In my post, What is Better About Agile Development? (a reprint of the article Top 10 Reasons to Use Agile Development that I wrote for DevX.com), my eighth reason for using Agile is that, Agile development expects continuous improvement. This post will expand upon this topic.
As I noted in my article, “Agile development expects its practitioners to be continually learning and adapting…” This concept is articulated in the final principle of the Agile Manifesto, which states:
“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”
As a manager, I want to see everyone to improve and grow, and i feel that continual learning is vital in the software business. If you aren’t learning and growing (you’re “maintaining”), you are effectively losing ground. The world will move past you.
It is equally important that my development organization is utilizing the best practices possible to make individuals and teams as effective and productive as possible. Agile development actually makes a manager’s job easier with respect to learning and improving people and the software development process. You don’t have to explicitly create a “learning opportunity” for your staff (carving out time in busy schedules); the opportunity is created through the Agile process itself.
As I stated in my article, continuous improvement is enabled in part through sustainable development. Improving productivity requires that people grow and change, and in order to accomplish this, people need time to learn, think and reflect. Another component of improving productivity is getting people to accept change. The best way that I know of to accomplish this is to have them initiate the change on their own.
The other enabler is the individuals themselves. People must have the desire to actively learn and grow; they must value learning and be willing and able to act on what they learn, improving their personal and/or team productivity. By applying what they learn and then thinking and reflecting on how well it worked (and tweaking where necessary), new knowledge and expertise is developed. This is a true learning organization at work.
To facilitate this, Agile development incorporates the concept of slack. As James Shore and Shane Warden described it in their book, The Art of Agile Development:
“To keep up with their constantly expanding field, programmers must continually improve their skills. In doing so, they will often learn things that enhance their work on the project.
“Dedicated research time is an excellent way to encourage learning and add additional slack into your iterations. To introduce it, set aside half a day for each programmer to conduct self-directed research on a topic of his choice. Be completely hands-off. I recommend only two rules: don't spend this time on project stories or tasks, and don't modify any project code.”
I’ll make one point about the first sentence, which in part states, “…they will often learn things that enhance their work on the project.” Some people are better learners than others, and often times it is better to learn about specifics that are directly related to the work that is being performed or is about to be performed then something that you might need to know about in the future – there is direct applicability and reinforcement of the learning. It’s an application of the age-old, “use it or lose it” advice.
Team retrospectives are another way that Agile development fosters improvement. A retrospective is a meeting where a team looks back on their past iteration so that they can learn from their experience and apply this learning to future projects. In contrast, traditional, plan-driven projects normally hold something like a “post-mortem” at the conclusion of the project, when it is too late to improve that project.
I like this continuous improvement cycle of Agile development, not only because small improvements are being routinely made, but because the changes are automatically bought into by team members because they are the ones initiating the change. I also like regular retrospectives because they are also a great time to reflect on what went well, and what should be celebrated. Celebrating success helps keep people energized and engaged.
When it comes to improvement, some key points about retrospectives that I feel are important:
No blame. Retrospectives shouldn’t look to lay blame, but to examine – professionally and depersonalized – what needs improving.
Focus on what is in the team’s control. A team retrospective that focuses on exclusively that is outside of their control isn’t particularly useful to the team. Sure, maybe the team could have used an extra resource or two. The question is, did the team maximize the use of everyone? What or how could the current team have done to work more productively?
Drill down to actionable tasks. Don’t settle for high-level statements of a problem and/or vague notions of what could be done. Decompose the issue into actionable tasks that could be taken on in the next iteration.
Prioritize and select a task. A team doesn’t have to take on a suite of improvements all at once. In our organization, we use two-week iterations, so every two weeks there is an opportunity for improvement. Teams need to ask themselves, what would have the greatest impact on productivity for the team?
There are some managers who get uncomfortable with the concept of slack during an iteration and time dedicated to routine retrospectives. They don’t feel that they are maximizing productivity because team members aren’t engaged in “producing” software on a constant basis. This is counter-intuitive, in my opinion.
If you want productivity gains out of your knowledge workers – increasing the capacity of your existing workforce – then those people need to put knowledge into their knowledge banks. Knowledge workers cannot improve their capacity without investing time and effort to do so. This is a two-way street, however. The organization must recognize and provide the opportunity for this to happen, and the employees must take responsibility and take the initiative to follow through.
Agile development creates this opportunity. And it is up to the teams and the individuals on the teams to exploit the opportunity that is presented to them.