Leslie Ekas & Scott Will have written the book Being Agile: Eleven Breakthrough Techniques to Keep You from "Waterfalling Backward" provides advice on how to make an agile transformation sustainable.
They identify some common mistakes and provide ideas on how to avoid them, with a focus on what is needed to Be Agile instead of just doing agile practices.
InfoQ interviewed Leslie and Scott about their book.
You can download here the first chapter of this book.
InfoQ: Why did you write this book? What is the underlying problem you were addressing when you wrote it?
Scott and Leslie: We saw that new teams moving from waterfall to agile were regularly hitting the same problems. Agile is a very large undertaking and new teams seem to tackle the easy stuff initially and then stagnate. What we’ve found is that the teams that stagnated tended to approach agile as just simply adopting a set of practices. Only when they moved beyond the “adopting practices” mentality, and began to understand why the practices were advocated (i.e., understand the principles behind agile), did the teams really start to make significant improvements.
Principles should be the driver. For example, in one sense, short iterations do not really matter – but what teams should get from adopting short iterations does matter. Getting to “working software” in short, time-boxed iterations so that you can get rapid feedback, manage your quality as you progress, and do no more than is really needed, are some of what’s behind short iterations.
Even for teams that understand the principles, they sometimes get stuck since waterfall thinking has held sway for so long. We faced a number of these issues and came up with some breakthrough techniques to help teams overcome their old ways of thinking. The breakthrough techniques were designed to help overcome the "let's do what we’ve always done in this situation" reflexive responses when challenges arose. When agile teams reflexively used waterfall thinking, they were waterfalling backward. We wanted to help them breakthrough old habits and really begin to see the fundamental changes in how agile teams should operate. The successes we had are what prompted us to consider writing the book.
InfoQ: What makes you the right people to write this book? Please tell us a bit about yourselves and your background.
Scott and Leslie: We both have spent the majority of our careers as software engineers and managers. Between the two of us, we have experience in many facets of the business. We both started developing when the industry was relatively new (punch cards and assembler anyone?) and have lived through its continual transformation. We have seen many software fads come and go. Agile, however, is not a fad – it’s here to stay. There will be continuing changes, such as the adoption of DevOps, but they are being built on top of agile. Both of us got early experience with agile and it made our teams better. We wanted other teams to get this same result.
We were charter members of the IBM Software Group Agile Center of Competence and have coached teams inside IBM, as well as customers, for many years. Through our engagements with a multitude and variety of teams, we learned what worked, and what didn’t, in terms of helping teams succeed with agile. Our book conveys these experiences so that other teams can benefit from them.
InfoQ: Why the title "Being Agile" - isn't Agile a methodology for software development?
Scott and Leslie: “Being Agile” was a critical part of the book title because we believe that you have to think and respond in an agile way in order to succeed with agile. If you have an agile mindset – one informed by the agile principles – then planning, execution, and problem solving naturally flow from that mindset. One of our early working titles was, “Don’t Just Do Agile – Be Agile.”
Treating agile as just a methodology is the reason we think teams get into trouble and quit making progress with their agile adoption. This is why we spend so much time in the book discussing agile principles – we wanted to show why doing the practices matters as well as discuss the benefits that teams should experience.
InfoQ: You present a number of ideas around the social/team aspects (whole teams, multitasking, stakeholder engagement) - why do they matter so much?
Scott and Leslie: We believe that the social/team aspects are so significant that our first chapter is on the agile concept of whole teams. One of the most fundamental differences between agile and waterfall is the realization that the most productive teams consist of tightly knit software professionals who work closely together to leverage their strengths and collectively overcome their weaknesses. From the whole team deciding on how to accomplish their work in every iteration, down to developers, testers, and writers working closely together daily to get to working software, team interactions and collaboration are a key driver to success. Timely communication helps teams prioritize, brainstorm, avoid problems, and learn. Teams working closely have to communicate often and effectively. Verbal communication tends to be the best method as there is live interaction, and the interaction enables forward movement. Agile methods encourage active and regular communication.
Having teams work closely together on one thing at a time helps eliminate multi-tasking – the each team shares a common goal (i.e., completing a user story) and any interruptions are met with stiff resistance because it impacts what the team is trying to accomplish. What we tend to see when teams don’t get the whole team approach is individual team members off in their cubes, isolated from each other, working for a week or two at a time, and being relatively unaware of what other team members are doing. The results are usually predictable – major problems at the end of an iteration due to a lack of regular interaction.
If communication within the team is so important, then communication with stakeholders is even more important (just to clarify, we tend to use the term “stakeholders” to refer to the folks who will be buying and using the product). Understanding their needs, and whether or not what you’re building is actually meeting their needs, is critical. The thinking that teams can ship a product without ever having talked to a customer, and believe that they have met the customers’ needs, escapes us. Constant engagement with stakeholders is another key agile success criterion.
InfoQ: You also present a set of ideas which seem to come from Lean thinking - queuing theory, eliminate waste, release often, deliver value, stop the line - where is the overlap with Agile and why do they help to "be Agile"?
Scott and Leslie: We think of agile as building on Lean thinking. It is hard to imagine succeeding with agile adoption without understanding Lean. Actually, it’s hard to imagine agile even existing without Lean. For instance, how can you have working software every iteration without being able to break your work down into small batches? And why are small batches inherently more efficient than larger batches? Lean provides the answers…
And regarding the emphasis on eliminating waste, in the past if we had problems, we created new processes to overcome the hurdles. With Lean thinking, we don’t just add more process to deal with the symptoms – we figure out the root cause(s) and solve them there. We also determine what not to do by determining what part of our routine does not deliver value.
Showing how Lean thinking forms the basis for many of the agile concepts results in a better understanding of agile methods. That understanding drives more successful execution so that teams actually get the benefits that agile promises.
InfoQ: What are the key elements of a continuous improvement in being agile?
Scott and Leslie: The most critical element of continuous improvement is the "continuous" part of it. Never stop trying to get better. There are always ways to improve – this is the mindset to achieve. That is not to say that what you are doing currently is bad, but it is always possible to get better. We constantly tell folks that there is no such thing as “100% Agile” to help drive this point home.
Constantly pushing to improve every iteration can be challenging over time – especially as deadlines loom – and teams often give up on improving as a result. That is why we introduced some alternative approaches to maintaining a focus on continuous improvement. If you are not continuously improving, then we would say you are not “being agile.”
The end of iteration reflection meeting (sometimes called a “retrospective”) is the mechanism that agile teams use to focus on continuous improvement. The idea behind reflections is not to gripe about problems, nor to simply list off all the problems and create big action plans in an attempt to boil the ocean. The key point of reflections is to focus on the biggest pain point and begin taking action to solve that problem. Keep focused on that one problem (for multiple iterations if necessary) until it’s no longer a problem, and only then move on to the next biggest pain point. When all your pain points are gone, then use reflections to decide on some new practice, or technique, or technology to investigate, and then pilot it to see if it helps the team improve. Lather, rinse, repeat!
InfoQ: Is there a single piece of advice you would give a team who wants to make the transition from Doing Agile to Being Agile?
Scott and Leslie: The single piece of advice that we would give a team that wants to successfully make the transition from "Doing Agile" to "Being Agile" is to have working software every iteration. Adopt this approach beginning with the very first iteration. If the team does not succeed one iteration, keep at it. Plan to have working software the next iteration, and then every iteration following. Achieving this goal regularly requires that a team understand and apply at least some of the important agile principles. Having working software continuously will enable them to think and act in agile ways instead of just implementing some practices in the hopes of progress. Once a team achieves working software throughout its development life cycle, the progression to "Being Agile" comes more naturally.
This interview is based on the book, Being Agile: Eleven Breakthrough Techniques to Keep You from "Waterfalling Backward", authored by Leslie Ekas and Scott Will, published by Pearson/IBM Press, Oct. 2013, ISBN 978-0-13-337562-6; for more info, please visit the publisher page.
About the Book Authors
Leslie Ekas has worked in software development for over 20 years as a developer, manager, and agile coach. Her industry experience ranges from a startup, to a mid-sized company, and most recently IBM. She has led multiple products to market successfully over the years. She has managed teams of all sizes and many disciplines and across broad geographies. Leslie helped start the IBM Software Group Agile Center of Competence after her team’s early success transforming to agile. After coaching for several years, she returned to development to lead the worldwide Rational ClearCase team. She later moved to the Enterprise Asset Management Software product management team to help them adopt an agile operational approach.
Scott Will has been with IBM for more than 22 years, the last six as an agile consultant. His experience ranges from providing consulting for small, co-located teams to teams with hundreds of engineers scattered across the world. Previously Scott was a successful programmer, tester, and customer support team lead, and he was in management for years. He is a contributing authorto the book Agility and Discipline Made Easy, an IBM Master Inventor with numerous patents, a former Air Force combat pilot, and a graduate of Purdue University with a triple-major in Computer Science, Mathematics, and Numerical Analysis. He also completed his MBA while in the Air Force.