I read somewhere that a large number of software teams think they’re Agile because they do Daily Scrums. Now I don’t like to get religious, and I certainly don’t believe you have to follow some list of Ten Specific Practices to “Be Agile.” But I do think that sometimes companies get a little overly anxious to jump on the agile bandwagon and before we know it we’re regaled with horror stories of agile project failures. But were they really agile? Or were they just doing Daily Scrums?
What should you do if your company is trying to go agile? How can you make sure that –
even if you’re not following some textbook-perfect definition – that you’re actually doing enough of the right stuff to reap agile’s benefits?
Focus on Intent, Not Practices
Agile is a set of values (see: Agile Manifesto), not practices. Of course, we’ve got all these super smart people in software and so we’re continually discovering new practices to help us achieve those values. But here’s the thing:
The practices are tools to help us, they’re not what makes us agile.
What this means is, you can’t just whip out your handy dandy List o’ Agile Practices and pick out 1 or 2 that look easy (“Hey, I bet even WE could handle these Daily Scrum things! And ooh, let’s stop Big Up Front Design too – we’re not very good at design anyway”) and think it’s going to make you Agile.
Instead, we need to focus on agile’s intent – which is defined in the Principles behind the Agile Manifesto. Things like:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Think about what you most want to achieve with agile, and then select some practices that will help you achieve it. This is helpful, because if you know what you’re trying to achieve, then you can evaluate your progress.
If you’re just trying to “be agile” – that makes it a little fuzzier. Are we agile yet? Sure, why not!
So how do you measure if you’re staying true to agile’s intent with the practices you select? I like to think of Lean as the foundation under agile – the principles that explain why it works. And so, I find that Lean provides a good compass for helping us evaluate whether the practices we select are helping us… or taking us in the wrong direction.
The 7 Principles of Lean Software Development
(adapted from Implementing Lean Software Development by Mary & Tom Poppendieck)
The following questions can (and should) be applied not only to the new agile practices you select, but also to the existing practices your team is following. Keep in mind that becoming more agile means not only adopting new, agile practices, but also eliminating the old ones that are holding you back from that agile nirvana…
1. Eliminate Waste – “Add Nothing But Value.” Can you articulate the value your practice is adding to the business or the team? Bonus Question: Is it the best practice your team can do right now to achieve this value? Just because a practice adds value doesn’t mean it’s the right place for your particular team to start.
Daily Scrums, for example, are intended to help the team. If the team finds them a waste of time, that should be a red flag. Maybe the Daily Scrums are being run incorrectly (hint: they’re not status meetings), so you need to start with learning or coaching. Or maybe your project hasn’t implemented the other parts of Scrum (teams with shared goals, sprints with backlogs, definitions of “Done”) that the Daily Scrum is there to support – so you need to start with those.
Until you resolve those issues, ask yourself if the Daily Scrums are really providing value? Or just waste?
» See Martin Fowler’s It’s Not Just Standing Up: Patterns of Daily Stand-Up Meetings for correctly run Daily Scrums.
» See Mike Cohn’s An Overview of Scrum for the building blocks of Scrum that the Daily Scrums support.
2. Build Quality In – You can’t test quality in at the end. Does your practice help ensure the team has what they need to build features right the first time? Or does it result in rework by identifying issues after the developer is “done”?
Acceptance Test-Driven Development, for example, captures the customer’s requirements as executable tests that the team can use to validate the features as they build them. Having exploratory testing in your definition of “done” means issues are identified real time so they can be corrected before moving onto the next task.
Alternately, having devs hand their code over to testers to validate so the devs can move onto the next feature results in rework and an ever growing pile of bugs as the testers find bugs in code the devs thought they were done with.
» See Where Do The Testers Go In Agile?
3. Create Knowledge – “Software development is a knowledge-creating process.” Does your practice encourage systematic learning that enables the team to stay on track and make good decisions? And does it include mechanisms for the team to rapidly respond to this new knowledge?
A number of Agile practices are intended to provide the team with frequent and regular feedback that they can learn from. This includes demoing the product to the customer at the end of each sprint to get the customer’s feedback and regular retrospectives to get the team’s. Also, automated tests that get run with TDD and continuous integration practices to provides rapid feedback on the integrity of the software.
Of course, if no one examines the results of the Continuous Integration tests, or no changes are made as a result of the retrospectives, then it’s clearly failing to meet its intent and so not providing value (see Principle #1).
4. Defer Commitment – Because software is a knowledge-creating process, the more we build, the more we know. The best time to make decisions is Just In Time. Does your practice enable you to defer decisions or clarifying details until the last responsible moment? Or is there pressure to nail things down as early as possible?
For example, User Stories allow us to capture the features we want to implement, while deferring the specifics of how to implement them until we’re actually ready to build them. Once we’re ready, we’ll likely have some of the application built out so it is clearer what the new features should look like. Alternately, Big Up Front Design, where we flesh out all the architectural details and build them up front (because we know we will need them) often results in rework the first time we write application code to use that architecture and discover what we really need from it.
5. Deliver Fast – “Speed is the absence of waste.” What is most interesting is that the Poppendiecks equate “fast” with “quality”. This isn’t about hacking something together as quickly as possible. They say:
“There are two ways to achieve high quality. You can slow down and be careful, or you can develop people who continually improve their processes, build quality into their product, and develop the capability to repeatedly and reliably respond to their customers many times faster than their competitors.”
I don’t know about the rest of you, but the 2nd way sounds a lot more enjoyable to me. So… I think this gives us a few questions we can ask about our practice:
- Does it enable the team to repeatedly deliver working software quickly to their customers? (No waste!)
- Does it promote internal quality to enable the team to sustain it’s fast pace over time, as the code base grows?
- Does it allow the team to do what they feel needs to be done to respond effectively to the customers?
6. Respect People – In her paper Principles of Lean Thinking, Mary Poppendieck says:
“It is sometimes thought that a benefit of good software engineering is to allow low skilled programmers to
produce code while a few high skilled architects and designers do the critical thinking. With this in mind, a
project is often divided into requirements gathering, analysis, design, coding, testing, and so on, with
decreasing skill presumably required at each step. A ‘standard process’ is developed for each step, so that
low-skilled programmers, for example, can translate design into code simply by following the process.This kind of thinking… is the antithesis of lean thinking and devalues the skills of the developers.
Centering on the people who add value means upgrading the skills of developers through training and apprenticeships. It means forming teams that design their own processes and address complete problems. It means that staff groups and managers exist to support developers, not to tell them what to do.”
This is a hard one to capture because there is much that is felt but not seen, but I think we can still glean good questions to consider when evaluating our practice:
- Does it create teams that are able to design their own processes and address complete problems? (Or does it break things down by role and state that only certain people can do certain tasks)?
- Does it push responsibility and decision making to lowest level possible? (Or does it tell people how to do their jobs?)
- Does it give people the training, resources, and support they need to be effective?
- Does it foster pride in workmanship – creating engaged, thinking team members who are continually improving?
Per the Poppendiecks, if you implement all the principles except this one, you’ll “reap only a shadow of the potential advantages.” Yet if you implement only this principle, “you will position the people in your organization to discover and implement the remaining lean principles.”
7. Optimize The Whole – When we optimize for a subset of the whole, we almost always end up sub-optimizing the whole. Does your practice reward people for providing actual business value? Or does it reward them for intermediate steps of the process?
For example, some projects rewards developers for lines of code, or testers for # of bugs found. However, more lines of code means more code to maintain and so will actually slow the overall delivery of features. Similarly, more bugs is obviously working against the organization’s goals of delivering quality software. These types of measurements tend to be the result of teams that are structured to only provide one piece of the value chain (e.g., coding or testing) and so measure the output of those teams and reward for things that suboptimize overall delivery. Alternately, cross-functional feature teams that include all of the members/skills required to provide the required business value can not only optimize the process of developing and delivering each feature, but can be measured and rewarded on this facet as well.
What about the practices you’re following on your projects? Are they capturing the intent of Agile?
