Being Agile: Eleven Breakthrough Techniques to Keep You from “Waterfalling Backward”
The goal of the book Being Agile – Eleven Breakthrough Techniques to Keep You from Waterfalling Backward is clearly stated in its first page: “Transforming from a waterfall-based methodology to agile is no small undertaking. This book is for people who may find their team falling back into old habits when the going gets tough or just because an old waterfall approach seems like the right thing to do. It is also for those teams that have adopted agile but do not feel like there has been a significant improvement.”
The book Being Agile – Eleven Breakthrough Techniques to Keep You from Waterfalling Backward explores eleven aspects of Agile like the whole team concept or delivering value where teams might have issues when trying to change their practice. Each chapter is structured in the same manner. It starts with a discussion of the topic with real life examples and ends with metrics that will allow you to assess your status and a provocative breakthrough that can help you implement the principle. You will find also a summary of the key points discussed in the chapter.
I think that this book achieves its goal of discussing the problems when you try to adopt Agile practices. I will therefore recommend this book to every software developer and project manager involved in this type of transition from traditional project management approaches to Agile and Scrum.
Reference: Being Agile: Eleven Breakthrough Techniques to Keep You from “Waterfalling Backward”, Leslie Ekas, Scott Will, IBM Press
Quotes
Traditional software development organizational structures have advocated for teams that specialize in technology and are grouped by a common discipline, for example, development, test, user documentation, and so on. The reasoning goes that teams composed of people with similar skills can help each other within their own domains. Furthermore, it is believed that teams that share a common discipline can be “time-sliced” across various projects as needed instead of focusing on one project at a time. This is the epitome of the “job-shop” mentality in which engineers just do their specific job and lose sight of the bigger picture. Unfortunately, optimizing the efficiency of a particular discipline almost always sub-optimizes the organization – a point that is often not well understood. Lean thinking in particular focuses on process throughput optimization to improve efficiency, versus individual throughput.
What do we mean when we advocate “smaller batches” in agile projects? What we have in mind is a pattern of completing design, coding, testing, automation, and product documentation tasks in tight integration with each other on an on-going basis. Think in terms of hours – up to a day or two at most – to complete one of these tasks.
If you want to get into the habit of not accumulating waste, try this technique: Limit defect priorities to just one classification: “ Fix it now! ”
When I started practicing agile, I found the notion of “do just enough” not only liberating but also a subtle, yet fundamentally different way to think about delivering customer value. The basic idea is that just enough functionality is created to meet the needs of stakeholders – but nothing more. Do not include extra capabilities that may or may not be used. Applying “do just enough” thinking solves several problems: Noncritical features will not be developed, value is delivered to stakeholders sooner, and teams get early validation that their product is actually solving customer problems. The Agile Manifesto principle, “Simplicity – the art of maximizing the amount of work not done – is essential” reinforces do just enough thinking.
