Becoming Agile : Get back to first principles first
0 likes562 views
The document discusses the challenges organizations face in effectively implementing agile methodologies, highlighting issues like high lead times, team stress, and the need for a return to first principles. It emphasizes the importance of focusing on people, value, flow, and quality, while also critiquing common motivational strategies and the significance of communication and collaboration in team dynamics. Ultimately, the document advocates for a deeper understanding of customer needs and the optimization of workflows to achieve real transformation in agile practices.
Becoming Agile : Get back to first principles first
- 1. Text Becoming Agile Get back to first principles first Presentation Outline Only - NOT the actual content
- 2. Outline structure of the session What went wrong? What about people? What about value? What about flow? What about quality? Becoming Agile
- 4. Talks about partial successes with Agile implementations. We have become iterative for sure and there is a definite sense of cadence. But concept to cash lead times are still quite high. A sense of dogma has crept in the rituals, they happen, but there is little soul.Team members are still quite stressed out; We have avoided the famous waterfall death march for sure but it is still a very tiring and painful long march. Organisations doesn't feel that they have reaped all the benefits which were promised. There is just a handful of companies who seem to be living the values and are really nimble in the market place. What went wrong? Our focus on people, value, flow and quality instead of process,tools, cost, schedule and scope, got the attention but did not get internalised by all. So while we are adopting “Agile” methods we have not become “agile” yet. There is a need to get back to first principals. There is a need to explain knowledge workers on the ground “Why” the principals work. Leaders need to do more than just support the change, they need to know, behave and do the right things. Lastly people do need to learn and love their craft. Yes, it is about money but is it also about autonomy, mastery and purpose. The session takes through key concepts around people, business value, product development flow and quality via fast feedback, and invokes people to understand and let their team understand the basic principals first to lay a strong foundation, before building an Agile enterprise on top of it. It is only then the “real transformation” happens and the products get in front of the end users faster.
- 6. Teams Building a high performance team Hundreds of books have been written on team-working; team-building courses are perennially popular, and every CV insists the applicant is a 'team player'. Team is obviously an important concept for modern business, but most individuals will have experienced the frustrations of non-working teams as well as the special magic of teams that work as more than the sum of their parts.
- 7. Motivation Doing more, and having more fun doing it A motivated team or company is not only fun to work in, it increases growth, profitability and reduces staff turnover costs. Yet despite maintaining expensive motivation programmes, most companies motivate their staff in ways that are inefficient or have unintended consequences. Challenging a system engrained in corporate culture can prove difficult, but this session provides a compelling argument, supported by meticulous research, to reconsider the way we motivate our teams and our people
- 8. Communication, Collaboration & Coordination A project is more likely to fail because of problems with communication than through technical difficulty. A failure to collaborate can destroy employee motivation and erode the competitive edge, while coordination errors result in staggering levels of waste. In short, these three fundamentals of human interaction are more essential than any other skill to the success of your project and organisation. As philosophies, Agile and Lean have placed enormous emphasis upon all three. Yet few companies make any formal or sustained attempt to improve them as part of their end-to-end innovation and delivery processes.
- 9. What about value? Understanding your customer Prioritisation Delivering value early & often Trade-offs
- 10. Understanding your customer Create lasting value - focus on customers The Agile manifesto opens with the statement, 'our highest priority is to satisfy the customer'. Everyone knows that the customer is important, right? And yet there are many organisations that have failed because they have lost sight of the customer's needs. It's not always easy, but knowing how to give your customers what they want when they may not even know themselves is what successful innovation is all about.
- 11. Prioritisation The problem isn't having good ideas - it's deciding which ones to do Wherever resource is constrained - time, money, people - choices have to be made about which project, feature or requirement we will focus on first, or whether to do them at all. How we make that choice is not always simple because value can mean different things to different people. Is the decision based on revenue, time-sensitivity, risk, cost or a combination of them all? Investing your resource in the right projects and even ordering what you deliver within those projects can have a radical impact on profitability. Indeed, it can mean the difference between success and failure.
- 12. Delivering value early & often The compelling case for early delivery of value Delivering early and often has major financial benefits by releasing value early. It also helps with marketing, incorporating customer feedback earlier to improve flexibility and with engineering, because lowering technical complexity is often a requirement of incremental delivery and short launch cycles help advance quality. There is also a real and measurable affect on team motivation, joint learning and performance, as teams focus on seeing their work go live.
- 13. Trade-offs If you can't have everything, what do you need Trade-offs are essential within any project or organisation - cost, speed, risk and flexibility among others. Yet decreasing cycle time actually helps with most of these, by shortening the feedback cycle. Previous sessions provide an in-depth exploration of the tools which help to decrease cycle time. This highly-practical session examines the combinations in which the tools should be used to optimise flow depending upon the trade-offs that best suit your organisation. It also explores concurrent engineering, overlapping activities so as to reduce cycle time, discussing the benefits and risks and how to manage the team's external dependencies.
- 14. What about flow? Requirements Optimising flow Attacking your queues Batch size matters Work in progress
- 15. Are requirements the problem? When projects fail, poor requirements are cited as the problem a third of the time. No wonder writing and managing requirements is such a hot topic in delivering projects. But, are the requirements really the problem? Ultimately the requirements are a way of communicating ideas and coming up with a shared understanding of ways to meet customer needs and wants, but they so often become an immovable contract that leads to many unhappy parties. Agile methods have introduced the idea of much shorter feedback loops and the ability to change based on evidence and learning from interacting with users much more frequently. So, we now need to look harder at how we express and communicate customer needs and develop the most valuable solutions we can.
- 16. Optimising Flow Optimising flow – finding the best way for your organisation to deliver The fable of the tortoise and the hare is a story of slow and steady versus fast but flaky. It’s a story with parallels to software development. Moving fast means more time in market and more awareness, while an organisation’s agility or nimbleness makes it easier to respond to opportunities or threats. Speed and first-to-market also have associated costs and risks. Deciding how to travel depends on the organisation’s goal, but in general most organisations want to move faster. Despite striving towards this, few organisations deliver software and IT projects as fast as they, or as their customers, would like. Instead they are wedded to a measure called ‘on time’ delivery, which has unintended results - often making them slower and less flexible.
- 17. Attacking your queues Battling the enemy of flow to reduce cycle time Most work - whether a task or a vast project - spends most time not in activity, but sitting waiting for someone to do it - in a queue. Because work in software development is normally intangible information, it is easy not to manage these queues and instead to let them build up. This session examines the nature of queues - the reason they form, why long queues get longer and why they cause so much damage. Especially revealing is the link between capacity utilisation and cycle time.
- 18. Batch size matters For better flow, batch size matters A batch is a quantity of work for or from a single operation, and since the rise of industrialism, we have trained ourselves to work with large batches because of perceived efficiencies. Waterfall development, big- bang launches, project approval gates ! these are all examples of processes that lead to large batches. This session considers the high price we pay for these supposed efficiencies - increased risk, value tied-up and lengthy cycle times.
- 19. Work in progress Do less to do more, the beautiful paradox of WIP Work-in-progress constraints are the heart of the Kanban methodology gaining popularity in some organisations. Understanding why WIP constraints work and their effects on work flow, queues and delivery are essential for anyone considering adopting 'pull' practices. The session explains the principles of visualising work, signalling, self- management and matching work to capacity. As well as advising of differing ways of limiting WIP, the session examines potential problems and the likely pitfalls and errors - signs that system is not working for your organisation.
- 21. Feedback The route to learning Customers don't know what they want, developers don't know how to build it, and things change! Painful as those problems may be, they are common, in fact, inevitable. Feedback is the only solution. It is not a perfect solution, and interpreting feedback may not always be simple, but it is essential - the only way that we can adapt and learn.
- 22. Becoming Agile When it comes to Agile implementations, at one extreme you find people who want a checklist of rules; at the other, people adopt the label ‘Agile’ without changing anything at all. Both attitudes are liable to end up in the same place – frustration. One of the approaches that work: Get back to first principles Right application of Lean & Agile - Scrum, Kanban, XP etc. Scale across the enterprise using SAFe etc.