While Agile development is now being adopted by a wide range of companies around the world, there are still many
teams out there who have not yet made the transition from a phased-and-gated development approach to an Agile one. As Elisabeth Hendrickson says, a team is Agile when it delivers business value frequently, at least once a month, while working at a sustainable pace. This brings many benefits to the companies who successfully implement an Agile development team, but the transition requires a big investment of time, learning and discipline.
Where do we start an Agile development team?
These days, we have several frameworks available that help a team move to Agile development. In my experience, Scrum provides a framework that is easy to implement. You can decide tomorrow to start the first day of your first iteration, be it one week, two weeks, whatever you want to try. Hold a sprint planning meeting, put stories and tasks on a board, start a burndown chart, choose a time for your daily stand-up and go.
Implementing the framework is simple. Other frameworks such as those used in Kanban are too. The hard part, and the key to success, is learning to be a self-organizing team. That takes more time than you expect. Our business stakeholders and customers want features delivered right now. How do we balance time to learn and delighting our customers?
The most common problem I see in new Agile teams is that they’re so anxious to show their management how great this Agile thing is, they become overly optimistic about how much they can deliver by the end of the sprint. It doesn’t help that the stakeholders are begging, “Can’t you do just this one additional small story?”
In The Clean Coder, Bob Martin explains that being a team player does NOT mean saying “I’ll try” to every request from management to meet an unrealistic deadline or do “just a little more.” We’re team players when we get in touch with reality and set reasonable expectations for what we can deliver. And let’s be honest – even if we only delivered one small user story at the end of an iteration, isn’t that way more than they would have gotten in your old development process?
You need lots of time to learn how to be a self-organizing team and to learn many new practices that will let your team deliver high-quality code. If you don’t build this foundation now, you will accumulate technical debt, and possibly fail in the long term. If you invest in quality now by taking time to learn and practice, you will be able to do more in the long term.
Fight your natural optimism by intentionally planning less work than you think you can complete during the iteration. Pulling in more stories is better than having to disappoint the stakeholders by telling them you have to drop a story. Remember to budget time to complete all testing activities for each story, including automating regression tests and exploratory testing. When you estimate stories and plan tasks, remember to include refactoring and other practices to keep your technical debt under control. You may need to write stories to learn new practices, try out new tools, or do technical debt-reduction work.
My team plans only enough work to stay busy for a few days. We often plan additional stories to have “on deck,” but we don’t commit to completing them. Interestingly, when we switched from the traditional Scrum ‘commitment’ to this process, our velocity went up significantly.
Learning about Agile
In my experience, a team needs some core practices to keep their technical debt manageable and succeed over the long term. Perhaps most important is a short feedback loop. You need to know within a few minutes whether a new code check-in has broken some part of the code. Therefore, you need a continuous integration (CI) process that kicks off on every code checking. This compiles the code, creates deployable software, and runs automated regression tests. If your team does not have a CI process, stop everything you’re doing right now, and get one going. The good news is that this is pretty easy for your developers and system administrators to do.
Automating all the regression tests is another core practice. It begins with test-driven development and automated unit and integration tests. Automated regression tests at each level of the application, including the API or service level and the GUI level, are a key component for keeping technical debt from building up and slowing down delivery of new features. If you don’t automate all your regression tests, you’ll quickly build up crippling technical debt, you won’t have time for critical exploratory testing, and your team will find it hard to break out of the resulting death spiral.
A self-organizing team inspects and adapts: it looks back at what has happened recently, and thinks of new experiments to overcome impediments and improve. It’s not easy for a team to learn how to solve its own problems. Budget plenty of time for this in your first few months or even first year of your Agile transition.
Training and coaching Agile teams
The skills I’ve talked about are difficult to learn. Find good people that can provide useful training to your team. An ideal solution is to hire a permanent employee who has worked on successful Agile teams and can mentor the rest of the team. If you decide to hire an outside coach or consultant, be aware that nobody, no matter how talented, can come in and “fix” you. It’s good to get help, but find someone willing to at least come back frequently over a long period of time and help your team keep itself on track.
Budget plenty of time for learning. My current team started its Agile transition in 2003, but we continually need to learn and improve. Recently, taking a cue from companies such as Google, our company implemented one “learning day” per sprint. The first Friday of each sprint is time for every team member to try out new tools, experiment with new techniques, learn about our domain, whatever we feel we need. This seems expensive, but it means that we can respond to business needs faster, and find ways to continually improve and shorten the concept-to-cash cycle.
Sit back and take stock at least once per iteration. What are your biggest impediments? Are there roles on your team that don’t fit into the Agile prescription? Identify your biggest issue, and think of an experiment that will make it a little bit better. Write a story or task card to make sure that experiment is done, and evaluate the results the next iteration. If you asked anyone on my team what’s the single biggest reason we’ve been able to improve so much over the years, they’ll tell you it’s doing retrospectives and trying experiments.
Keep your experiments small, and time-box them. Try some new practice or take on an action item for one or two iterations, then take time to evaluate how it’s working. If it’s not helping, dream up another experiment. Solve your problems in small increments and short iterations, just like you write and test your code.
Your team needs to learn how to self-organize and solve its own problems. Nevertheless, you need someone to help remove impediments, and run interference for areas outside the team’s direct control. Scrum Masters, coaches and managers can fill the servant leader role. There are times when a manager needs to step in, for example, if there is a personnel issue that the team hasn’t been able to work out on its own. Scrum Masters fill in the squishy middle parts of the Scrum framework, facilitating discussions, helping to resolve conflicts and getting help or input from customers as needed. Other frameworks have similar servant leader positions.
Scrum is simply a project management framework. The success or failure of your team depends on the people in your team. Are they allowed to do their best work? Does somebody have your back? Your team might have to make some hard decisions – not every individual can make the transition from a traditional chaotic software development environment to an agile team. Agile brings transparency, and that’s not ok with everyone.
It’s a journey
Remember that projects don’t succeed or fail based on a methodology or tool. They succeed when they have the right people, who are allowed to do their best work.
Be patient as your team learns new and better ways to develop great – or even better, magnificent – software. Take baby steps. Inspect and adapt continually. Work on your biggest problem and make it a little bit better. Get involved with local user groups and online mailing lists for ideas and support. Read as much as you can. Don’t worry about failures – they are how you learn, and if you fear them, you won’t innovate or grow.
I love my job because I have the satisfaction of working with a magnificent team delivering a product whose quality improves a little bit with each iteration. As your team learns to deliver value to the business frequently without building up burdensome technical debt, remember to enjoy the journey.
Follow us on Twitter at @SoftwareTestTT and let us know what you thought of this article.