Process Technology

Making Agile work outside of Product Development – it’s still about the people

A few weeks back I wrote this post on How to make Agile work for Product Development. As a build on that post I’d like to share how I’ve used Agile to successfully deliver ‘Business’ challenges outside of Product Development.

Consider this scenario, there is a problem in the business and despite many efforts to solve the problem the situation continues to get worse. I’m sure you’ve come across this before and it normally happens when a lot of people are involved in solving the problem but they aren’t working for a common purpose, they are trying to resolve the symptoms rather than the cause, and very often their efforts cancel each other out or make the problem worse.

So how can Agile help?

Well the Scrum process works just as well in this situation as it does for Product Development; here is the process I’ve used:

  1. Establish a Framework: Break the problem down into its component parts, identify the deliverables and the priority of each deliverable. Sound familiar, yes? This is our backlog.
  2. Identify Clear Focus and Accountability: Chunk the backlog up into a number of time bound sprints, identify clear accountability for who’s going to lead each sprint, who’s going to work on each sprint, and what needs to be accomplished in each sprint.
  3. Trust the process and the people: Let the sprint team get on with it. If you’ve given accountability to the right people then you don’t need to do their job. Instead provide support and help them by removing any barriers and keep distractions away.

I know what you’re thinking… Does, this mean you’re abdicating accountability? Absolutely not, you still have accountability for the entire thing and you need to be there if the sprint team need you. Does this mean that you won’t know what’s going on? Absolutely not, Scrum is an open process… anyone can drop into a sprint meeting to hear what’s going on, but remember not to interfere if you’re not part of the sprint team.

As with Product Development, It’s a good habit for the sprint team to use their Friday review meeting for more formal progress update, i.e. if you have a short project with one week sprints, this will be the end of sprint retrospective meeting, if you have two weekly sprints then this would be the mid sprint review, and so on. Personally, I favour Friday as it’s a good way to celebrate progress at the end the week and to retain focus on what the plan is for the next week. This is also a good technique to kill two birds with one stone, e.g. if you need to provide visibility to an external or higher level sponsor.

This really is a very simple and effective process which I’ve used this countless times to very good effect. However, as with Product Development, the formula for success is all down to having a clear framework that everyone understands, a strong focus always, and good people who are willing to take accountability.

There is of course a fourth ingredient to the formula that I haven’t mentioned here, anyone like to tell me what it is?

4 replies on “Making Agile work outside of Product Development – it’s still about the people”

A clear understanding of the problems you’re trying to solve, or vision of the results you want to achieve.

I definitely agree that Scrum (or similar) can be used effectively for projects outside of Product Development; it’s no more tied to software development than is PRINCE2 or Waterfall (although you know what I think of the latter!)

That said, it’s (obviously?) not ALWAYS the right choice. In Schwaber and Beedle’s original book on Scrum they actually advocate running the process-change project as a Scrum project itself. I’ve tried that with mixed results, to be honest.

I think Scrum works well for projects of the sort you describe, Stu, but is much harder to use effectively on large programmes/initiatives with undefined endings (e.g. culture change)

For messy or wicked problems I think it’s far more effective to use creative techniques to understand the problem and design an appropriate solution – then use Scrum for the bit it’s good for: implementing the changes.

Thanks for the comment Steve,

I would agree with you that scrum is not always the right choice. However, scrum aside I’ve been pleasantly surprised how many times you can fit this simple three step approach to just about anything.

Also around undefined endings… to be honest, this is still a pet hate of mine, I hate not knowing the ending. So many people I meet think blind faith or divine intervention will step in and save their project… This never happens, they fail every time.

Something I learned long ago is you have to control the controllables…

Which is probably worthy of another post in itself.

> how many times you can fit this simple three step approach to just about anything.

Absolutely. Especially the third one!

As for defined endings, I think the trick is in the level of detail: not enough and you’re in big trouble, but demand too much too soon and you risk breaking your point 3…

I suppose you could boil the whole of “management” down into “knowing what it is you need to know, and what you don’t”!?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.