Agile, Software Development, Teams

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.

Discussion

No comments yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: