Howzat! – The new and improved Agile method
Howzat! is a light-hearted perspective on the world of Agile methods.
In a cricket match, “Howzat!” is what the bowling side shouts to the umpire when they believe that the batsman is out.
The article was originally published as “Play Ball!” by Mark Lines in collaboration with Scott W. Ambler and Carson Holmes, and published by the Agile Journal in December 2009.
This cricket interpretation was developed by Julian Holmes over the summer of 2010 for the UK and Commonwealth nations in collaboration with Arun Zachariah.
We all know that terms such as “iteration”, “project manager”, and “daily stand-up meetings” are extremely difficult for software development professionals to comprehend. To simplify things, we have created a better methodology fashioned after a metaphor from the sport of cricket.
This article explains the fundamental principles of this revolutionary approach, the best methodology ever created because it’s brand-spanking new, named Howzat!.
Some people may refuse to accept Howzat! and take their bat home. They may think that a methodology such as RUP, Scrum, or XP is better, but you need to tell them that their methodology is so 2006.
Here is a list of roles for the project team. We generally don’t need to assign specific roles to individuals, as we don’t want to pressure anyone into having expertise in any particular area. It is more important that we all just get along, or collaborate, and that we have the courage to assume that everything will work out in the long run. Howzat! is a qualisynergistic process, making it far superior to the empirical and prescriptive processes of yesteryear.
Every software application must have a majority stakeholder who benefits from the solutions being developed. They are ultimately responsible for the success of the project. In Howzat! we call this role the Chairman. The “Chairman of the board of selectors” controls the funding of the project, approves and may influence the makeup of the Team. The Chairman also is responsible for explaining the suboptimal performance of the team to the other stakeholders or users, known as the Fans. He or she often promises to improve results by spending more money on the project.
The project team must have a Captain. In Howzat! all team members are contributors, including the Captain. We expect a Captain to be a coder roughly 50% of their time. In the rare situation where a Captain is unable to code to design patterns, they must find another way to be productive, such as monitoring adherence to variable naming standards or ensuring that the code is well commented.
The Captain is not so much a classic project manager, but a “leader”. As such a key function is to keep the team well motivated. An unlimited supply of tea and cucumber sandwiches will be provided. Scones with jam are acceptable alternatives. Occasional hugs and slaps are encouraged, however, check local customs before adopting this approach!
Bowler and Batsman
The Captain relies on key technology experts to assist with decision making. These specialist roles assist the teams in completing their tasks. They provide guidance for every ball bowled in line with a greater team strategy as set by the captain. They also have the freedom to make instant decisions that they feel will be beneficial to the team, however the current score always provides an immediate reflection on the effectiveness of their decisions, which may result in their immediate replacement.
Other than the bowler, the remainder of a defending team consists of members known as “Fielders”. All of the Fielders are of equal standing and are self-organised. There is no “I” in “Software Development Team”. However, Fielders are encouraged to sign up for new roles, such as Third Slip and Silly Mid Off. The Captain must never tell the Fielders how to perform their role, as they are in effect free agents in control of their own careers.
Fielders that are also capable as Bowlers and Batsmen, are considered the most valuable members of the team, and are referred to as “All-rounders”. The boldest of Fielders can also apply for the most critical role of continuous integration, the Wicket Keeper.
The Umpire’s decision is final, and it’s this decision that determines a team’s real progress. An Umpire is embedded with the team, and provides real-time support and guidance representing the interests of all the Supporters and any competing Chairmen. Without an Umpire the game can descend into chaos as the teams compromise the rules of the game, make decisions in their best interests, and determine progress in accordance with their desire to appear to be winning.
A project release from initial project inception to termination is known as a Match. Many Matches can be played from the time when the application is initially conceived to when it is eventually retired. The lifetime of the application is known as a Series. In very special circumstances, the lifetime of the application can also be known as “The Ashes” in memory of an application development disaster from the past.
Cricket Scaling Model
A Match can be planned and scheduled in many ways, but is typically defined by the Cricket Scaling Model (CSM).
There are 3 common variants of a Match as defined by the CSM, which in ascending order of size and complexity are:
- Level 1: “Twenty20″ – A short burst of development, normally incremental, providing a significant result at the end of a Series or Tournament.
- Level 2: “1-Day” – A longer development project, that may require a team to perform throughout the day and the night
- Level 3: “Test” – A large and complex development project, requiring greater disciplined, to achieve “Howzat!@Scale”
The duration of a Match, is split up into a number of periods (the number depends on the CSM) of variable length, each of which called an Innings. The closest concept in RUP is a Phase, but Scrum never really had this concept – with the exception of some forward thinking individuals who insisted that Sprint 0 was different to all other sprints.
Each Inning is broken down into a number of short, identical periods, each called an Over. During each Over, a small number of high-priority requirements are selected to develop (User Fairy Tales). These Fairy Tales are a few lines of text. No more documentation is required as any extra requirements that the users wish to document will be wrong and unrealistic to actually implement. Besides, the details of these requirements are obvious to talented software developers that use the Howzat! methodology.
Use Cases and User Stories are clearly less versatile than User Fairy Tales, as so much more information can be expressed once Magic is involved (a complex requirement easily expressed in Fairy Tales, but completely unbelievable in the land of logic).
At the start of an Over, the relevant team members will congregate and discuss the tactics to be employed. In all cases, this meeting is held standing up in the field of play. Prior to each ball being bowled, the Bowler typically performs some last minute grooming and polishing of the Ball.
The Fans (stakeholders such as end users, senior management, operations staff, and so on) are invited to attend and observe these daily stand-ups. Fans may tend to exhibit unsportsmanlike behavior by expressing their opinions vocally during this meeting. However, under no circumstances must the Team pay attention to the Fans’ comments. The rationale for this is that while the Fans are “involved” in the Team’s performance, they are not “committed” to the outcome.
Team Bonding (Collaboration)
Constant collaboration between the team members maximises productivity and reduces miscommunication. This Team Bonding is also known as co-location. It reduces the need for excess documentation and prevents delays in decision making from using traditional communication mechanisms such as e-mail. Accordingly, the Team will typically socialise in a “work-area” called the Clubhouse, but alternate venues include Bars and Clubs.
Entertainment Value (Scope Management)
Regarding scope, a team should not make promises to the Fans, especially when the Fans rarely make up their own minds about team strategy. More important is to deliver the functionality of high business value prior to the funds running dry. It is also very important that a team sets no expectations for the Fans before The Game, merely telling them to pay the “Ticket Price” (project funding) up front and promising to deliver an entertaining experience.
Fairy Tales are decomposed into tasks to be delivered during an Over. Each task or work item is referred to as a Ball. Requirements can be categorized as of good line (functional), good length (non-functional), no-balls (change requests), or wides (defects). When a team led by the Bowler achieves significant success in the delivery of Fairy Tales, he is said to have bowled a Maiden over. However, there is no role for a Prince Charming.
Under no circumstances can the Balls be changed during the Over, even if it is realised that they are incorrect. Focus for the Team is very important. If the wrong balls are deliver in an Over, they will be changed and redelivered in the next Over.
Delivering too many Balls in an Over can result in the burnout of the team. It’s not recommended that the team works too much overtime. This has been referred to in the past as maintaining a “sustainable pace”. In Howzat! it’s called managing the “Extras”.
If it is discovered that the Bowler (often referred to as the Architect) has been delivering a poor performance, for example too many slow-pace balls being hit-for-six, this is clearly unsatisfactory performance and the Fans are justifiably dissatisfied that their system performance requirements are not being met. However, at any time in the Inning, we can send the Bowler to the showers (discussed below) and bring in a new Bowler to find a better way to deliver the Overs. This was previously referred to as major architectural refactoring. The trick is to find a new Bowler to deliver the pace ball that the newly understood architecture requires. Unfortunately restarting The Game at this point is not an option.
Managing the Game (Monitor and Control)
The Umpires make all decisions of to do with the measurement of progress during a game. They make all the decisions as to the success of Balls delivered in an over, especially in the case of when either a Batsman successfully adds a run to the team score (done) or has been deemed to be out (not done).
The team captain will facilitate the team’s overall approach, but each team member also takes responsibility for their performance and techniques.
The end of an Inning is an ideal opportunity to determine if a change to project team is required. Team members that are not good performers may be replaced by those waiting in the clubhouse. Umpires may also suggest the removal of team members from the game for unacceptable behaviour or performance. This typically follows intense discussions face-to-face.
A team’s progress is determined by their current score in comparison to their target score (burn-down) and their current run-rate (velocity) provides a strong indication of whether they will achieve their target within the remaining overs.
Additional team-member metrics are also available. The Batsmen have a Strike Rate and Bowlers a Bowling Averages, both of which are similar to a team’s velocity, but provide all the stakeholders and fans with an insight into their team member’s individual performance.
In the spirit of openness and to ensure that everyone involved in the game understands the true measure of progress, all the current scores and metrics are displayed on a score-board. However, depending on the size of the match, and in accordance with the CSM, the available detailed metrics will vary and may be provided through the use of collaborative and knowledge management tools (TV, radio and internet).
Unless you are a member of the International Process Laureate (IPL) you can’t possibly learn Howzat! on your own. To ensure that you are properly trained and ready for the “Premier League”, we offer Howzat! Certification. Attend one of our “Summer Camp” Seminars, to become a Certified Howzat! Master (CHuM). Beware of imitations. All of our instructors are endorsed by the Howzat! League Commissioner Julian Holmes, and have been trained by the Howzat! Chief Trainer Arun Zachariah.
Certification Seminars are conducted at major centres around the world, in a lecture format. The 2 day seminars are available for £2,000. Seating is limited to 50 Rookies. Cheap Seats are available for £500 whereby we send you a DVD and a certificate. Executive boxes are also available, where unlimited energy drinks are served by ex-OOPSLA booth babes. Additionally Julian will sign books, if bought in quantities of 20 or more (2 signings per order, £100 for each additional).
No actual experience is necessary for certification, nor any testing performed to ensure that you paid attention during the two days of training – the fact that you’re willing to pay for certification is testament enough to your ability. Credit card orders will speed up the printing of your certificate. I am sure that you understand that having our certification instantly increases your batting average on your resume, and increases your chances of being “picked” by the selection committees.
Sign up today so that you too can send a ball into the covers!
For more information, or to sign up for our next Summer Camp session, contact Julian@UPMentors.com
Fine print: Season ticket renewals are required to maintain your certification.
Seriously though, software development is not a game. As professionals we should not fall for “consultantware” proprietary processes that merely re-state existing ideas. We should be wary of certification scams that designate us as a “Master” with no knowledge testing or experience reviews. The days of revolutionary “brand new” processes are long gone. It does not make sense to turn entire methods upside down in the interest of a few new ideas. No methodology is a silver bullet. A more sensible approach is to incrementally adopt bite-sized chunks of process, known as “practices”. These practices can be swapped in and out of your existing delivery processes as new ideas evolve, according to what is appropriate for your organisation or project.
About the Howzat! Thought Leaders
Julian Holmes is a Co-founder of UPMentors. Like Mark Lines, the original author of “Play Ball!”, he has spent far too much time in the last few years discussing the merits of one methodology versus another. However he has recently been encouraged by efforts within the industry to break down methodology barriers and to find commonality in the sensible adoption of disciplined Agile practices for large-scale and complex software project delivery.
Julian thanks Mark Lines, Scott W Ambler, Carson Holmes, and Arun Zachariah for their input on this article.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)