El Kahuna

After finding the 5 Whys of the previous post a colleague reminded me of “The 5 Questions”.  We used to work on a team that was responsible for rolling out and training people on the use of Agile Methodologies.  During that time I stumbled across a set of questions that I found useful when working with Agile teams.  These questions are directed at someone who is playing the role of Coach (in Extreme Programming (XP) parlance) or Scrum Master, but they are useful regardless of what methodology your team is using.

1. What task are you working on? - Part of any style of planning process is to create a list of things to do.  As a developer I should be concentrating on completing one of those tasks.  Unfortunately is is far too easy to follow a rabbit trail that leads you down a path that isn’t progressing the task you are supposed to be focused on.  This question allows the coach to determine if the person is maintaining the necessary focus.
2. Where is your pair? - As a proponent of Agile, I believe in Pair Programming.  It was something that we coached and stressed.  The purpose of this question is simply to find out if the person is off working on their own.  If they aren’t pairing, why?
3. Have you written a test yet? - Another important practice in Agile is the use of Unit Testing.  Whether your team has decided to try Test Driven Development (TDD) or not, a well structured umbrella of Unit Test is important to any software effort.  The purpose of this question is to reinforce the notion that any code written without covering tests (we can argue about spikes later) is not moving the task at hand forward.
4. Did you talk to the customer about this task? - Even if you “think” you know all about the problem being solved, it is a good practice to talk to the customer before you begin a piece of work.  Often time the customer has refined their understanding of the problem (which is a nice way of saying that people change their minds) between the time it was originally discussed and the time that the team begins working on a task.  By talking to the customer and reviewing the acceptance criteria, and maybe even prototyping with the customer, you make sure that your thinking is in line with the customers.  Who know, you might not even need to complete the task.
5. Can you describe your design? - Communication is quite possibly the most important values of any team.  If the team is communicating then the coach should be able to ask any member of the team to describe the design of the system being developed and get very similar pictures.  The purpose of this question if for the developer to be able to describe how the task at hand fits into the overall design of the system.  This is critical to keep the organic growth of any system in line with the overall objectives.

I love this.  The 5 Whys.  I’ve used this technique for years without knowing that it had a name or that it was associated with Toyota, Kanban, etc.  It just seemed like the right response to (usually) very talented people who come into work and say something like, “We should use ‘X’”  My rule was that if I could get to the 5th why without hearing, “I don’t know, I thought it would be cool”, then it was probably an idea worth investing in.

Use this technique with your teammates (or yourself) the next time someone has a great idea.

Can it survive the 5 Whys?