Comparative Agility

So how are you doing at adopting agile? You decided to go Agile. You got the training and coaching. Six months have passed. Are you where you should be? Are you excelling in some areas? Do you need to improve in others? How well are you doing compared to your competitors?

To answers these questions, Kenny Rebin and Laurie Williams presented Comparative Agility at Agile 2010. Comparative Agility is an assessment that evaluated multiple dimensions of agility that lead to actionable recommendations. The assessment framework consists of 7 dimensions covering 3 to 6 characteristics per dimension for a total of 125 questions.

The seven dimensions represent broad classifications of changes to be expected of a team or organization as it becomes more agile. The seven dimensions are:

• Teamwork
• Requirements
• Planning
• Technical practices
• Quality
• Culture
• Knowledge creation

Questions are asked to assess a team's score on each characteristic and answers are in the form of:

• More true than false
• Neither true nor false
• More false than true
• False

The philosophy behind the assessment is that organizations do not need to be perfect but they need to be better than their competitors. The assessment is not used to determine maturity levels. It simply answers “How am I doing compared to my competitors?”

Want to find out how you are doing? Take the survey and find out more at www.ComparativeAgility.com

Code Retreat

At agile 2010, Rob Park introduced us to code retreats. This is where software craftsmen from all over get together to do several iterations of pair programming and test-driven development. Developers pair up to try to solve Conway's Game of Life. Each iteration is 45 minutes, followed by a retrospective. Before each new iteration, code is deleted and pairs are swapped. The idea is to experiment and try coding with bottom-up or top down, using no ifs or no loops, etc. Practice the fundamentals of TDD by coding using “TDD as if you meant it”:

1. Write exactly 1 failing test
2. Write implementation code in the test to make the test pass.
3. Create new implementation methods only by extracting out the working code from the test.
4. Create these new methods in the same test class.
5. Extract these new methods from the test class into implementation classes.
6. Refactor as required.
7. Repeat

The rules for Conway's Game of Life are:

•  Any live cell with fewer than two live neighbours dies, as if caused by under-population.
•  Any live cell with more than three live neighbours dies, as if by overcrowding.
•  Any live cell with two or three live neighbours lives on to the next generation.
•  Any dead cell with exactly three live neighbours becomes a live cell, as if by reproduction.

The first generation is created by applying the above rules simultaneously to every cell in the seed—births and deaths occur simultaneously, and the discrete moment at which this happens is sometimes called a tick (in other words, each generation is a pure function of the preceding one). The rules continue to be applied repeatedly to create further generations.

Others have tried retreats using games like tic-tac-toe or Go. Find out more at http://www.coderetreat.com/how-it-works.html or check out the next code retreat coming to a neighborhood near you at coderetreat.ning.com/events

New Year's Resolution: Get Fit Using Agile Workstations

Every New Year, I come up with a New Year's resolution list, and it almost always includes getting in better shape by joining a gym. Unfortunately, I never seem to follow through on it. But how about getting fit at work by using an Agile Workstation?

Recently, Matt, a colleague of mine, setup a make shift standing work station. He stacked some books on top of some boxes to lift up his keyboard and mouse. He also placed his monitor higher up on a shelf. His argument was that this gives him better posture and reduces neck pain and is better for his overall health. Everyday he codes standing up for about 2 to 3 hours and then goes back to a more traditional seated coding position.

This reminded me of a presentation given by Doug Bradbury at Agile 2010 entitled “Walk and Code”. Doug presented data that showed that we sit significantly more and stand significantly less on our work days than on our leisure days. Another study showed that obese individuals were seated on average 2 hours longer per day than lean individuals. Yet another study showed that men and women had a 17% and 37% higher chance of death when sitting more than 6 hours per day as compared to those sitting less than 3 hours per day. When we factor in sitting and not exercising then the numbers jump to an alarming 48% and 95% respectively. So clearly we need to exercise during our work week. But does standing or walking count?

Doug next describes the research done by Dr. James Levine on non-exercise activity thermogenesis (NEAT) which is the calories people burn during everyday activities like walking, standing or even fidgeting. Dr. Levine is studying the effect of NEAT on energy expenditure and overall good health. Simply walking at a slow 1 mph can burn an extra 100 cal/hr. Dr. Levine came up with an adjustable treadmill desk where people can walk and work, stand, or sit. He believes this can help in both health and productivity as people stay motivated, alert and focused. However, this adjustable workstation cost $4000+.

So like Matt, Doug setup his own make shift treadmill/desk by buying a used treadmill from ebay and a desk from IKEA. After 22 weeks he had walked 240 miles (average of 11 mi/week) by just walking and coding!

So are you up for it? I found a treadmill desk add-on on amazon for $400. If this all sounds too extreme and expensive then try replacing your chair with an exercise ball or bicycle, or simply take the stairs instead of the elevators, park far from the office, and take a walk at lunch. Good Luck and Happy New Year!

 

To learn more about NEAT check out http://mayoresearch.mayo.edu/levine_lab/about.cfm

To find out more on how Dough constructed his workstation, check out his blog http://blog.8thlight.com/articles/2010/2/25/walk-and-code

Here are links to studies referenced in Dough's presentation:

http://www.ncbi.nlm.nih.gov/pmc/articles/PMC2783690/
 and http://aje.oxfordjournals.org/content/172/4/419.abstract

Agile Mythbusters

It’s Family Fued meets Myth Busters at an Agile 2010 presentation given by Scott Ambler. Scott explores surveys from Ambysoft and Dr. Dobb’s Journal to expose some myths about agile software development.

Below is a brief summary of some of the survey results:

Busted:

Myth	Survey Says
Agile teams don’t provide up front estimates.	More than 60% present high level estimates using expert analysis or agile estimation techniques.
Agilists don’t do upfront requirements modeling.	About 80% use documented approaches.
Agile teams just start coding.	On average agile teams take about 4 weeks to warm up.
Agilists don’t do upfront architecture.	About 80% use documented approaches.
Agilists don’t write supporting documentation.	Agilists write user manuals, training materials, system overview, and operations documents.
Traditionalist write better quality documentation.	Quality agilists’ documentation is the same.
Most agile teams are collocated.	42% are collocated while the rest are not and about 30% are distributed by a significant distance.
Traditional work better for distributed teams.	Agile works better for both collocated and distributed teams.
Agile is just for small teams.	Even though the majority of teams doing agile are small, there are large teams doing agile as well.
Traditional works better for large teams.	Agile works better for small, medium, and large teams.
Most Agile teams are doing Greenfield development.	Most teams are working and integrating with legacy systems.
Agile doesn’t apply to regulatory situations.	About 30% reported using agile in regulatory situations like for example, SOX and HIPPA.
Agile works better than iterative (xUP) approaches.	Success rates are the same, but agile may provide greater ROI.

Confirmed:

Myth	Survey says
The majority of organizations are now doing agile	About 70% are doing agile.
Agilist test often and test early	The majority is doing TDD, regression testing, and code reviews.
Agile works better than traditional approaches	Agile provides higher quality, quicker delivery, correct functionality, and greater ROI.

The full survey results are available at http://www.ambysoft.com/surveys.

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.

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

Effective Questions For An Agile Coach

Arto Eskelinen and Sami Honkonen gave an agile coaching workshop at Agile 2010. They presented the GROW framework in which coaches can structure effective questions. They started by stressing that sustainable change has to come from inside and as coaches we should not be tempted to give advice but instead create better awareness to help the team take ownership and feel empowered. They recommend favoring what and when questions and recommend avoiding how, who and why questions. The goal is to keep things at an observatory level and not at the analytical level.

The GROW structure provides questions that lead to exploration, aim at descriptive answers, avoids judgment, and avoids an unproductive state of mind. The idea is to look at the goal 1st, then look at the current situation, and analyze what are possible ways to move forward. Finally, make a decision and follow through.

Arto and Sami describe each stage of GROW as:

1. Goal: A description of the desired or ideal state. Make sure it is meaningful and specific and stated in a positive way (use: Catch the ball vs. don’t drop the ball). Ideally, how would you like things to be? What will you get out of it? What do things look like when we get to that ideal state?

2. Reality: A description of the current state? Try to expand coachee’s view of the situation by testing current assumptions, exploring different angles and exposing feelings to different situations. Do not be tempted to just gather data and make a decision. Try to ask questions that lead to moving away from reality and lead to exploring and seeing things from a different angle. What if we have more time? More people? What does the other team see in this situation? What does this solution feel like?)

3. Options: State the existing ideas (how would you solve this?) and challenge the limitations (if this limitation was not there, what would you do?). Also, make sure to discuss “stupid” ideas. These might lead to exploring other interesting angles that were not considered before. Try to have at least 3 options to consider. Keep asking: what else? Until there are enough good option to evaluate.

4. What will you do? The last step is evaluating the options and formulating and action plan. Make sure a timeframe is set, obstacles are removed, uncertainties are cleared and done is defined. What are you going to do? When are you going to start and how do you know when it’s done? Are there any obstacles? What prevents you from achieving your goal? On a scale of 1 to 10, how do you feel about this solution? If they answer 8, then ask what is stopping it from being a 10.

A questions checklist is provided at Sami’s site at http://sami.honkonen.fi/checklists.pdf

Distributed ScrumMasters

At the August DC Scrum user group meeting, David Bland gave an Agile2010 preview presentation on Distributed Scrum and the Art of Digital Facilitation. David recommends trying to use light weight tools even in distributed environments and emphasizes concentrating on the process as opposed to the tool. He also recommends video conferencing over phone/email/IM.

One very interesting point that David discusses is dealing with the Daily Stand up across different time zones. David mentions that the 3 questions have to be re-phrased when working across major differences in time zones so that

1. What did you do yesterday?

2. What will you do today?

3. What’s in your way?

becomes:

1. What did you do today?

2. What will you do tomorrow?

3. What’s in your way?

So due to the difference in time zones, one team (A) is talking about what they will do today where as the other team (B) is about to go home and is talking about what they already did today. David emphasizes that the product owner and scrum owner must quickly address any issues that team B bring up, otherwise, team B will come in the next morning without clear guidance on the stories or priorities and with impediments still blocking progress. Team B will have to wait almost the entire day before the next Daily stand up and before getting any updated guidance from the product owner. Having the product owner address any issues while team B is asleep ensures that team B will be productive first thing in the morning.

You can follow David on his blog http://www.scrumology.net and view the presentation slide deck at http://www.slideshare.net/7thpixel/distributed-scrum-masters-d-bland-agile2010.