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.
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.
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.
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”.
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.
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.
The duration of the project, or The Game, is split up