Increasingly organizations, having struggled with incomplete agile methods such as Scrum, are looking for a more disciplined, scalable, and enterprise aware alternative to supplement the core agile principles.

Disciplined Agile Delivery (DAD) extends mainstream agile methods such as Scrum and Extreme Programming (XP) to cover the full delivery lifecycle.  DAD addresses many agile fundamentals that are not clearly described elsewhere, such as enterprise considerations, agile modeling practices, and balancing value priorities with the need to mitigate project risks.

The paper serves as an introduction to DAD, and will be followed up with the book on Disciplined Agile Delivery currently being written by Mark and Scott and to be published by IBM Press.

Scott Ambler and I suggest a few minor changes and additions to reflect the modern realities of agile projects in the enterprise.

Take a look here, where Scott has published an updated version of the Agile Manifesto and its supporting principles.  We welcome your feedback!

www.ibm.com/developerworks/mydeveloperworks/blogs/ambler/entry/reworking_the_agile_manifesto14?lang=en

Mark

Co-Founder UPMentors

mark@upmentors.com

I have followed Scott for years, but I still seek opportunities to hear him speak because he always has a few new gems in his talks.  Scott is IBM’s global Practice Lead for Agile Methods, and likes to remind us that most organizations have to deal with realities that the Agile fanatics seem to trivialize or ignore completely.

Namely:

• Many of us don’t have the benefit of co-location, where the entire team works in close proximity (ideally in the same room), with the user representative present at all times to answer questions
• Pair programming i.e. 2 programmers sharing 1 keyboard is an expenditure most management will not endorse
• Delivering a system without moderately detailed requirements (beyond User Stories) is not acceptable for testing, writing training materials, and production support purposes.
• Fixing architecture as you go (i.e. refactoring) without some initial architectural design is not appropriate for large-scale enterprise systems
• Most projects are not completely independent and cannot be built in isolation.  Dependencies and integrations with other systems are required and require some co-ordination.
• Organizations usually have some governance practices in place (such as PMOs, ISO, CMMI) that necessitate a level of bureaucracy and documentation
• Deploying software to users every 1 or 2 weeks is usually not practical in most organizations.  Just migrating software through development, test, system test, user acceptance, production environments is a major undertaking.  Having many projects trying to do this in parallel on a weekly basis simply isn’t feasible.

OpenUP – A full lifecycle agile methodology

OpenUP is the freely available open-sourced version of the IBM Rational Unified Process.  It is an agile kernel of process that includes guidance for all aspects of the software development lifecycle.  It is however, by design, a lightweight process.

What makes OpenUP (as well as other Unified Process variants such as the IBM Rational Unified Process (RUP)) different from other iterative agile methods is some common sense improvements such as:

• Understanding that not every iteration is the same, and thus deserves specific emphasis depending on the business milestones that we are trying to achieve.  For this, the Unified Process breaks a project up into 4 distinct Phases, after which the iterations are named.  In this way, stakeholders can know how the project is progressing.  An iteration name of E2 conveys to a stakeholder that the project is in the 2nd iteration of the Elaboration phase.  This means that the team is maniacally focused on reducing risks by elaborating the requirements and architecture of the application (by building software to validate the architecture).  Other agile methodologies simply number their iterations sequentially.  Being in iteration 4 tells me nothing about the progress of the project towards completion of its initial vision.
• Understanding that architecture is not trivial.   Software architecture encompasses key decisions about the structure of a software system.  Well designed architecture allows us to deliver our functionality against non-functional requirements such as performance and scalability.  Poor architecture, discovered late in a project is not a “refactoring” fix.  Rather, it is usually a “do-over”.  The Unified Process acknowledges that we had better test that we can meet our non-functional requirements in the early iterations of the project before we write thousands of lines of code against a flawed architecture.  Grouping our early iterations into an “Elaboration” Phase communicates to our team and stakeholders that we are focused towards this goal.
• Most agile methodologies have poor lifecycle coverage.  For instance, Scrum contains some good guidance for Project Management, but is silent on Architecture practices.  Extreme Programming (aka XP) has some interesting ideas about coding and testing, but is weak in the area of Project Management.  Grady Booch (an IBM Fellow and thought leader on Architecture) told me that he recently received a call from Kent Beck (thought leader on XP) wishing to discuss architecture.  Grady looked like the cat that swallowed the canary.  Seems other methodologists are realizing that architecture and things like requirements are actually important!
• The Agile community is fractured and has been subject to considerable disputes and infighting.  As I write this, it has just come to light that Ken Schwaber (the force behind Scrum) has resigned from the Scrum Alliance and has renounced the Scrum Certification [1] program that he has benefited from for several  years [2]. As a result, the Scrum community is in considerable disarray, without its leader.  My business partner (Julian Holmes) and I have recently been doing a talk called Process Wars, where we point out that fighting over whose methodology is best is a juvenile sport.  Why throw out your process for the latest fad just because a few interesting and sexy practices (as well as terminology such as “sprint”) have emerged that are not described in your current process?  Much better to stick with your current process, and replace or inject specific “practices” (such as test-driven development) into your current lifecycle [3].

Agile Needs to Grow UP!

Bickering over terminology and this idea that “mine is better than yours” is juvenile.  We should all have realized by now that process must be adaptable to the situation for an organization and project.  This means that project management is not prescriptive but rather requires thinking.  Modern Project management is better described as project “leadership”.  Effective project teams are highly motivated and collaborative.  The days of “command and control” styles of project management are long gone.  An effective project manager facilitates, enables, and gets out of the way.  They are also masters at navigating the unique culture and bureaucracy of their organization.

If you are interested in incrementally improving and evolving your software development process, and swapping new practices for old without ditching your current process, I encourage you to consider using one of the base agile processes (eg. OpenUP, Scrum, DSDM, XP) that are available from the Eclipse Process Framework (www.eclipse.org/epf).  Published templates and guidance are freely available for download.  I welcome your feedback and questions at Mark@UPMentors.com

References

[1] For a parody on inventing new methodologies around sports metaphors see Play Ball!

[2] Many people are surprised to find out that Scrum trainers do not train from the same set of slides.  Trainers must provide their own training materials, which are not subject to reviews for consistency.  Not surprisingly, many people are questioning the credibility and value of the certification program, including Ken Schwaber himself (http://www.scrum.org/faq/certification-and-assessments/why-isnt-scrumorg-offering-certifications.html) .  Also see Ambler’s http://www.ambysoft.com/certification/scam.html

[3] For those of you that ARE comfortable changing your methodology to the latest-and-greatest every few years, we consultants thank you for the opportunity to come and teach you new terminology for techniques that have essentially not changed materially in 30 years.

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.

Sign up today so that you too can knock the cover off the ball!

For more information, or to sign up for our next Spring Training session, contact Mark@UPMentors.com

Fine print:  Season ticket renewals are required to maintain your certification.

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.

About the Play Ball! Thought Leader
Mark Lines is a Co-founder of Unified Process Mentors (www.UPMentors.com). 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 extremely encouraged by the open source Eclipse Process Framework project that allows customers to easily adopt a set of practices that make sense for them without having to adapt an entire new set of branded terminology.  For more information, download the free OpenUP process and practices at www.eclipse.org/epf.

Mark thanks Scott Ambler and Carson Holmes for their input on this article.  This article was also posted at Agile Journal.com.