The year is 1984. You move to a new city and now some kids are beating you up because you’re getting friendly with the ex-girlfriend of one of them. You need to learn how to defend yourself.
Okay, so you’re probably not The Karate Kid. Much has changed in 30 years. Your competition is gaining market share, and you’re struggling to keep up. You need to take action in the new year and adopting Agile techniques seems like a way to compete.
Perhaps your team creates customized software for clients. Maybe you’re on a support team that works tickets for seven different systems ranging from true bug fixes to feature enhancements. It could be that your team is trying to revamp corporate policies and tooling to protect customer data. Or you could be building a car.
I’ve seen lots of groups say they’re “Agile” because they go through the mechanics of some particular method and wonder why they’re not immensely successful. I’ll often hear: “We’re doing Scrum. We have daily stand ups, everyone is colocated, and we show off our software every month.”
Those same people, after doing a little more digging, say things like “Well, we show off our software every month, but we haven’t released anything to our users yet. It’s only been 10 months though. Good thing we haven’t released it too, because there are parts we haven’t tested yet and really, I’m not sure if they’d work when we flip the switch on.”
This does not sound like a promising situation for the company or its clients. Any Agile method supports the principles laid out in the Manifesto for Agile Software Development. Generally they favor a focus on people and their interactions, getting working product at regular (and short) intervals, and fostering a culture that is responsive to change.
Speaking of Agile methods, there sure are a lot of them. We have Scrum, eXtreme Programming (XP), Lean, Feature Driven Development (FDD), Dynamic systems development method (DSDM), Kanban, and Scrumban amongst others. Just check VersionOne’s State of Agile Survey to see the large number of ideas that our industry is experimenting with, a list that’s surely grown since publication.
For your unique situation, simply doing what all the other cool kids are doing may not offer you the best chance at success. With so many options, how does one know which to use?
Paint the Whole Fence
A great place to start is taking a look at how complex your effort is.
The above is a model by Ralph Stacey applied to three major factors in product development: requirements, technology, and people. The complexity of a problem is determined by how close or far from agreement and certainty we are about various things and how much people factor in. Likewise, the more complex the problem the more likely a candidate it is to apply empirical process control, preferred by Agile methods, over defined process control.
Different Agile methods thrive in different complexity domains and there is definitely overlap. For simple to complicated efforts, we might be best served with Kanban and Lean principles to help us visualize our work, measure flow, and look for opportunities to improve what’s already in place to maximize that flow.
In the complicated to complex space, we might rely more on the practices provided by XP to help keep quality high and focus on building something that validates choices made around requirements and technology. At the edge of complicated, Scrum starts to be effective and prevails in the complex domain.
Scrum expects that the intersection of market conditions, technical ability, and people’s perceptions of a product they can interact with will invariably change what is desired to build into the product next. Teams and stakeholders regularly meet for engaged feedback sessions to validate that the right thing is being built and use that information to drive what should be built next to deliver the most value.
What if we start in the complicated space, but move to the complex? What if while we’re in the complex space we create a process that’s simple? Daniel-san was “almost done” painting Mr. Miyagi’s fence when suddenly, BOOM! ALL the fence!
Paint the Fence! Sand the Floor! Wax the Car! Paint the House!
If all Daniel-san knew was “paint the house” then he wouldn’t be very effective at karate. It took floor sanding, car waxing, and house painting as well all brought together to become a karate natural. Being Agile works the same way. You can “do” many different techniques and methods, but bringing the practices and principles from many together as the situation requires to use the right thing at the right time will help you to “be” Agile.