Thursday, January 8, 2009

Can you manage conflict in an Agile way? [John Levy]

A company I know initiated an agile software development project in 2007 using Scrum. They put together a very competent crew of developers, isolated them in a corner of the building, put them under a manager who understands and is an advocate for Agile frameworks, and let them start. There was only one hitch -- their business counterparts were 750 miles away. Nonetheless, the team overcame this obstacle by daily telephone conferences, online file sharing, and frequent visits by the business folks to the developers' location. Development continues with frequent demonstrations of working software.

This year, a larger, existing group of developers and website design people in the same company decided that all their problems could be solved by going Agile. The list of obstacles, however, is quite a bit longer:

1. The development managers and some of the developers are also 750 miles away from business and website design people.
2. Some of the developers and QA people are contractors at a location a few miles from the development location.
3. Other developers are offshore -- in India.
4. None of the developers or managers have experience with Agile / Scrum teams.
5. The development work is dependent on a number of vendors' software packages.
6. The physical work area at the company's plant is not conducive to Scrum team interactions.

This may seem like a lot to overcome. In fact, it may look like a fool's journey to take on implementation of Scrum in this environment.

But we're still not through the whole story. Here are a few more issues:

7. The server software environments for development and for QA are not the same as in the operational systems.
8. The QA people are constrained by company rules from accessing the live, operational system.
9. Attempts to allocate budget for infrastructure improvements are consistently thwarted "because they won't increase business."
10. Frustration at the low throughput of finished projects has led to a lot of conflict between the business people and the development people.

So now let's consider a few questions about what to do if you're an advocate of "Agile Management" ....

Would you take on the Scrum training for this company? If so, would you expect the company to see positive results within a year?

Where would you begin to tackle the productivity problems at this company?

If the CIO asks you what should be done to make development run more smoothly and more productively, what would you say?

And finally, how would you justify (to the management) spending dollars on infrastructure improvements?

Yes, I am involved with this company, and for now I'll tell you only that I'm addressing issue number 10 first -- the conflict between the business people and the developers. I believe that establishing a basis for cooperation between people who need to work together is always the first order of business. Is this "Agile Management?" Yes, of course. The top priority is what's most important and most valuable; and getting conflicts resolved is at the top of my list of value-producers.

______________________________________________
John Levy, PhD http://johnlevyconsulting.com
Managing product development for speed and innovation

2 comments:

Anonymous said...

John -- excellent scenario. Thanks for helping to get this blog rolling!

This is my first-ever response to a blog, so please excuse any gaffs I may make here in contributing my two cents.

In my view, the greatest challenge with converting to an Agile process is generally getting the necessary buy-in. Agile approaches can be dramatically different from the standard waterfall approach and the strengths and weaknesses of the two camps vary greatly. It's extremely easy for someone involved to escalate fears/concerns up the ladder and have executive management throw on the brakes if they aren't fully committed. One particularly painful way this can happen is for upper management to allow only a few of the Agile processes to be adopted (generally, those most similar to some waterfall processes). Because some of the Agile processes are so interdependent, adopting only a subset of them, if not done knowledgeably, can lead to disaster (with the unfortunate consequence of many deciding that the Agile process didn't work).

So the first and most critical step is getting solid support for the Agile process from the management of all departments affected (e.g., Engineering, Marketing, QA, etc.). In a startup, full commitment from the CEO is typically critical.

Now, to address the listed items and questions.

I would also start with #10, "Frustration at the low throughput of finished projects has led to a lot of conflict between the business people and the development people." This is typically the core problem: poor throughput (and/or quality) and/or misaligned expectations. In addressing this issue first, John can get the attention of the necessary people. "How can we fix it?" can be answered with, "Agile." In other words, leading with this item can help get the necessary commitment to try Agile.

At the significant risk of oversimplifying, I would say that the following items of the 1-10 list are of particular interest.

1,2,3: Distance
4: Scrum experience
6: Physical work area

#3 (the lack of Scrum experience) is very significant, but can be overcome with training.
#1, 2 and 3 (distance issues) may simply have to be worked around.
#6 (he physical work area) might or might not be addressable, depending on the details; if not, it, too, can probably be worked around.

The other items are problematic but would also be significant in non-Agile environments.

5,7: Heterogeneous environments
8: Organizational
9: Process

To respond to John's specific questions.

QUESTION: Would you take on the Scrum training for this company? If so, would you expect the company to see positive results within a year?
ANSWER: I would definitely train the company on Scrum. After getting buy-in from the top, I would initiate this as the next priority. It is a somewhat complex area since it is often useful to ease the company into the new set of processes in a phased manner, over time. However, it's critical that some of the key strengths and challenges of Agile be understood at the very beginning. For instance, the short-term iterative approach of Agile can make it hard for engineering to define a long-term architecture and for product management to commit to a long-term roadmap (there are reasons for this, but they need to be communicated). People need to understand these things up front. I would *definitely* expect positive results within a year.

QUESTION: Where would you begin to tackle the productivity problems at this company?
ANSWER: I'd change the definition/deliverables cycle to an Agile-type schedule (e.g., monthly) as soon as possible. It's also important to note that, more often than not (in my experience, at least), the core issue with "productivity problems" often has nothing to do with the approach (Waterfall vs. Agile). Rather, it is simply that the product delivery expectations are unrealistic. In that situation the challenge is adjusting the expectations to make them realistic -- otherwise, no amount of process changes are going to yield success.

QUESTION: If the CIO asks you what should be done to make development run more smoothly and more productively, what would you say?
ANSWER: Describe the problems as I understand them and then describe how converting to an Agile approach would address them. This would be part of the activity of getting executive management to commit to Agile before initiating the changes.

QUESTION: And finally, how would you justify (to the management) spending dollars on infrastructure improvements?
ANSWER: I'd identify which infrastructure issues exist already and which new ones would be introduced by converting to Agile. Then I'd propose a phased transition to those necessary to support the Agile processes and provide target dates with the benefits associated with each phase. I'd raise the non-Agile infrastructure issues in completely separate discussions so as not to confuse the two.

Barry

Anita said...

Oh my, John. What an amazing collection of challenges. Each one is one my list of "why projects fail".

I'm resisting my natural instinct to tell you to run away screaming from this project, and instead I'm pretending I'm Kimberly (who would take on any challenge).

It seems to me that if you can get Agile truly (I mean TRULY) adopted on this project, it would be the best early indicator of whether this project could be successful at all. The reason for this is the “early” feature of Agile.

As you collect the project requirements, you’ll test the collaboration and review process to see if you can get the entire cross-functional team truly working together.

As you create the increments, you’ll test the development teams and see if they can work together. Plan the increments to bring the vendors’ packages in as soon as possible. To not do this will guarantee failure. If these don’t already exist, this becomes a very high risk. Getting these packages in house must be a high priority.

As you test the increments, you must plan for (and insist) on testing each increment in all environments (development/QA, operational). This will reduce this technical risk (which is large and shouldn’t be underestimated). If management refuses to set up the operational environment for this testing, I would question their commitment to the project’s success.

Agile itself will be a challenge on this project, and so I would use the Agile training as the first test of whether this project should proceed. If you get everyone to attend formal Agile training (and I wouldn't attempt an Agile project without formal Agile training), consider the first test passed.

As for your specific questions – I’m not sure how large your project is, but I’m guessing it’s pretty big and multi-year. I’ll try to give some advice on each question.

Positive results within a year? Within a year, if you have cross-functional participation and cooperation, if management has agreed to your terms, and if you have the first few scrums under your belt, you will know if you are on the road to success or disaster. If it looks like disaster (after that year), then it will be, and I’d recommend stopping the project.

Tackling the productivity problems at this company? When management buys-in and agrees to follow a solid process, kicks in some money for tools and training, then the team members will see that they are serious. It will help get their cooperation in the improvement effort.

If the CIO asks …? See above answer, for a start.

How to justify to management spending dollars on infrastructure improvements? This needs a written cost/benefit analysis, but it doesn’t have to be rocket science. It will, by its nature, be based on assumptions and estimates, and you could use this project as a case study on which to base the numbers. I’m not sure exactly what kind of infrastructure improvements you have in mind (equipment, tools, training, process, etc.), but as you do your analysis, but sure to show their linkages and dependencies (i.e., the numbers to back up doing one may not hold up unless you do another).

These are tough issues, but there’s a way to deal with each one. Dealing with them will take patience, planning, a good process, leadership, attention, and knowing when you’re not being supported in making your goals.

Anita Wotiz