In this article, an excerpt of which originally appeared in the Iterations eNewsletter, Rob Myers writes of his experiences with difficult large-scale agile transitions and offers suggestions for avoiding disaster.
"Institutionalized flexibility," I said to my colleagues, only half joking, to describe what it seemed we had been hired to create. We were a group of very experienced agile coaches, hired by a huge client to transform the IT division into a lean and agile one. Only, we never really got to do much transforming.
Many larger software organizations are trying to "go agile," and many are taking this same strategy: Hire a group of agile mentors and coaches and have them help define what "agile" means to the organization. This has obvious benefits to the organization, as they want visibility into what multiple teams are doing. I've seen this done well; I've also seen this model for organizational transitions go terribly wrong. There are hurdles to jump and chasms to cross. Mostly, there are assumptions (and egos) to transcend. Here, I list some things I've seen go wrong fairly early in these transitions and suggestions on how to avoid them.
Remember Portfolio Management
"Which team should 'go agile' first? Do we choose our worst team or our best team? The team that's least busy? A project that isn't really important?"
This type of talk raises a Big Red Flag for me. Does the organization believe that this transition is going to provide return on investment (ROI), or is this some crazy make-work project for bored IT managers?
My answer is simple: What's the most important product under development? (Even for IT, there's essentially some "product," though organizations rarely seem to consider ROI here.) If we believe that agile can help, then we should probably be helping that team. Agile software development is a piece of a whole organizational transition leading to higher quality and better ROI. Before investing in radical changes to the software teams, take a good, hard look at organizational priorities. Ask why we assume that most of the burden of organizational transformation should be given to the development teams.
Don't Define Process without Experienced Feedback
"We need to tell the teams to what standards they'll be held accountable, how we'll enforce that, and how their productivity will be measured, before we have a single team 'go agile.'"
No one would actually say that, right? Yet, it's nearly an exact quote from an IT manager leading one of these transition teams. She wanted to know precisely what the agile process was going to look like, without ever letting a single team try any of it.
The transition team is often led by the IT department manager or director, who has read some books or taken a Certified ScrumMaster course. I think it's necessary that the person spearheading the transition should have some idea of where to take the organization, but if you've hired a gaggle of coaches, please be prepared to receive their input. I recently spent three days in presentations describing exactly what agile will look like for that client. We coaches were there "merely to implement" the changes! We didn't even have to think! (No extra charge for the sarcasm.)
When it comes to planning or modeling, flexibility and detail are inversely proportional. I've found repeatedly that those who try to gather more detail than is readily available end up sabotaging the very project they are trying to model. Of course, the model usually includes a rigorously detailed change-control process, and so remains blameless when everything collapses in a heap on the delivery date.
Focus on Information Retrieval, Not Data Storage
A number of these transition teams want to record "The Process" in documentation, using some industry-standard process-documentation tool.
Blame YouTube, perhaps, but our culture now seems to want to record every bit of information about a topic into some software tool, regardless of how difficult it is to find (or understand) later. There's a reason why Google is so famous/popular/wealthy: Inaccessible information is useless (and incomprehensible information is dangerous).
On one team, we created wonderful podcasts, videocasts, reading material with external links to more reading material, and even quizzes and games. It was all squirreled away in some byzantine tool. One of the coaches would ask another, "Hey, can I take a look at how you described velocity in your workshop?" and we would have to hunt for hours through the process tool's unfathomably twisty little network of hyperlinks (all different).
Why not use a single folder of well-named subfolders of suggested reading/listening/watching? Add to that a reasonable curriculum of courses with prerequisites, a method for training the trainers, and some preliminary coaching. These would have worked better to record information where it was most needed and most accessible: in team members' minds.
Let Coaches Deliver Their Training
I've been asked to "commoditize" course materials, essentially writing down everything I would say and, presumably, every answer to every question I've ever been asked at that point in the presentation, while the image of the squirrel hanging from a bird feeder is projected on the screen. All this, so someone could stand in front of a team of bright developers and testers and read from a script while advancing a slide deck.
The answer is a resounding no.
The PowerPoint (or Keynote) file is not the entire course. Good courses require good instructors who are knowledgeable about the topic and experienced with the course's presentations and exercises.
Of course, having an Extreme Programming (XP) coach teach the XP course for your whole organization doesn't scale well. I'm only one guy, and you have how many developers?! In that case, what I need to do is give the course to potential trainers-people who have some experience with the topic and some affinity for training (or vice versa).
Let Coaches Interact with Teams
On one of my worst transition-team experiences, the coaches were asked not to bother the teams, because they would be distracted and would end up "even further behind!"
Before you start making changes, you have to understand the difficulties the teams are actually having. This is precisely what coaches are for. Management's perspective is critical and interesting, but it often misses root causes buried in the day-to-day details of writing software. A hierarchy of management that assumes all constraints are being communicated honestly and fairly up the chain of command is either thoroughly deluded or wholly enlightened (and doesn't need a transition team).
Let Coaches Interact with Each Other
This really hasn't been a problem on any transition teams, because you can't possibly stop a gregarious bunch of bright geeks from congregating and sharing. What I'm suggesting here is that the whole transition team would benefit from frequent face-to-face meetings, even (or especially) without a fixed agenda.
I've always learned as much from my colleagues as others have learned from me. In every case, I have been pleasantly surprised to find that most agile coaches agree on most process-related things and will discuss areas of disagreement with an open, collegial attitude. It's as though coaches are really "process scientists," for whom debate and the free sharing of new ideas are the default behavior.
So, coaches will need to spend some time with their development teams and some time with the other coaches in the transition-team meetings. What you should get from this is an overarching picture of the transition, some interesting perspectives on the corporate culture, and common impediments.
Don't Micromanage the Efforts
Too frequently, this transition team of world-class agile coaches is assembled, assigned cubes and laptops, "asked" to work forty-hour weeks (regardless of how many hours per week are spent on airplanes), asked to track hours in at least two ways ("so they can be compared"?!), and in many other ways treated as employees. This, by the way, gives us some insight into some painfully wasteful practices that are imposed on the employees. It's no wonder they fall behind or make mistakes, when they have to do things in triplicate so someone else (someone infallible?) can check the copies for errors.
The coaches are responsible for coaching teams, delivering courses, and meeting with and working on materials with the other transition-team coaches. I've never been able to fathom paying that much money to a group and then telling them exactly how they should manage their time. Time does not equal productivity, especially when creativity and thinking are involved. (Software development, like agile coaching, requires both.)
Many coaches will resist conformance to corporate policy, and it may seem at first as though they are being "prima donnas." That may be the case to some degree, but the resistance is also another experiment: If management isn't flexible with us, how do they manage the teams? It's sincerely not intended as a power struggle (though it's usually interpreted that way) but as a learning experience. Note how the really good coaches will ask for something for the sake of everyone on a team-e.g., "Those of us who travel from the west coast would like to fly out Monday and be in the office Tuesday morning."
Don't Silo the Coaches
Are your teams split up by functional disciplines-dev group, QA group, etc.? Agile coaches may have specialties, but they have to have a strong background in all aspects of agile development. Hire enough coaches to cover your needs, but avoid limiting them to their specialties.
If I have a particular "specialty" in the agile domain, it's been test-driven development (TDD). I was recently surprised to find that a client had no interest in having me help the coach who had been assigned to TDD activities, because I was hired to be the QA coach. There is an awful lot to TDD, and he was overworked, whereas I didn't have enough interesting work to keep me engaged. I was busy, certainly, but bored.
Being a specialist as a coach is a career dead end. This isn't the client's problem, but if you want to see whether lean and agile techniques improve quality and value, go ahead and experiment with the transition team.
The type of work we're doing on a transition team is quite conducive to Scrum or kanban planning. Stories could be written for deliverables or coaching, and a coach (or two!) could volunteer to work on an item. This is a great way for the organization's management to participate as product owner.
Train Leadership Early
Ultimately, many of the prior suggestions lead me to this one: Before the coaches are hired, you may want to get yourself and the rest of the transition-team leadership some agile leadership training from a reputable source.
The notions of "servant leadership" and "self-organizing teams" are frequently counterintuitive. They're not what we've been doing, and the terms imply a chaotic, hands-off approach that is not really the case.
I refer to these techniques collectively as "collaborative leadership." As managers, we need to see that the team has the most information and can react most rapidly to a problem. Many of us were once "the hero" on a team and want to do all the thinking and designing, and we want to control everything. We need to see that this heroism is not only counterproductive but usually outright insulting to the rest of the team.
Leadership is responsible for the improvement of the team and the product it creates. Hire people you can trust to do a good job and who want to improve continuously, not those who are the cheapest labor. Software development is an industry of thoughts and ideas at every level of the organizational hierarchy. So, don't be a hero; be an example.
