The point of using agile is to get finish something valuable-to-the-business quickly, to get feedback. Why? For several reasons, but the first one is so you can change the project’s priorities. The second is so you can change the project portfolio. The third is to get feedback on what you’ve done. Okay, you can exchange one, two, and three if you like. For me, those are the top three reasons to get to done every few days to two weeks. They are right behind each other in priority. Agile is all about change.
This is why every project needs to design its own way to get to done.
If you have a single collocated team, who understands how to deliver value quickly you might be in the situation described in Design Your Agile Project, Part 1.
What happens when you have more unknowns? What if your organization is “addicted” to waterfall and long projects? When you can’t see the people on your project, because everyone isn’t in the same place? When you have a lot of technical risk, such as technical debt? How about when you’re starting a program and everyone is transitioning to agile (oh please, don’t do this). Or, you’re new to agile, and you don’t have training. I have a question: would you drive a car on the road with no training, either?
Rethinking What to do When Your Project or Organization is Full of Unknowns
Let’s discuss the principles of designing your agile project when you have more unknowns. Let’s start with a common problem: an organization “addicted” to waterfall and long projects. And, they’ve heard about this “agile” stuff, and they want to try it.
If you have heard about the many places Scrum has failed, this is classic. Scrum says, “replace your old culture with this new culture.” Wow, that’s a big shift. If you look at the Cynefin framework, you can see that for an organization addicted to waterfall, long projects and big requirements, they are not in Complicated. They are in Complex. Why? Because they have too many unknowns.
Here’s what I see when I do assessments in these organizations:
- Much multitasking to address emergencies.
- No project portfolio management
- Their requirements are so large, it takes them forevvveerrr to release anything
- Because their requirements are so large, and because their releases are so long, that increases the demand for emergencies: patches, interim releases, firefighting.
There could be more. This is enough.
In that case, you want to look at the Cynefin framework, and say, “What does the Complex side of the framework say?” It says we should consider emergent practice. We should not only consider out-of-the-box solutions. We have to probe-sense-respond.
What do we need to accomplish? Getting to working software, at the end of an iteration. Or, in flow. We want a feature, in flow, in a day or two, maybe three. We want completed features, with no leftover wasted work (unfinished features) at the end of an iteration. We want to be able to change what we do after the iteration, or after the feature. How do we accomplish that, from the team’s perspective? Let’s forget labels, and focus on the team.
What’s the First Thing the Team Could Do?
I like to ask, “How little can we do?” Too often, the team has been asking “How much can we do?” Starting with that question helps.
Thinking in inch-pebbles, timeb0xing work, spiking work, all of that helps to learn how to work small.
Sometimes, when we have stories, and we don’t know how to break them apart, we ask, “What’s the first thing that could add value?” Maybe that’s a good question here. You could ask, “What’s the first thing the team can do?” Or, “What’s the first thing we can do that would help us get to done in a one- or two-week iteration?” Or, “How do we finish a feature in flow (kanban)?”
Often, for teams who are in the Complex side of the framework, I suggest these things:
- Start a kanban board. You need to see what your actual process is. You need the visuals.
- Decide on your work in progress limits, and stick to them, at least for a week.
- Retrospect and reflect on those limits, the progress you’ve made and anything else that arose. Where are you, as a team? What progress did you make? What do you want to keep, add, change?
Notice how this is not out-of-the-box agile or lean. It’s a way to start a team moving from the Complex to the Complicated. Once a team has been through the first week, they iterate, keeping in mind these principles:
Let’s Review the Principles:
- Get to done, either in flow or iterations. Why? Because we want to develop working software.
- Keep the iterations short, either one or two weeks. Longer is not better. Why? It’s too long to allow for frequent change. Why? Because we need to allow for change in the project. That way, we can get feedback on the features, change the project’s priorities, and manage the project portfolio.
- Find a way to connect as a team, regardless of how you do so. Real-time rituals are not good if they make everybody crazy from lack of sleep. Why? We need sustainable development, even if real-time rituals are the best.
- Find a way to reflect as a team. Surrogate reflection is not good. Why? How can someone else substitute for what’s really going on in a team?
Where are we now?
Nobody has changed roles. Nobody has changed culture. We are looking at our process, and making things smaller for a while. We are reflecting. All of this in order to simplify, to move from the Complex to the Complicated.
Remember, I have only discussed what I have done with teams who are collocated, who have had problems with too-large features, long waterfall projects, and many emergencies. I haven’t addressed the issues of distributed teams yet. They are next.
I hope you stay with me as we move to part 3.
| Reference: | Design Your Agile Project, Part 2 from our JCG partner Johanna Rothman at the Managing Product Development blog. |
