Categories
Software Development

Tee Up! How Building Software is Like Playing Golf

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Golf Course

The Course Layout

We have a course laid out and we are moving along the course. Not all courses are the same, but they have the same basic structure and flow as we play:

  • Tee off on hole 1
  • Move along the fairway
  • Hit onto the green
  • Sink the putt
  • Move on to the next hole and repeat

The golf course structure aids us by its layout and keeps us moving along in the proper direction doing things sequentially. Similarly software development methodologies have a structure which keeps development moving in the proper direction with a repeating sequence.

Playing the Par 4 Hole

For a par 4 hole, the plan prior to tee off is to drive onto the fairway. Put the second shot on the green. One putt for birdie.

However, things do not always go according to plan. We may hook or slice a shot, hit the rough, a sand trap, land in the water, and even a hit out of bounds is possible.

This is when the golf course structure pays off in that you can be moving along the fairway toward the green even though you are not necessarily in the fairway. There are rules to follow, you have the direction to head, and you know the goal.

Similarly as a golf course is broken into 18 holes, software development is broken into pieces, often referred to as an iteration. And while you have a plan at the start of each iteration things do not always go according to plan. However, with the structure of your chosen software  development methodology in place you know the direction to head, have rules to follow, and you know the goal of the iteration.

Summary

For many finishing with a 72 after 18 holes is the goal, but one which is not often reached. Still, you have a goal before the game starts and from experience you realize that many things can come up as you play.

Software development is similar, in that you can plan out everything you want to do for the entire 18 holes before you step up to tee off on hole one, but there are many things that happen along the way to finishing.

Understand that golf is like software development. It is likely not going to go as planned prior to tee off. Do not get shaken when you hit a sand trap or other obstacle. Pull the right club and play on.

With a good software development methodology in place you will recover when things do not go as planned. Expect things can happen up front and smile big when things go as planned!

Scramble anyone?

Facebooktwittergoogle_plusredditpinterestlinkedinmail
Categories
Rapid JAD Requirements Uncategorized

Bundling

Facebooktwittergoogle_plusredditpinterestlinkedinmail

By Erik Jul

Bundling is a tidy idea.  Consider the humble bundle of sticks.

Bundle of Sticks

Useful.

Or the Roman fasces, shown here on the reverse of a U.S. Mercury dime, or Winged Liberty Head, dime.

Fasces

Powerful.

What makes each bundle desirable?

  • Utility
  • Fitness for a purpose
  • Ease of use
  • Similarity or complementarity of components, or
  • Some other bundle-making attribute that ties the individual pieces together

When selecting from a backlog of functional requirements, product owners and developers must select and form a bundle for the next development sprint.

This may seem like–or it may be–and easy job.  More often than not, however, it is fraught with decisions, trade-offs, and compromises.

What makes a good bundle?  Something must tie them together.

  • They implement a coherent feature.
  • They trace to user stories or epics.
  • They build upon a prior bundle.
  • They are required for a subsequent bundle.
  • They match the velocity of the development team.
  • They can be implemented in the current environment.
  • The account for any technical debt from previous bundles.

Of course, any bundle is only as good as its constituent requirements, which must be clear, correct, complete, consistent, unambiguous, verifiable, traceable, and testable.  Rapid JAD techniques greatly assist these objectives.

Creating the right requirement bundle is the basis for a successful development sprint, and a good bundle starts with a strategically stocked product backlog selected from a bank of user stories or epics.

Executing these challenging business analysis and project management tasks can prevent a bundle from becoming a bungle.

What’s in your bundle?

 

 

Facebooktwittergoogle_plusredditpinterestlinkedinmail
Categories
Requirements

TV Dinner Requirements

Facebooktwittergoogle_plusredditpinterestlinkedinmail

TV Dinner Requirements

TV Dinner Requirement have the following characteristics

  • Conveniently pre-packaged
  • Tasty like cardboard
  • Surprising when there is something good inside

Already Packaged

TV Dinner Requirements come to you already packaged and ready to go. A business has hired an analyst to define their requirements and package them up in a document. The company then puts their TV Dinner Requirements out for other companies to bid for the work, sometimes called a Request For Proposal (RFP)

If you find yourself working with TV Dinner Requirements, then you are beyond the defining of requirements typical of Classic JAD and are on to the next phase:

  • Validation of requirements
  • High Level Design

Remove the Plastic and Heat

Pull off the plastic wrap and validate the requirements. They may have become stale sitting around in a frozen package as time goes past.  How old are these requirements? Have they become stale like cardboard? Are there any good requirements in the package? Can someone in the business tell you why the requirement is in the package? Often the reason something is in the package is unknown! For these reasons a good business analyst will validate the requirements in the package.

Things should heat up as you share the TV Dinner Requirements with business leaders and developers and put together high level designs as a proof of concept. Everyone will like talking about the good stuff they find inside as well as the bad stuff.

Keep in mind that TV Dinner Requirements can be fast and easy, not necessarily good.

Facebooktwittergoogle_plusredditpinterestlinkedinmail