Accelerating Your Organization’s Agile Adoption

Bryan Campbell and Robbie Mac Iver gave a talk at Agile 2010 about Agile Adoption. They started out by discussing how acquiring a skill requires time, practice and a mentor. They then defined 7 stages of agile expertise based on the work of Meiler Page-Jones:

• Innocent: unaware of agile techniques
• Aware: aware and seeking to learn more
• Apprentice: ready to apply their skills to a real project
• Practitioner: leap from classroom projects to those of real world complexity
• Journeyman: agile techniques embedded natural way of working
• Master: range of real-world project experiences; ability to teach these techniques to Apprentices
• Researcher: sharing knowledge with a broader community; champion to further extend the benefits of agile techniques

Next they identify the risk and challenges from moving from one stage to the next. Moving from innocent to aware can happen fairly quickly. Moving from apprentice, to practitioner, to journeyman requires more effort and will take longer; however, it is during these stages that you get the greatest increases in productivity. Reaching the master and researcher stage will take even longer and not many companies see value in having employees reach this level. The tipping point is usually when more than 50% of the organization is at the practitioner level and more than 75% is operating at the apprentice level.

Next Bryan and Robbie discuss the J-curve effect where an apprentice struggles in adapting his new skills to real situations and reverts back to old techniques. This causes a dip in the skills progression which results in a decrease of productivity and a risk that crossing to the next level might stall or eventually fail. This is where having access to an experience coach or mentor is crucial to overcome the J curve and achieve a successful agile adoption.

Bryan and Robbie recommend 2 techniques that can help accelerate agile adoption:

• The Breadth approach focuses on developing a solid foundation of best practices and refining them over time. This works best in the move from innocent to aware, or from practitioner to journeyman.
• The Depth approach is focused on a more active engagement/participation of mentors on a real project. It is more of a deep dive and is best for crossing the J-curve from apprentice to practitioner.

They next cover agile leadership guidelines. They recommend

• Addressing culture and values first and then practices will generally follow
• Working in ways that embrace change and adjusting methods to fit the project
• Creating teams of advanced citizens to ensure team dynamics
• Influencing team decisions by setting movable boundaries

Bryan and Robbie wrapped up by presenting each group with different real life scenarios and having each group discuss different ways of resolving them.

The scenarios can be found at http://www.robbiemaciver.com/documents/presentations/A2010-Agile%20Maturity%20-%20Problem%20Scenarios.pdf

The presentation slides are available at http://www.robbiemaciver.com/documents/presentations/A2010-Agile%20Maturity%20-%20Presentation.pdf

The Curious, Present, and Empathetic Agile Coach

At Agile 2010, David Spann and Gil Broza gave a workshop on agile coaching. The workshop involved several exercises to stress the importance of presence, curiosity and empathy.
They started out by emphasizing the importance of good posture when engaging a client. Posture subconsciously sends message of energy and others will check in or check out based on that. When standing, stand in with right foot in and always feel your toes. When sitting, sit up straight and also feel your toes. If things are not going your way, know your presence and adjust accordingly. They also reminded us that standing up is a power high energy position. It means you are involved.
Next, David and Gil define empathy as repeating in your own words what was said, mirroring hand gestures, and not trying to pass judgment at the moment of interaction.
Finally, curiosity involves asking questions and figuring out the context. They wrap up by recommending several books:
Presence Based Coaching
Leadership Dojo
Coaching with NLP

Look Before You Leap - Agile Readiness Assessments Done Right

At Agile 2010, Gerry Kirk and Michael Sahota led a workshop on Agile assessments. The format was more like an open space discussion where Gerry and Michael started out by asking the group to come up with some objectives for having an assessment:

• Tuning of training according to needs
• Maximizing value and effectiveness of training
• Revealing constraints, building trust
• Finding out motivations for going agile
• Figuring out pain points
• Deciding where to focus
• Understanding fears smell
• Understanding the state across of the organization
• Defining success
• Figuring out where the organization is currently at and their current practices
• Setting the right expectations
• Making the transition owned internally

Next Gerry and Michael suggested a format for the assessment and define 4 parts: Preparation, Data collection, Analysis, and Recommendation and next steps. They suggested that each group brainstorms and comes up with ideas for all the parts. They started us out with the following examples:

• Prepare: 12 question survey from break all the rules
• Data analysis: Lean value stream mapping with x-functional work group to show process and lead time
• Analysis: From interviews write stickies for culture, technology, product, people, process
• Recommendation and next step: Meet with key decision makers and workers to create a transition backlog

Next, each of the groups tried to come up with their own ideas but non where as detailed as the ones provided by Gerry and Michael. Below is a summary of what the teams came up with

Prepare:

• Prepare checklist for us and the client
• Conduct outside research on organization
• Learn the organizational structure
• Identify sponsors and stakeholders
• Find a champion
• Prepare non attribution statement
• Present readiness and process group
• Establish point of contacts for all logistics
• Conduct survey to figure out current process
• Conduct Schneider culture survey
• Conduct a survey to gauge urgency for change and current company health
• Compile a list of various articles, videos on agile introductory topics
• Present a related experience report
• Get organization aware of agile through training

Data collection:

• Meet the team and the leaders
• Observe the team at work and identify the different roles
• Identify and document current agile practices
• Identify and document current agile non practices
• Document the current approach for managing and organizing work
• Document the goals of the movement to agile from execs to team members
• Create a baseline metric

Analysis:

• Determine waste in value stream map
• Perform Kano analysis on techniques
• Try to identify potential pilot project and pilot team
• Look for feelings by team
• Look for variation in perspective
• Distill interview into mindmaps
• Look for often mentioned bottle necks
• Perform futurespective (innovation game)

Recommendations and next step:

• Create statement of work on improvement goals
• Create cross functional transition team and backlog
• Establish target metrics
• Create training plans
• Create transition timeline with goals
• Have a workshop for executives to share findings
• Establish ground rules and agreement
• Perform retrospective to improve future assessments

This is all very much a work in progress and Gerry and Michael are going to continue to gather ideas and eventually publish an assessment guideline.

So what's it like to be a generalist?

Project Vital Signs

At Agile 2010, Stelios Pantazopoulos gave a presentation on project metrics entitled “Project Vital Signs”. Stelios starts by pointing out that IT has lost trust and credibility with the business due to projects having a poor track record of success, poor visibility and ROI that is hard to quantify. Projects are over budget, late, or fail all together. To restore trust and credibility, we need to show how and why a project is on track throughout the project’s lifecycle.
Stelios, suggests applying the metaphor of medical care and their use of “vital signs” to help form a holistic view of the state of the project. In medicine, doctors go over the patient’s medical history, review lab test results, look at vital signs, and then use their experience to diagnose the condition and recommend a treatment. Stelios defines vital signs as simple, quantitative, near real time metrics conveyed via a chart published to a location and easily referenced by all. There are 5 vital signs that need to be monitored. 4 are based on PMBOKs Scope, Quality, Schedule, and Budget. In addition, Stelios feels that monitoring the team’s overall health is also very important.
The 5 charts are:

1. Scope Burn Up: Backlog burn up chart (stories in each state vs. time) that tracks schedule and scope to show expected delivery date. Number of stories or story points are be tracked. Stelios mentions that if you have a big enough back log, tracking number of stories worked well for him.
2. Current State of Delivery: Backlog Scrum board that tracks scope and team and shows real time state of delivery. Tracks the state of each story and who is working on which story.
3. Budget Burn Down: Burn down chart (total $ vs. time) that tracks schedule and budget to show remaining dollars.
4. Delivery Quality: Dot Chart (bug category vs. time) that tracks schedule and bugs to show overall quality. Bugs are categorized into 4 categories:
1. High priority/High severity
2. High priority/Low severity
3. Low priority/High severity
4. Low priority/Low severity 
At the end of each iteration, each bug is represented as a dot in the corresponding category. Ideally, as the schedule nears release date, most bugs should fall into the low priority categories. Stelios also mentions that alternatively one can track automated test results as opposed to bugs.
5. Team Dynamics: Chart (state vs. time) that tracks the state of the team and schedule to show the state of team at different stages of delivery. The state is collected in the retrospective by asking team member to have a secret vote on where each feels they are on the Tuckman model of group development (forming, storming, norming, performing). Similar to the delivery quality chart, each team member’s opinion is represented as a dot in the corresponding category.

The 5 project vital signs are combined to create a project dashboard that is placed on the wall for high visibility. Stelios wraps up by going through different sample scenarios and demonstrates how the dashboard provides a holistic view of the project. He then diagnosis the project and performs what if scenarios for different treatments showing the state of the project before and after treatment.

Stelios provided the slide deck for the presentation at http://projectvitalsigns.com/

Agile Coaches Dojo

At Agile 2010, Rachel Davies gave a workshop on Agile Coaches Dojo. The Dojo was modeled based on the developers dojo where a bunch of developers get together to solve a challenging programming problem. The group collaborates to solve the problem and along the way learn new tools and techniques.

In the Agile Coaches Dojo, instead of solving a coding problem, coaches solve a challenge faced by an agile coach. Rachel recommends the following format for the dojo:

A seeker presents a specific challenge to 3 coaches. The coaches each take 5 minute turns to discuss the problem with the seeker and provide advice. Meanwhile, 2 to 3 observers take notes documenting interesting perspectives while a facilitator ensures the dojo moves along smoothly. At the end of the discussions, the group has a 5 minute retrospective on what went well in the dojo and what did not.

The Agile coaching Dojo gives participating coaches a chance to see how other experienced coaches tackle the same situation based on their own personal style and reactions to different context.

Building a More Accurate Burndown Using Range Estimation in Scrum

At Agile 2010, Arin Sime gave a presentation on how to build a more accurate burndown. Arin started by asking how long does the drive to work take? Various answers were given (15 minutes, 8 minutes, 45 minutes, 20 to 30 minutes). Arin pointed out that some estimate were precise but might not be accurate (for example 8 minutes, but what if we hit traffic?). Other estimates were less precise but allowed for more accuracy (20 to 30 minutes). He mentions that single point estimates are a problem because we tend to be overly optimistic and use different methods or have different biases. He then presented a scenario and asked if we can build a CMS website within 2 weeks. Some answered simply yes or no while other asked for more info and then gave a range of 3 to 4 weeks. The point was that even though a range was a better answer, the original 2 weeks presented in the question created an anchor for the response and any answer will be close to that range.

Arin moves on to discuss Scrum and mentions how Scrum uses planning poker to generate a consensus group estimate, and how using story points ensure relative estimates. However, estimates are still a singe point. Range estimates recognize uncertainty, alleviates our tendency towards optimism, incorporates risk, allows for better financial projections, and better informs our bosses and clients.

Arin then demonstrates how he uses range estimates. Basically, he still uses planning poker with his team, but each team member now raises 2 estimates. The team still discuss differences between low and high estimates, but eventually settle on a range between the 2 estimates. On the sprint burndown chart, both the high and low estimates are tracked. A 3rd estimate (the 2/3 of range estimate) is also tracked. Now the chart shows an ideal burndown and a low and high deviation limit. The actual burndown should fall somewhere in between this range

Arin warps up by warning against some pitfalls of using range estimation. He mentions that not everything can be estimated using a huge range otherwise you will lose all credibility. Try to meet the ideal estimate and don’t use the high estimate as an excuse to miss deadlines. He also stresses on always using the range estimate and not slowly moving back towards relying on the single 2/3 estimate.

Arin provided the slide deck for this presentation at http://www.slideshare.net/o19s/range-estimation-in-scrum