Scrum, Kanban, Lean development, Lean Startup, DSDM, FDD-- it’s alphabet soup. How does each one build in project management? Will one work for your company “out of the box,” or do you need to customize your own approach?
Don’t get caught up in labels and brands. Focus on your company’s goals. For long-term success, the goal needs to be the best possible quality, so that the product will delight the customer, while keeping
How will you know when your team is Agile? I recommend Elisabeth Hendrickson’s Agile Acid Test: Agile teams produce a continuous stream of value, at a sustainable pace, while adapting to the changing needs of the business. The key here is “sustainable pace.” We must deliver production-ready code every two weeks, every week, multiple times per day, without working insane hours and taking longer and longer to implement each new feature.
We naturally turn to established processes for answers. Scrum and Kanban both provide project management frameworks. Lean development applies across the organization, not only within the software team. Extreme Programming (XP) provides core development practices, which can fit within any project management framework. Some companies come up with their own way to develop their products, but still pass the “Agile Acid Test.”
Ask the right questions
“Agile” does not mean “go faster.” A successful transition to Agile, as defined above, requires a huge up-front investment of time, learning and discipline, but that investment brings a huge payoff over the long term.
Start your Agile journey by getting everyone in your software organization together to ask good questions. What’s the biggest problem, the one impediment that if you could remove it, your team could take a big step forward? It could be missing skills, inadequate infrastructure such as hardware and software, projects not delivered on time, delivering a product that doesn’t meet customer needs, any number of potential issues. Identifying your biggest obstacle is half the battle. Retrospectives at least once per iteration are the most valuable Agile practice.
Once you’ve identified your biggest impediment, think small experiments to make this problem just a little smaller, or work around it just some of the time. Choose a small experiment which will provide quick feedback to try for the next iteration. Say your biggest problem was that the build fails multiple times per day. You could experiment with using a colored light in the team area to show the status of the continual build process.
At your next retrospective, see if the biggest impediment is any smaller. If not, think of another little experiment to try. You may have discovered that the real problem lies somewhere else. Or perhaps your experiment cut the impediment down by 25%, and it’s no longer your biggest issue. In that case, move on to the new biggest obstacle and repeat the process.
Educate yourselves on the alternatives
Now, you’re focused on whittling away at your biggest impediments by trying small experiments, inspecting and adapting. You still need some framework to manage your product development and project progress. You also need core development practices to keep technical debt at a manageable level. Which “flavor” of Agile will suit your situation the best?
The Agile Manifesto and its Principles are your best guides as you evaluate different agile practices, processes, frameworks and tools. There are many excellent books that explain Agile principles, specific Agile project management frameworks such as Scrum and Kanban, and Agile practices such as test-driven development (TDD) and continuous integration.
Join online and local Agile user groups to get recommendations of good books, blogs and other publications to help you tailor your own approach to Agile development. Ask more experienced Agile practitioners to recommend training courses, conferences and other resources where you can learn more.
When I started on my first XP team back in 2000, I joined the extreme programming Yahoo group, where I got plenty of help and guidance. Soon we formed the Agile-testing Yahoo group for narrower discussions around testing. I also got with other practitioners in my area to form the XP Denver (later Agile Denver) user group. The past few years, I’ve learned a lot from people I follow on Twitter.
Take your team on field trips to visit other, more established Agile teams. My own team has gotten some of our best ideas by watching other teams.
Once you understand the various Agile project management frameworks and approaches, choose one to try, but be sure to have the right people to help you get started.
Implementing a simple, straightforward project management framework such as Scrum can literally be done overnight. However, effecting meaningful change in the way an organization works requires changes to the underlying company culture. It’s a difficult and tricky effort that is likely to fail, because people don’t like change, and company bureaucracies may put up many obstacles. Having someone on board who’s already been through a successful Agile transition is a big asset. If possible, hire one or more developers, testers, analysts, Scrum Masters, coaches and/or people with other skill sets who’ve worked on successful (and truly Agile) teams.
At the very least, bring in an experienced Agile coach who knows how to successfully change company culture. Find one who will work hands-on with the teams over a long period of time, even if it’s just a few days a month, to help them learn how to be self-organizing teams and solve their own problems. Make sure everyone, in every role, has the support, training and time they need to learn. Expect everyone to make mistakes, and help them learn from those. A big investment now is better than having to “stop the line” years from now and try to “fix” everything.
Customizing by experimentation
When you choose an Agile approach or process to try, it’s usually best to start out “by the book.” As your team gains experience, it can start identifying issues and trying small experiments to address them. You may try out practices from other agile project management approaches, or techniques borrowed from teams you’ve visited on your field trips, as mentioned earlier. Use your retrospectives to evaluate how your experiments are working, and to dream up new ones.
My current team transitioned from Waterfall to Scrum in 2003. Team members with Agile experience, including myself, were brought in. We estimated user stories in our product backlog, did sprint planning and retrospectives and learned the core ingredient in making Scrum work: how to be a self-organizing team. To meet our commitment to develop the best quality software that we could, we soon adopted the XP practices. For the first year, we only delivered a small number of new features each sprint, since we needed time to learn new practices and pay off years of technical debt. Once we had a solid foundation of cleaner code supported by tests, and had learned how to collaborate with stakeholders to get examples to drive development, our velocity steadily increased.
Over the years, we’ve abandoned some Scrum practices that didn’t add value for us, and incorporated techniques and principles from Lean development and Kanban. If you visited our team, you might not be able to identify what Agile “methodology” we practice. What matters is that we can accommodate the fast-changing needs of our business while maintaining a steady velocity. We continue to investigate new ways to plan and manage our work and deliver more value.
No project ever succeeded thanks to a particular methodology. Projects succeed when they have the right people who are allowed to do their best work. Make sure you have the right people, and get obstacles out of their way. Focus on delivering the best quality software you possibly can. Take lots of time to learn and experiment, and get expert help to find and implement processes and practices that work best for your particular situation. Let the Agile Manifesto and its principles guide you, as you find ways to deliver value to your business quickly, as you maintain a sustainable pace.
This was first published in June 2012