Is Your Agile Journey Based on Problems or Process?

Is Your Agile Journey Based on Problems or Process?

You can start your agile journey in any number of ways. Some people like to start with Scrum, because it’s a project management framework. Some people like to start with Kanban, because it reflects your current project approach and allows you to visualize your workflow. You can improve as you proceed.

Some people want to plan an entire agile transition from one team, to an entire organization, as if they could imagine how the organization could change, all up front. Big Design Up Front, anyone?

Let me suggest an alternative. Instead of selecting a process first, consider the agile values first. Are there values that resonate with you more? Maybe you build on those values first, solving your problems, using them as the basis for your agile transition. As you proceed, maybe you can integrate other values to build on your success.

Faye said:
“We started knowing that we had a value of wanting the teams to work together more closely, first inside the teams, and then between teams. That was important to us. So, we focused on continuous integration. We knew it would help us release software faster. What did we need to do to achieve continuous integration?”

“We knew that we could change requirements if we had already integrated what was done. So continuous integration was necessary for us to start. We removed all obstacles and paid off all our technical debt for continuous integration. It took us four weeks on one project. It took us three months on another program. But, by the time we finished with those two efforts, we knew what it took. As a by-product, we understood how to do smaller stories, use a kanban board, and use timeboxes. We weren’t agile yet. But we were using the principles. And, we were able to deliver software.”

David said:
“We had to focus on working software. Before, we used to go for months without a working build. We set ourselves a goal of first having a weekly build. It would take us all week to clean up the errors and warnings for the build. Once we did that, we went to nightly builds. Once it took us less than a day to clean up the nightly builds, we went to build-anytime. Now we can build whenever we want. If someone breaks the build, that person knows and cleans the build right away. We’re generally five or ten minutes away from a working build. Considering we have four teams working on one application, that’s quite a feat for us. Now, we can think about what approach we want to take.”

If you, like Faye or David, have concerns about your approach to agile, you might want to look at the values or principles behind the Agile Manifesto. What appeals to you? Where do you have the most pain?

Instead of deciding on a process or a framework first, consider the agile values. What would help your organization the most? Solve that problem, using the tools of agile: using short timeboxes, visualizing your work, and limiting your work in progress. You don’t have to start with a process first. Start with your problems. Solve them. You might discover that solving your problems by starting with agile values provides a better solution.

Where Johanna is Speaking