Where They Apply in Agile Development

When training people in basic Scrum, we often talk about the Five Levels of Planning. I always put it in what I call the Product Context (organizational strategy and product portfolio). Luke Hohmann, inventor of Innovation Games, calls these levels the Planning Flame:

Innovation Games can be used for some of the planning activities that are within the Agile/Scrum boundary. Mike Griffins gives some examples at LeadingAnswers. During the class, Alan Shalloway worked with Luke to quickly prototype a new online game for affinity estimating of user stories based on Steve Bockman’s Team Estimating Game. Use of the games in the team context are always applied to achieve convergence – finding consensus and keeping everyone going in the same direction.

The more valuable learnings for me, though, were the use of these games at the outer levels of the flame, market research, for which they were originally designed. This is where real customers are involved in helping organizations develop and refine strategy, new products to realize those strategies and new feature areas for existing products. Luke expressed a goal of bringing the Agile mindset to product marketing. One motivation is that Agile teams can build product faster than traditional market research takes to define products. So the games provide ways to speed up the research process – gaining qualitative data more quickly and identifying targets for quantitative data gathering more efficiently.

Innovation Games used at the outer layers can be applied for either convergence or divergence. Often the players have very different perspectives. They may be from different market segments, different customer organizations, different geographical areas. The games are used to discover the values and possible actions based on those perspectives. This may lead to multiple responses rather than a single aggregate response (ex. a line of products vs. a single product or a roadmap based on successive target markets). Awareness of divergence can even lead to whole new product ideas (“You use our product to do what?”).

Emergent Value

While it was both fun and interesting to learn about the games and game framework and to play some of them, I was also gifted with a challenge to my belief that collaboration is best done in person. (See Tips for Distance Training). Luke told the story of how a client asked for the games to be playable online in order to cut down on travel costs. After some discussion and work the online games emerged. And guess what? You can do things with the online versions that you can’t do with the physical versions. You can reach more people and more time zones. Some synergies of physical presence are missing but observation of co-located games gave guidance to some interesting designs in the online versions that lead to other kinds of synergies. And you can get different kinds of information from the two versions. So, perhaps counter intuitively, technology brings a different set of capabilities and  opens the games up to an even wider set of possible uses.

Other Applications

The games can be used for other purposes beyond market research. They can be used to solve allocation problems, design questions and prioritization puzzles - many things that benefit from multiple points of view. If you take the class, you will begin to see the wide range of applicability.

One especially intriguing area of application is in public debate and discourse. Imagine if you could share your opinion on civic matters in other ways besides the polling booth. Take a look at GamesForDemocracy.org to see where that idea is going.

Recommended for Agile Coaches

Innovation Games are well defined and have years of road testing. The book gives clear instructions on how to plan and execute a game. They can be done alone or combined into “cocktails” to drill down to a solution and be “hacked” to suit specific circumstances. They hold a huge promise for finding out about commonalities and differences in how groups of people think. They come with many business success stories and are beginning to be applied in not-for-profit areas. I highly recommend that you give them a good look.

A recent coaching client is a small company that wanted to transition their entire development department to Agile. It was an easy sell to the applications people, harder to the maintenance people (until I told them about Kanban). The ones in the middle were the mainframe programmers. This company is in insurance, an industry that has lots and lots of legacy backend systems.

I have met mainframe programmers in my Agile travels before who were resistant to an Agile approach. The reasons are many but mostly based on the constraint that legacy systems take longer to change and mainframe systems in particular are not amendable to Agile development practices.

In this particular case, I was pleasantly surprised to see interest, even enthusiasm, at tackling a project using the Agile framework even though the systems involved were RPG, COBOL and CICS. I want to summarize the experience by describing what Agile practices we implemented, what challenges we faced and what successes we saw.

Standard Agile Practices

• The team was small: 3 developers and a QA specialist also playing the ScrumMaster role. There was a dedicated Product Owner who was a Business Analyst familiar with the problem to be solved.  The sponsor, a Product Manager, was also highly involved.
• The team chose a 3-week Sprint length based on unfamiliarity with Agile in general , the observation that tasks and stories might be larger (in hours required) than in other projects and the realization that team members could not cover for each other well due to specialization.
• Detailed design was incremental.
• Features were prioritized and done in priority order.
• The Product Owner and end-users were involved on a daily basis.

Challenges to Standard Agile Practices

• The developers were highly specialized in their technologies. Cross-training was limited by a steep learning curve. Yet there was some.
• Automated testing was considered to be impossible. We brainstormed this at great length. At the unit level, well – what is a unit in COBOL? It is a structured language. Programs are huge, monolithic. Compiles take a long time. It is tough to run just part of the code. Testing is done by stepping through a debugger and fiddling with variable values in memory. This does not lend itself to automation. We looked into screen recording and playback, which is possible, but the resulting scripts are extremely fragile. In the end, the relative cost of investigation was too high for the short project timeline.
• Having a small team did cause some delays when people were absent.

What We Got

• During backlog estimation, elaboration of a story was short-circuited when it became apparent that the business was asking for something that was technically impossible within the downstream host system. The story, initially estimated to be quite large, was simply dropped. The Product Owner was not concerned at the loss of the functionality given the essentially infinite cost of the story even though it had originally been prominent in the original project BRD. Cost savings were estimated at about $10,000.
• While planning Sprint 2, another large, high priority feature evaporated when the PO realized that the work done in Sprint 1 resulted in a sufficiently useful solution to the goal of the story. The feature was a real-time update of data from one backend system to a front end on another system. User testing of the first sprint product showed that batch updates had sufficient value and were much simpler to implement. Poof, another $10K saved.
• The team felt that these savings would not have been realized in a traditional project approach. The requirements would have been baked into a design document and implemented as well as possible without any discussion with the Business.
• Changes in other requirements resulted from continuous review by the PO (“Now that I see it…”) and were not an issue for the developers .
• The project was short, but still completed so quickly compared to pre-Agile expectations that the team stayed together to implement another set of features out of the scope of the original BRD and budget.
• The team, some of who were skeptical, had fun and enjoyed the success. The Business was very pleased as well.
• The pre-Agile estimate of work was 2 years elapsed time in this highly multi-tasked environment. The Agile project was completed in less than 3 months thanks to a focused effort. Time value of money, anyone?
• Thanks to executive story pruning by the Product Owner and Sponsor, the product shipped earlier than even the original Agile estimated release date.
• Management had a greater knowledge of status without having status reports simply by attending the daily stand-ups.

Conclusion

So, did Agile work out well for this all-mainframe project? Indeed it did. Even though it was not full XP in technical practices, using a Scrum approach and Agile principles resulted in both earlier ROI (cost savings for end-users) and lower cost (thanks to evaporating features). Oh, and everyone had fun doing it - always a good sign.

I took an Improv workshop at Agile2008 and really enjoyed it. I have been looking forward to a chance to do it again. This session was led by Todd Sedano from Carnegie Mellon. We did a number of cool things. I wanted to share one in particular because it was simple and, for me, powerful. It was called Gift Giving.

“I have given you a box. It is wrapped and has a gift inside. Take it, lift it, examine it. Now tell us what you find.”

We had a moment to look over our invisible boxes. One-by-one we described our boxes and the gifts inside. Mine was white with a black and orange ribbon. Inside was a Willie Mays autographed baseball glove and a can of neatsfoot oil. While the other people in the session were describing their boxes, I took out my glove and began pounding it quietly to soften it. I was having memories of childhood, when a new glove was a rare treasure. Back in the day I would spend hours working in neatsfoot oil to keep my glove soft. It was a special aroma, the oil and the leather.

What brought that image to mind? It must have had something to do with being in San Francisco and having seen a few Giant’s games this year. Doesn’t matter. It was fun.

The real gift, though, came from what Todd said about how he uses the exercise. Whenever he goes in to a consulting engagement, rather than feeling uncertain about meeting the unknown challenge ahead, he pictures a Gift Box waiting for him. He anticipates that the job will have something for him beyond what is written into the contract.

And so it is with Agile Coaching. We go into an engagement with our toolkit ready, but we never know for sure what we will find. It is easy to feel some concern that we might encounter something outside of our experience. This is not unreasonable - every place is unique, every person is unique, every team is unique. So it takes trust in our skills to go in with confidence that the job can be done before knowing for sure what the job is. Believing that the job will also have a gift for us, and not knowing what that gift is, makes the job all that more interesting. And it can help increase our confidence. Each engagement brings new learning, honing of skills and broadening of horizons. All of that makes us better at what we do and more valuable to our customers.

So now when I step into a coaching situation, part of my preparation is to wonder “What gift will be waiting for me here?”

Deep Knowledge of Agile

An experienced Agile Coach has a solid grounding in both the practices of Agile and the principles behind them. It is easy to try out some of the practices that you read about in a book. It is not so easy to get full benefit from them. Practices like, for example, short iterations, pair programming and frequent customer involvement are most successful when applied in concert. Each are an expression of one or more underlying principles such as constant collaboration for greatest communication, rapid feedback to adapt to changes and learning from experience. A Coach knows not only what works best in a particular situation, but why. A Coach knows what to look for when results do not meet expectations. And a Coach knows these things from experience, not just from reading a book.

Broad Experience

A professional Agile Coach has worked with more than one organization. They have encountered similarities and differences. By hiring a Coach, you have access to the learning experiences of other companies that can be valuable when you have puzzles to solve and new opportunities to leverage. Your questions may have answers that are not visible from inside the corporation. There may be questions that your organization does not even know to ask. A Coach can help you to climb the Agile learning curve faster.

Impartial Perspective

Organizational change is not easy. Participants have their own individual and departmental viewpoints and agendas. It is challenging for an insider to achieve a perspective that spans across the organization and through its hierarchical layers. And even if a person can gain such an expansive view, it may still be challenging to convince others to trust that perspective. An external Coach is impartial, having no history within the company. A Coach’s job is to make the team and the organization better.  The business’s success is the Coach’s success. That agenda favors no specific individual or department.

Access to Resources

Collaboration is one of the cornerstones of Agile development. The value of collaboration applies to Coaches as well as practitioners. Agile Coaches have a wide community of practice through social media, professional organizations and conferences. If a Coach encounters a new situation, help may well be available from the greater community. Practitioners can tap into that group knowledge on their own, but an active Agile Coach will have more efficient connections and a better sense of how to find solutions.

Coaching Competencies

Some people view Agile change as technological –adopting different practices and tools for creating software. Some people view Agile development as a new process model – a different way to manage projects. We have learned that it is both of these and, even more challenging, an organizational change. Current practices, expectations and conventions may require modification. In each of these areas, people will be learning and adapting. An experienced Coach has competence in training, facilitation, communication, mentoring and team building. These skills may be present inside of the corporation, but it is unlikely that any one individual has them all as well as the domain knowledge necessary to guide the Agile transition.

Reinforced Learning

Agile software development is typically introduced through training. Individual training, such as Certified ScrumMaster and Product Owner classes from the Scrum Alliance (www.ScrumAlliance.org) is typically 2 days long.  Agile team training may take longer, 5 days or more. In either case, new information and skills are retained and understood best through application. Having a Coach available to reinforce the new learning will help to protect the investment made in training. A study done at Baruch College in 1997 illustrates this dynamic with data showing a productivity increase of 28% among people who had attended executive management training classes and a productivity increase of 88% by people who also had follow-on coaching.

Conclusion

Agile Coaching is an established profession. Consider hiring an experienced Agile Coach to help with your transition.

Author note: I am a Certified Scrum Coach, a designation defined by the Scrum Alliance in 2007 to create a consistent, verifiable definition for the role of Agile Coach. My coaching services are described at www.moonriseConsulting.com.

I did get one insight out of this exercise that I find useful in my teaching and coaching now. I average about two original thoughts per year so I am hanging on to this one with both hands. We started with the question “What does it mean to be done?”. This question was surprising difficult to answer. I closed my eyes, made a plea to the Muses, reached back into my life experiences of things completed in jobs, hobbies, school, chores. I gathered up the feeling that was common to them all. And this emerged:

“Done” means that I don’t have to think about it anymore.

This post is done.

The convention that has evolved in the Agile world is the “Definition of Done”. The DOD is project specific and can change as the project proceeds and as the team and organization mature in Agile practices.

I recently worked with a team that was challenged in meeting their commitment in the early Sprints. This is not uncommon but this particular team was impacted in a couple of ways that could have been avoided:

• The DOD was defined by the Product Discovery team before the development team was even assembled. The Product Discovery team was a group of leads and the Project Manager. They meant well by setting the bar high for “doneness” but it was too high for the people who ended up on the team. The DOD required skills that were not present on the team (TDD and automated testing in particular).
• The team was not involved in defining the DOD, but they were expected to comply with it. This is a Big Red Flag. Commitments made for you by someone else are harder to keep.

And, of course, this high hurdle on Day One set off a positive feedback loop (aka. vicious cycle) of pressure on people who now needed to learn too much new stuff in too short a time. People under pressure do not think faster or better. So the pressure grew.

I did my best as a Coach with Limited Influence to relieve this pressure through negotiations with Those Who Watch Impatiently. I also did a fair amount of mentoring in TDD and automated testing. It was great fun for me but not so much for this new team. We made good progress towards confidence by creating some space for the learning and working toward the high bar in small steps.

Definition of Done is an important tool but, like all tools, it must be used smartly. And, like all things Agile, it is subject to inspection and adaptation.