Article summary
Okay, that’s a bit grandiose, I admit. But I often see tweets or posts about how people don’t “get” capital-A Agile. Tweets like this and this point out common faults.
Everything they say is technically correct but not especially useful. Pointing out all of the not-get-its in the wild won’t make people “get it” better, so these sentiments are useless. I’ve thought a lot about this problem, and I’ve tried to assemble a bit of a theory of Agile that would provide a framework for improvement. I think I’ve got a start at it.
The Real Problem
Agile isn’t about “doing practice X.” It’s about finding practices that meet the needs of your team and project, then doing *those* things. But finding the right set of things to do is hard.
Optimally, you would have practices that all complement each other, that aren’t redundant at all, and that make use of the skills your team has. The right set of practices is going to depend on many different factors, and there is no “one size fits all” process that will be perfect for you. Jeff Patton explained why this is the case in his post “Is User Experience Relevant Where You Work?”.
Finding a Solution – for Your Team
Navigating the alphabet soup of tools and practices that are available is hard. What we need is some organizing principle—some way to organize and categorize all the practices. If we had such a rubric, that would also be useful for evaluating our team’s own practices and finding gaps.
I propose this as just such an organizing principle: practices can be arranged on a spectrum ranging from most concrete (i.e. code, user stories) to most abstract (brand values, user interviews.) This is sensible because it’s what I want out of a user story: both the “what”—concrete details (e.g. “send an email when event X happens,”) and the “why”—motivations, intentions, goals (“I want to be first to click the link so I can claim the job.”)
I’m looking for which of these questions a given practice will answer:
- What does the page look like?
- What is the broader workflow it fits in?
- What persona is using this?
- What is their personal objective?
- What is the business objective here?
- What brand values play into this?
I’ve found I can work on stories most effectively when I have all that. I don’t need a ton of detail, but I do need *context*. That context is going to help me decide whether I should find a third-party library, whether to build some framework code, or whether to upgrade a component. I do development work day-to-day, so that’s the place I most frequently see the value from having that information. But this knowledge is useful at all levels of the project:
- Understanding your users’ goals is critical for marketing to the right groups.
- Understanding the business objectives lets you set release targets and responsible budgets.
I think almost any decision about your project is easier if it can be made in context.
Evaluating your Current Processes
The idea of a spectrum of abstraction levels feels right to me… but it’s a bit hard to apply. Try this instead:
Write down your current practices. It doesn’t have to be a perfect exhaustive catalog, but try to capture the big picture of what your R&D team is doing.
Then, for each practice, write down when you last used it. I don’t think that the frequency is a cause, but I do think it correlates almost perfectly: more concrete practices (like spending an afternoon writing code for a story) are going to be narrowly focused on small areas of functionality, whereas a paper prototype for a complicated workflow might take a week to put together but describes months of implementation effort.
Here’s what that looks like for my project:
- Implementing a user story. Last done: today.
- Implementing a unit test. Last done: today.
- Pair programming. Last done: today.
- Automated testing. Last done: today.
- Demos to project stakeholders: Last done: 12 days ago.
- High-fidelity visual design. Last done: 4 weeks ago.
- User interviews. Last done: 5 weeks ago.
- Release planning. Last done: 3 months ago.
It’s clear from looking at that breakdown that we’re very focused on the short- to medium-term. We might have a problem taking a view further down the road. We might want to complement our existing practices with a brand experience workshop to get a broader picture, for example, or maybe use some other practice to understand what our project’s long-term goals should be.
What to Look For
In my opinion, you should have practices at each of these rough cadences:
- Daily – For example, development practices
- Weekly – Things like your Scrum meetings
- Quarterly – Practices involved with setting release targets, budgets, team assignments.
- Annually – Review and revise long-term project roadmap.
If things are going well and you can identify a formal practice in each cadence, then you’re probably mostly there. You’ll be able to get some incremental improvements in some certain area, but if you’ve already covered the breadth then there probably are no more easy wins.
If things are going poorly and you don’t have practices, then I hope this exercise helps illustrate where the weak areas are.
The most interesting and challenging categories are the other two:
When everything is great but we have no process
If you fall into this bucket, I don’t think it invalidates this approach. Rather, it points out that you have some part of your team handling the other responsibilities informally. It means your lead developer is probably talking to users, building a product roadmap, and selling it to management. That’s not a bad thing!
But it presents a risk because you are depending on something that you’re not controlling. If that person leaves or otherwise can’t work, then this work will stop. You won’t see the effects immediately, but after a few months, you’ll start to see things drift as the project floats on rudderless.
When things are going terribly despite the practices
This one is the hardest to fix.
If you’re in this bucket, then I think you probably have a culture problem rather than a technology or PM problem. People are going through the motions on the practices that have been prescribed but not using the artifacts to drive their work. It’s hard to offer specific advice because organizations can be dysfunctional in so many ways.
Let’s Talk
I’ll be presenting this idea in a talk at Michigan Agile & Beyond. If you agree and want to hear more, or if even this seems to be utter horsehockey, come find me later this May and we’ll talk!