Design Your Agile Project, Part 2

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

CynefinLet’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:

  1. Start a kanban board. You need to see what your actual process is. You need the visuals.
  2. Decide on your work in progress limits, and stick to them, at least for a week.
  3. 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:

  1. Get to done, either in flow or iterations. Why? Because we want to develop working software.
  2. 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.
  3. 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.
  4. 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.

About Johanna Rothman

I help managers and leaders do reasonable things that work.
This entry was posted in agile and tagged , , , , , . Bookmark the permalink.

3 Responses to Design Your Agile Project, Part 2

  1. Hi Johanna,
    I’ve a question which comes to mind though I realise it’s not directly related to the points you’re making: can you explain the differences in your diagram between probe, sense and analyse? At first they seem obvious so maybe I’m over-thinking this, but my context is slightly different.
    When you’re looking at business practice, some businesses simply operate by people falling into rules and processes without them necessarily having been fully thought through. There are some known issues within the business, but not everyone knows what they are or how to articulate them. So when new people or new tools are brought into the business, it’s really tough to explain what the processes are. That kind of meets the top-left quadrant description.
    But what’s the probing activity as opposed to sensing and analysing? Do you mean that you need to push people a little bit more to understand how they operate and that they’ll then be able to explain a process, rather than sensing which is where they won’t be able to explain it but you can somehow work out the gist of it? And that analysing is when a process can be explained but needs to be better articulated for it to be made clear to all stakeholders?
    Can you shed some light on this (without meaning you necessarily need to write another post)?
    Thanks,
    Philippe

  2. HI Phillipe, I’m happy to explain. Here’s a link to the Cynefin Framework, too, so you can get the information directly.

    The idea is that when things are unclear, and not linear, and you need to make sense of them, you may want to probe, to try an experiment. Based on that experiment, with data, you can make good decisions about what to do now for your organization.

    Once you have started to change your organization, you may well be in a different part of the framework. Let me know if this answers your question.

    I urge you to watch the video.

  3. Pingback: New PM Articles for the Week of March 31 – April 6 | The Practicing IT Project ManagerThe Practicing IT Project Manager

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>