We’re All in This Together – Part II

Keep the final goal in mind

In my previous post, I wrote about the strategies that can help players win the cooperative board game Pandemic.

The first strategy is keeping the final goal in mind.  In the game, this refers to focusing on curing diseases, while managing ongoing distractions and remembering that even though eradication of disease is possible, it is not a condition of winning.

What is the final goal in software development?

Successful completion of a software project has been defined many times with slight variations.  It generally comes down to delivering software that meets the client’s needs, on time and on budget.

How can we possibly focus on the final goal in a long software project, with an expected completion date that is months (or even years) away?

There are so many things between here and there:  distant, intangible goals; the client who is justly nervous after waiting and waiting with no concrete results; dealing with mundane, but necessary tasks; and the desire to take every future possibility into account.

The answer is surprisingly straightforward:  Come up for air.  Frequently.  Look around, regain your bearings.

Plan.  Do.  Check.  Adjust.  And share.

This is certainly not a new idea.  It has a long history in manufacturing processes and its applications are numerous.  Variously known as PDCA, PDSA, the Shewhart Cycle, and the Deming Cycle, the basic idea is to establish expected short-term results, work towards those results, and regularly compare actual outcomes with the expected ones.

Each cycle is an opportunity to reflect and refocus.

How does this approach address our long software project and its inherent diversions?

Distant, intangible goals

This process takes abstract goals and turns them into achievable, measurable milestones.  Plan, do.  At each milestone, come up for air:  Check, adjust, share.

It is important to be realistic about what can be accomplished in the established time frame, and to reliably deliver and reflect on the results.  It takes time to tune this process.  As the project progresses, you will get better at predicting what can be completed by the next milestone.

There are many methods of identifying, scoping, and prioritizing pieces of work.  I’m a big fan of planning poker because it encourages discussion, involves the client, and helps to bring out important details.  I’ll delve deeper into planning poker in a future post.

The nervous client

The client who is involved in planning and who frequently sees results is reassured that the project is going as planned.  Involve the client in creating milestone goals and during reflection.  Those realistic milestones that you establish and dependably deliver do a lot to increase the client’s confidence.

Jeff Patton’s Mona Lisa example is a great explanation of how iterative development improves our software development and delivery cycle.

At each delivery point, retrospectives are a huge help in identifying what went right, what went wrong, and how to proceed towards the next milestone.  They are also a good reminder that everyone is working together to reach the final goal.

Mismanaging the details

Does every software project include boring housekeeping tasks that no one wants to do?  Probably.  Will the project suffer if they’re not handled correctly?  Very likely.

This problem takes a couple of familiar forms:  the first is partial completion of features and the second is getting bogged down repetitive detail.

The intermediate milestones we’ve created help us with both of these issues.

When we put off parts of a task until later, the results are predictable.  First, we have to remember to go back and complete the part that was left out.  If we do actually get back to it, we have to remember why we took the shortcut in the first place AND the better solution that we had in mind AND maybe even how it was going to apply to all the other similar issues that we knew we were going to come across later.

Incomplete solutions usually indicate that the author knows there’s a better way, or doesn’t have enough information to really complete the functionality, or wants to complete a portion of the work and revisit the details later.

This is the time for some honest reflection:  is it really necessary to move on and come back later, or is doing it right just less interesting than doing something else right now?

When we gloss over unfinished details, we have to own up to this when we reach the milestone checkpoint.  If we truly can’t complete the item, it is carried over very visibly to the next milestone, or a new task is created for the portion that isn’t complete.

The second problem, getting bogged down in tedious activities, may sound familiar: repeatedly doing mind numbing error-prone fixes, configurations, and adjustments.  Now we’re not ignoring the issue, we’re addressing it!  Over and over again.  We feel like we don’t have time to create a better solution, when we know we need to step back and improve the process.

Repeated, tactical fixes and ad-hoc configurations like these can slow down work in every project cycle.  A good retrospective will uncover this type of issue and highlight the fact that a better solution should be a high priority activity.

Covering all possibilities and YAGNI

It is a natural tendency for clients to ask for all conceivable features, just in case they might need them later.  Again, the strategy of delivering and reflecting regularly should go a long way towards gaining the client’s confidence in a software solution that fulfills their needs without the added bulk of unnecessary features.

Sometimes extra complexity comes from a developer trying to cover all the bases by adding extra features that they’re sure the client will find invaluable.  This is often referred to as ‘gold plating’.  The developer has spent time creating features that the client hasn’t asked for and possibly doesn’t even want.  Meanwhile, required features are being delayed.

Another development pitfall is the temptation to make the software design flexible in ways that are just not warranted.  Certainly, all code should be easily maintainable and extensible, but the desire to cover all possible future needs may result in a framework that is too complicated or carries too much overhead for the actual requirements.  To this, many experts say: YAGNI! You Ain’t Gonna Need It.

 

Stop, reflect, refocus.  Frequently and honestly.

In my next post, I’ll write about being aware of your teammates’ special abilities and combining them with your own.

We’re All in This Together

What cooperative games can teach us about software projects

Recently, I have been playing a cooperative board game called Pandemic.  Like some other cooperative games, there is no competition between players.  Either all players win the game by reaching an objective, or everyone loses if that goal is not achieved before a given event occurs.

I tried to resist, but it got me thinking about software projects.

In Pandemic, four diseases have broken out around the world.  The objective is to cure all four diseases before a pandemic causes global disaster.  Throughout the game, players move between cities on a world map, using their common abilities to treat infections, build research stations, and discover cures.  In addition to this common set of skills that all players have, each player has a distinct specialty that gives them increased capacity to move, cure, research, and share knowledge.

Action Card

One of the things that’s great about this game is that it is not easy.  While there are adjustments that can be made to modify the level of difficulty, none of them makes the game dead simple.  What fun would it be if you brought this game home and beat it, right out of the box?

What really got me thinking were the strategies required to win the game:

  • Keep the final goal in mind
  • Know your teammates’ special abilities and combine them with your own
  • Share knowledge
  • Invest in infrastructure
  • Know your limits
  • Prepare for setbacks

The end

Keep the final goal in mind

While players are working towards curing diseases, there is an ongoing distraction:  infections are spreading.  Treating infections does nothing to help cure a disease, but ignoring infections can result in an outbreak.  With enough outbreaks a pandemic can occur.  The players must keep their focus on curing diseases, while at the same time being aware of small problems that turn into bigger problems.

Likewise, it’s possible to go right past the goal of finding a cure by eradicating a disease.  But while someone is eradicating one disease, another uncured disease could be getting out of hand.

Specialists

Know your teammates’ special abilities and combine them with your own

Each player in Pandemic is assigned a specialty.  Depending on the specialty, a player has increased power to move, cure, research, or share knowledge.  It is a real advantage in the game to be aware of your strengths and the strengths of others, how they are best used and combined, and to recognize opportunities to do so.  While one player builds a research station, another can quickly move there, and another can share knowledge to efficiently cure a disease.

But players also shouldn’t use their special abilities to the exclusion of their common abilities.  Sometimes it’s more advantageous (and urgent) to combine abilities that all players share.

Not today

Share knowledge

In the context of Pandemic, sharing knowledge involves passing cards between players so that one player has enough of a given card type to cure a disease.  The catch is that the player giving up the card has to use one of their limited number of moves to do so.  It is possible for a single player to independently collect the required cards, but in most cases, it is faster to reach that goal by sharing cards.

South America

Invest in infrastructure

Research stations serve at least two purposes in Pandemic:  players may move to cities with research stations more quickly than they can to other cities, and a player must be in a city with a research station in order to cure a disease.

At the beginning of the game, there is one research station on the board.  Players may build a research station during their turn, but there is short-term sacrifice involved:  they must use up a move and give up one of their cards to do so.

Know your limits

At the end of each turn, the player draws two cards.  If this draw takes the player over the set limit of seven cards, they must reduce the size of their hand by discarding the excess or playing special event cards that they hold.  Throughout the player’s turn, they are aware that this choice will be coming.  They can pass cards to a teammate – share knowledge – to help bring them closer to curing a disease, while a the same time creating space for the cards that they will be adding to their own hand.

Hazard

Prepare for setbacks 

Throughout the game, infections are slowly spreading.  But epidemic cards and outbreaks result in the proliferation of a disease, causing sudden multiple infections and the spread of disease from one city to all adjoining cities.  Players must plan ahead so that when (not if) these events occur, they are manageable.

If players move steadily towards the goal of curing the diseases before epidemics and outbreaks cause infections to get out of control, the game ends in a victory.

 

That’s it:  those are the basic strategies that can be used to succeed in this cooperative game.

Can we apply them to help us work together to create great software?

I’ll share some of the experiences I’ve had with these strategies in software development in my next few posts.