Jeff Langr and Tim Ottinger
Font: Brown Bag Lunch
Pop quiz, hotshot.
Q. "You're not agile if you don't ... "
A. Select one more of the following:
|a.||Have daily stand-up meetings|
|d.||Employ a metaphor|
|e.||Have a ScrumMaster|
|f.||Run iteration planning meetings|
|g.||Use index cards|
The answer is H, none of the above. Practices are just that--specific techniques a team might or might not employ to aid them in being agile--whatever agile means. Here's our definition: Agility means you are able to frequently and continually deliver high-quality software that meets the customer's needs.
The agile manifesto lays out four core values ("working software over comprehensive documentation," e.g.) and a dozen or so principles. But what factors truly make an agile team successful?
Freedom to change. Incremental change, one of the other success factors, can only occur if your teamis able to change how they work without outside interference. Meddling and micromanaging, never mind the intentions, usually divert the team from what should be everyone's goal of shipping quality software. Get the right people in place in your organization to support the team's rightful decisions, and to not try to change them. We'll be blunt: Conversely, this may mean removing the wrong people from the chain of influence.
Energized team. The successful agile team just gets it. They want to work this way. We can walk into a room and generally see whether or not a team will succeed. A good team is highly transparent and visibly enjoying what they're doing. They've built a true team spirit, and no one talks about "my code" or "my stories." They collaborate without being told; they hold their own stand-ups without a project manager having to crack the whip. They always act to protect the product and its integrity--they don't discard quality controls even when under intense pressure to deliver. They also look for ways to make life better for everyone--"How can I rework this test so that the next developer will understand my intent?" They'll step in and help anyone as needed to deliver quality product, even if it's "not their job."
While we like to think a good, energized team is all it should take, lack of freedom to change will demoralize even the best teams, to the point where your guys who "get it" choose to move on to something less oppressive.
Commo (line of communication) to customer. A product is an intricately detailed ship that must be well understood and constantly steered. The best teams we've seen have been steered by a strong, enthusiastic single-person, dedicated customer who truly understands what needs to be built. This customer has the time to ensure that everyone else can learn from them what needs to be built. While the strong customer can have a supporting cast, a large, committee-style product management team simply doesn't work. (It's always unfathomable to us that most companies are willing to staff development teams with no end of apathetic dregs, but are unwilling to pay well for strong people who know what product to build.)
Collaboration. So many teams want to be agile but can't get past cube mentality. Sometimes we think stand-ups were designed solely to compensate for cube walls, to make people feel better because they got together for a few minutes in the morning. Collaboration isn't just meetings. It's working together, and more importantly, figuring how to change workflow so that you have to work together. Due to the heavy intricacy of hundreds of thousands of lines of code interacting together as a single unit, software projects cannot be individual efforts ("you do your code, I'll do mine"). We must learn how to collaborate in the code. Really--collaborate. Work together. We mean it. Those who treat coding as an individual activity don't get it.
Attention to quality. The code is your product, and, unlike most other products, one you will continually build on and shape to meet continual new customer demand. If you fail to pay attention to quality, you will eventually slow down in your ability to meet demand, sometimes to the point of stagnation. The team must ensure that the code is clean enough to accommodate new incremental customer needs. Attention to quality is never a separate task on a plan; it must be embodied in everything you do to build your product, including coding, design, documentation, testing, automation, tracking, communication, and so on. Quality must be incrementally and continually addressed.
Incrementalism Most of the practices you employ in agile have something to do with ever-smaller steps. Instead of a massive requirements document, you allow the customer to provide features just in time, in small chunks described on little index cards. Instead of a comprehensive up-front design document, you learn how to design on a task-by-task and test-by-test basis. And so on. You must learn to think incrementally.
You must also look to correct course continually and incrementally. For every few lines of code added or changed, take time to ensure the design is as good as you can get it. (Which you can only do if you have enough controls in place to allow frequent code improvement. Best way we know how to get there: TDD.) Not only do you need to correct course in the product, you need to always correct course in your team. You should always be introspecting about your team, probing for ways it's not performing optimally, and working to correct these problems. Retrospectives are a good start.
A successful agile project is not a bunch of hare-like sprints to the finish line. It is a cool-headed, tortoise-like, slow 'n' steady approach of small, well-reasoned steps. Each step is an opportunity to look up and see where it got you--closer to the finish line or further away? It's easy to correct a single misstep. In contrast, a single mad sprint in the wrong direction can take you pretty far off course from the finish line.
Automation. There are numerous ways to waste people's time on a software development effort--running automatable regression tests manually, for example, or suffering a build process that unnecessarily requires multiple manual steps or manual verification. Agile cannot work unless you automate as many menial, tedious, and error-prone tasks as possible. There's simply not enough time across a two-week period to get any real work done if you have to slow down for numerous manual gating processes.
"Commo" is short for "Communications." You are not the first one to mention that the card is unclear in that regard. The version that goes in the book will probably spell it out. Sorry for confusion. Mea Culpa.ReplyDelete
Clarification to the above post: Doing standups or TDD doesn't make you agile, and so we are trying to say that not doing them doesn't necessarily mean you are not agile. Not doing TDD, however, may be the difference between failure and success (as defined in the post). TDD is the best mechanisms we know for ensuring quality at the code level, and attention to quality is of course one of our seven success factors.ReplyDelete
Great post! The very last sentence is so important and so often ignored.ReplyDelete
People often associate being 'Agile' with specific techniques like daily standups. Great post which reminds the essentials.ReplyDelete
Hahaa, I started reading the post, and had not read the answer of "The answer is H, none of the above." ...I almost started a rant (to post on my blog) about how people sometimes post these "you gotta do X to be agile" and how that is so wrong.ReplyDelete
...fortunately I continued reading before I got to far in my writing. ;)
Great write up. Enjoyed the read.
OK I say (c) Do TDD.ReplyDelete
Give a counter example of someone/ some organisation who you consider to be agile who is not doing TDD.
Hi Mat--thanks for the comment. Well, lots of Scrum shops think they are agile and don't do TDD. (I've seen some of these--I suspect they are in for some serious hurt down the road).ReplyDelete
Note my earlier comment about TDD likely being the differentiator for success on a project.
I haven't seen wild success, but I have seen qualified success in shops where they either chose to do more TAD, or where TDD wasn't so feasible for what they were doing--at least not at the time. In one group at Sabre, they were using their own home-grown GUI development tool that resisted any realistic use of TDD (no potential for polymorphic substitution, for one). They'd be insulted if I told them they weren't agile, even though they were able to continually deliver what their customer wanted.
I accept your example.
I guess where I was coming from is: what people think is one thing, but it's what people do that matters.
The attraction of practices for me is that they very clearly say what you should do.
I like very much your final two bullet points: incrementalism and automation.