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.

The Waterfall Manifesto

In a recent blog entry entitled Beyond the Manifesto, I discussed the different agile related manifestos that came out after the Agile Manifesto. Today, I found one that I had missed entitled the Waterfall Manifesto by the Waterfall Alliance!

It states:

Our experience has taught us to value:

• Processes and tools over individuals and interactions
• Comprehensive documentation over quality software
• Contract negotiation over customer collaboration
• Following THE initial plan over responding to change

Check it out at http://www.waterfallmanifesto.org/

Defect Reduction Cocktail

In a recent presentation, James Shore introduced the Defect Reduction Cocktail to continuously produce quality software. The equal parts of the cocktail address 4 types of errors:

• Programming Errors: Test driven development, pair programming, energized work.
• Requirements Errors: On site customers, customer examples, Bring testers forward, customer reviews.
• Design Errors: Slack, simple design, incremental design, refactoring, fix bugs promptly.
• Process errors: root cause analysis, fix your process, exploratory testing.

Find out more at
http://jamesshore.com/Blog/Alternatives-to-Acceptance-Testing.html
http://jamesshore.com/Agile-Book/no_bugs.html

Java vs. Net

So which platform is better? Is it Java or .Net? The answer might be in this new movie coming soon to a theater near you. Check out the trailer.

Code Leaders and Beautiful Teams

At QCON London 2010, Roy Osheroveshared shared his experience of working on great teams.

He discussed things that good teams do:

1. Automate everything: Configuration, deployment, builds, and tests.
2. Test and buy the right tools: automation tools, bug management, source control…
3. Throw out the wrong tools.
4. Master your tools: shortcuts, macros, refactoring.  A good exercise is to try working without a mouse for a couple of hours.
5. Get quick continuous feedback from tests and CI, from customers, from peers
6. Show big visible process: Have a whiteboard.
7. Communicate without meetings: stand-ups, pair programming, peer code review, team rooms, and visual progress.
8. Visual board: Create a metaphor for your system and put inside it the components of the system and color code each process.
9. Code reviews and test reviews before every check-in.
10. Build by feature and not by layer.
11. Small team, same room, big feedback.

Then Roy covered things that good team leaders do:

1. They are bottleneck ninjas. Sit in the same room as your team. Be aware of the conversations going on and problems that arise and step in when necessary.
2. Grow people with integrity.
3. Remove obstacles and help the team on how to remove their own obstacles. Ask them to find solutions.
4. Connecting it all.

Roy recommends that these be used as a check list and be reviewed on a daily or weekly basis so that the team and the leader continue to improve.

How about a Game of Ping-Pong at Work?

That's ping pong programming of course. It's a combination of Test Driven Development and Pair Programming. The 1st developer writes a test and then passes the keyboard to the second developer who writes enough code to make the test pass and then writes a second test and passes the keyboard back to the 1st programmer who in turn writes enough code to make the second test pass and then writes a third test and so on. This keeps both developers involved and focused. What do you think? Ready to give it a try?