Topic: Agile learning
One of the ways we are introducing agile concepts to our company is through a series of workshops we call "XP Games." In today's event, four teams of five "competed" to deliver stories with predefined "value" to a "market" through three extremely short iterations. Members of the winning team took home a spectacular can of Thinking Putty. The photo shows a participant in today's workshop testing his team's product, a paper airplane, by attempting to fly it into a competing team's product, a house of cards.
While the spirit of collaboration exemplified by the flight test was heartwarming, a more important outcome of the workshop was that an important group of IT professionals was introduced to the basics of agile development in an enjoyable way. Last week's workshop involved the customers and users of a business-facing development project that is starting up in one of our business units. The audience was already in tune with the spirit of agile development, having heard about the value delivered on past projects by some of their peers in management. Today's workshop involved core IT personnel who have very different assumptions, doubts, and needs. They enjoyed the hands-on workshop, but the discussion period that followed was far more serious than in last week's event, and I believe more genuine learning took place for that very reason.
Six Sigma analysts were concerned about how our agile delivery method could supply them with the statistical information they need to perform their analyses. The testing group was concerned with the quality of code an agile development team might deliver to them, and whether the team would provide any follow-up support if there were problems. The problem on our part is that the company has only recently begun to apply Six Sigma analysis to IT projects, and our internal agile methodology has not yet had to deliver anything in that area. Today a Six Sigma analyst complained that she was unable to pull team members away from their work areas to talk about Six Sigma issues. The reason is we treat that as "stolen time" from the project. We learned that we must adapt our agile process to accommodate Six Sigma requirements so that the time needed for that activity is in plan.
Our company has a dedicated testing group with responsibility for "system testing" any new or enhanced applications before they can be installed in production. System testing in this context can mean a wide range of tests, some of which are already handled very well by agile development methods (test-driven development), while others are outside the scope of testing a typical development team can perform, such as verifying that an application can live harmoniously with other applications that share the same production server environment. The testing group was considerably more amenable to agile methods than the Six Sigma analysts. They could see how the relatively solid product delivered by agile teams relieved them of a great deal of routine and mundane testing, leaving them with more time for the kinds of testing that only their group is equipped to perform.
The mock iterations in the exercise allow a three-minute period for iteration planning and story estimation. One of the business analysts used up practically all that time in the first iteration trying to write down every detail he could think of about the story, how the solution would be implemented, and who would do the work. He tried to get the estimates accurate down to the second in advance. He also tried to micro-manage the team. His first questions were "How does this story break down into tasks?" and "What are the [specialized] roles on the team?" These are red flag questions that connote a waterfallish mindset. To his credit, in the second iteration he dispensed with excessive documentation, rapidly made gut-feel estimates, and worked in a more collaborative way. That team delivered twice as much value in the second iteration as it had done in the first. I was especially pleased to see him change his approach, since he has previously demonstrated a somewhat different concept of requirements analysis than our agile teams use.
We felt the session went very well and that people came away with a better understanding of how agile methods can fit into enterprise initiatives, although not everyone was convinced. At least we have made some contacts in the larger IT organization with whom we can talk about the value of agile methods and the challenges in their implementation. It is much more tiring to do a session like this with a skeptical audience than with an open-minded audience; you must have factual, objective explanations and answers for a wide range of concerns, and you must give those answers confidently and without hesitation. Hard or easy, I suppose it is all the more important to address the skeptics than the converted.
