Transitioning into an Agile Project

Question

We will be working on an exciting new project that slightly blurs the line of PM and Consultancy. This organization is eager to introduce agile for supporting their existing applications, but they have not found the appropriate agile processes to support them.

The first stage of this project involving us to wear a hat of a consultant who will advise the senior management the appropriate agile processes, and later on be the actual PM in the project.

We have different agile background, some of us have some involvement in Scrum, and some of us have involvement in XP. We all agree - and you guys are open to debate on this, that at the heart of introducing agile is a notion that : "Every organization has its own specific processes that become the bottleneck in their software development group. We take note that the bottle neck can also exist outside the software development group, but in the client instead"

We decided that the first thing that we should do is to identify these bottlenecks, and put in place the appropriate agile processes, educate everyone on our plan, get their agreement, and kick off the project.

In the first phase, our approach is to conduct focus groups, or one-to-one interviews between managers, software developers to know what the bottlenecks are. Have anyone do similar exercise before? Does anyone have any good techniques to spot these bottlenecks?

Answer 1

I think that before identifying bottleneck you should identify a "bottle" - what exactly you're going to achieve. "Agile" is a very broad and vague definition. Instead of promising your client "to make his organization totally agile" try to give him answers:

• What metrics/measurements will be introduced
• What are current values of these metrics
• How these values will be changed after your consulting
• How they will affect client's business values
• What is the forecasted ROI? In other words, how much will it cost.

Answer 2

I envy your remit!

I'd start by working out what the flow of work looks like from initial idea through to a fully released and supported product. Spend some time meeting and sitting with each of the teams along that pipeline and identify what their inputs are (what material/information they need from upstream teams) and what their outputs are (what they hand off to downstream areas).

Try to find out how often people wait for inputs and/or how big their queue of inputs is. If they already measure this, get the data, if not, see if they'd be prepared to start measuring queues.

It's important to actually visit and sit with people. It builds trust so if you later have suggestions that affect an area they're less likely to resist. Most critically, it lets to see how the work actually flows rather than relying on people telling you how the work should happen if processes are all followed (which is what you tend to get if you just email/speak to people in a meeting).

You've now got a pretty good map of how the work flows through the system and hopefully some data on where the biggest queues are. I'd start by looking at the largest few queues and seeing what impact that queue is having on the team at the queue and the upstream and downstream areas.

Some great books that look at these concepts more:

• The Goal - Eli Goldratt
• Freedom from Command and Control - John Seddon
• The Principles of Product Development Flow - Don Reinertsen