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 of the sport of Baseball.
This article explains the fundamental principles of this revolutionary approach, the best methodology ever created because it’s brand-spanking new, named “Play Ball!”.
Some people may refuse to “Play Ball!”, in which case you may need to play “hardball”. 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.
Team Roles
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. Play Ball! is a qualisynergistic process, making it far superior to the empirical and prescriptive processes of yesteryear.
Owner
Every application must have a majority stakeholder who benefits from the solutions being developed. They are ultimately responsible for the success of the project. In Play Ball! we call this role the Owner. The Owner controls the funding of the project, approves and may change the makeup of the Team. The Owner 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 Team.
Manager
The project team must have a Manager. In Play Ball! all team members are contributors, including the Manager. We expect a Manager to be a coder roughly 50% of their time. In the rare situation where a Manager is unable to code design patterns in C++, 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 Manager is not so much a classic project manager as a “leader”. As such a key function is to keep the team well motivated. An unlimited supply of Gatorade and chewing tobacco will be provided. Coke and Mars Bars are acceptable alternatives. Occasional slaps on team members’ backsides is encouraged! Check into your local customs before adopting this approach however.
The Manager relies on key technology experts to assist with decision making. These are known as “base coaches”. We realize that Tests should be written before code, so the Test Lead is known as the “First” Base Coach. The role of Third Base Coach is fulfilled by the Developer Lead. Sometimes the Developer Lead believes that continuous integration testing is not necessary. Being of the view that “testing is for wimps”, he may signal to bypass unit testing and steal home. A clean compile may be all that is required. This is a risky and dangerous proposition, known as the “suicide squeeze”.
Team Player
The Team consists of all members of the software development team. Individual Team members are known as “Players”. Everyone on the team is of equal standing. There is no “I” in “Software Development Team”. Team Players are self-organized. All Players are encouraged to sign up for new roles, such as Pitcher. The Manager must not in any case tell the team what to do because Players are in effect free agents in control of their own careers. Team Players that can fulfill more than one role are known as switch-hitters.
The Game
A project release from the initial project inception to termination is known as The Game. Many releases (Games) 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 The Season.
Inning
The duration of the project, or The Game, is split up into 9 periods of time that are called Innings. The old term for Inning was Iteration in RUP, and Sprint in the SCRUM methodology. During each Inning, we pick some requirements to build (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 Play Ball! methodology.
Each Inning is comprised of 30 Outs (each Out corresponds to a day of the iteration). Before attempting an Out, there will be a daily short meeting, known as a Meeting on the Mound (MotM). These meetings are kept very short and all team members must be standing up. All Players describe what they did during the last Out, how they plan to get the next Out, and why they may not be able to achieve the next Out. The Manager typically will facilitate the MotM.
Fans (stakeholders such as end users, senior management, operations staff, and so on) are invited to attend and observe the MotM. 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.
The Pre-Game Show
Often, a major stakeholder, such as a Vice-President will show up to give an inspirational message to the Team. This is referred to as “throwing out the ceremonial first pitch”. Also before The Games starts, the Business Sponsor, known as the Team Mascot, puts on a show for Finance in order to secure funding for the project. This entertaining display is called the “Funding Dance”.
Ok, let’s Play Ball!
Pre-game Warm-up
The game begins by having a planning session to determine the overall planning and scope of the system to be developed. We call this the Pre-Game Warm-up. In this phase, which should be time boxed to 4 hours, the Manager determines the Team Line-up. Developers that did not perform well in previous projects may be benched for this Game, or reassigned to a more trivial or non-agile project, known as the Minor Leagues.
Team Bonding (Collaboration)
We understand that constant collaboration between the Players maximizes productivity and reduces miscommunications. We call this Team Bonding. In the past, this was known as collocation. 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 should hang out, work and bond together in one room. We call this common work area the Locker Room.
The Playbook (Modeling)
Discussion of strategies on topics such as architecture is done in an agile fashion with modeling. As such, we should have lots of whiteboards in the Locker Room.
Entertainment Value (Scope Management)
Regarding scope, of course we can’t make promises to the Fans, as they cannot seem to make up their minds on things. At least we know that the functionality we deliver before we run out of funding is of high business value. It is very important that we set no expectations for our Fans before The Game. We merely tell them that they should pay the “Ticket Price” (project funding) up front and we promise to deliver an entertaining experience.
Steroids (Tooling)
We have found that using collaborative productivity tools, such as those provided by IBM Rational can improve the performance of your Teams. We call these tools Steroids. Players on Steroids can be extremely effective. The Agile community is sceptical about the use of Steroids however.
Game Play
We need to decompose Fairy Tales into tasks to be delivered during an Inning. Each task or work item is referred to as a Pitch. Requirements can be categorized as basic requirements (fastballs), change requests (curve balls), or defects (knuckleballs).
Under no circumstances can the Pitches (formerly known as Requirements) be changed during the Inning, even if we realize that they are incorrect. Focus for the Team is very important. If we deliver the wrong Pitches, we will simply change and redeliver them again in the next Inning.
Delivering too many Pitches in an Inning can result in burnout of your Players. We don’t recommend that the team works too much overtime. This has been referred to in the past as maintaining a “sustainable pace”. We call it managing the “Pitch Count”.
During delivery of the Pitches it is important that the Fans (users) don’t know exactly what is going on. To ensure that this is the case, the Manager will derive an elaborate set of Signs (status reports). Sometimes it may seem that the Fans have figured out the signs. In this case, the Manager convenes a special Meeting on the Mound, where the Signs are changed to keep the Fans confused.
Sometimes we find that the Pitcher (or Architect in the old days) has been delivering poor performance, for instance, 75 mph fastballs. 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 Pitcher to the showers (discussed below) and bring in a new Pitcher to find a better way to deliver the Pitches. This was previously referred to as major architectural refactoring. The trick is to find a new Pitcher to deliver the 200 mph fastball that the newly understood architecture requires. Unfortunately restarting The Game at this point is not an option.
Managing the Game (Controlling and Monitoring the Project)
The end of an inning is an ideal opportunity to determine if you have the right project team. Team members that are not good performers may be removed from the team. This is referred to as “sending them to the showers”. Project Management Offices, known as Umpires, may indeed themselves remove Managers from the game for unacceptable behaviour or performance. This typically follows intense discussions face-to-face. Sometimes the face-to-face discussions are followed with kicking of sand by the Manager in the direction of the PMO.
Sometimes during a Game, it may seem that the project is not going well, and a replanning effort is required. Stakeholders are engaged for lengthy discussions. This is referred to as the 7th Inning Stretch. The Team is content to await the outcome though, as they still get paid as they sit in the dugout. If more funding is required to continue the project at this point, the Team Mascot may be asked to put on an additional “Funding Dance” show.
Metrics
We need to evaluate the results of each Inning in order to improve and adapt for future innings. In the 90’s RUP called these reviews Iteration Assessments. SCRUM then subsequently changed the term to retrospective. So we have renamed these reviews to “Team Meetings”. These Team Meetings are held in the Locker Room.
In Play Ball! a simple metric system consisting of a Box score is used. Fairy Tales that can be compiled successfully at the end of the iteration are deemed to be a Single. Those that have been tested and are of good quality are granted a Double. Those which can be demonstrated to interested stakeholders are worthy of a Triple. If the Fairy Tale was actually demonstrated to a customer, this is a Home Run. In tallying the results, Home Runs must be counted before the other hits, as demonstrations cannot drive in the singles (merely compiled code).
Actual delivery of all functionality to the customer at the end of the 9 Innings is referred to as “hitting for the cycle”, or alternatively a “perfect game”. This is an occurrence often talked about by your Father but which you will seldom see in real life.
If unsatisfactory results are delivered after 5 or less innings, the project may be cancelled “on account of rain”. In such cases, at some point, The Game may be replayed. Of course, we expect the Fans to pay for replaying The Game. We may even raise the Ticket Price (cost of the project) prior to replaying.
If there is a huge backlog of pitches (requirements) yet to be delivered at the end of a 9 inning game, and the Fans (customers) are willing to wait, the Game may go into extra Innings. In the Play Ball! methodology, successful delivery of all the pitches after several extra innings is still deemed a successful game! However, in Play Ball! we expect the Fans to cough up more money for their Ticket. Proper post-game interviews are usually required to explain the Team’s performance however.
Certification
Unless you are a member of the Hall of Fame (a Founder of the Agile Alliance) you can’t possibly learn Play Ball! on your own. To ensure that you are properly trained and ready for the “big leagues”, we offer Play Ball! Certification. Attend one of our “Spring Training” Seminars, to become a Certified BallMaster. Beware of imitations. All of our instructors are endorsed by the Play Ball! League Commissioner, Mark Lines.
Certification Seminars are conducted at major centers 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. Luxury boxes are also available, where unlimited energy drinks are served by ex-OOPSLA booth babes. Additionally Mark 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 to at least ensure that you paid attention during the two days of certification 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 “called up” to the big leagues.
Summary
Seriously though, software development is not a game. As professionals we should not fall for consultantware proprietary processes that merely rehash existing ideas. We should be wary of certification scams that designate us as a “Master” with no actual testing or experience. 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 organization or project.
