Focus; Or, If You Don't Know Where You are Going, You May Get There Sooner Than You Think

All too often on a software development project, teams can fall into the trap of getting "too many balls" on the court at once.

Imagine a basketball team which decided that in order to score more points, it would put 5 balls into play and have all 5 players attempt to score.

Or, a baseball team which put one left-handed hitter and one right-handed hitter at the plate in hopes that there would be a better chance of getting a hit?

What about a burrito shop which, in attempting to serve more customers, tried to have multiple people operating the shell steamer and multiple people trying to scoop beans, rice, and meat at the the same time?

Why do these examples suck? Because, it's obvious that nobody would ever do these things because of the physical limitations of space and time (and the rules of games).

So, what if you work on a software team which has several developers, but only one Quality Assurance person? What if that person is the gatekeeper through which all developed software must pass for approval and review?

If this is the case you find yourself in, then do whatever you can to make that person's job as easy as possible. Do not build gigantic inventories of features for that person to review "all at once" or "at a future date". Instead, work closely with them to prioritize the delivery of work for their inspection and review, because there will be things you do incorrectly that you must fix, and they must re-test.

In short: the team must Focus, through collaboration, on the delivery of features in a prioritized, logical sequence that aids review and testing.

The team must avoid working on too many things all at the same time which hinder or slow down review and testing.

To visualize this, I recall a previous article I wrote a couple of years ago: Agile Software Construction is Like Neighborhood Construction.

In summary, imagine you have three forms that you want to deliver to your customer for their web site:

1. Standard Story Form
2. Emergency Story Form
3. Travel Story Form

You know that many components of these forms will be, potentially, identical, such a Title, Description, or Category section.

Upon further analysis, you see that the forms break down like this:

1. Standard Story Form
1. Title
2. Description
3. Category
4. Location
5. Save Draft
6. Delete Draft
7. Edit Draft
8. Submit Draft
9. Send to Expert for Review
10. Post to Site
11. View 
2. Emergency Story Form
1. Title
2. Description
3. Category
4. Location
5. Save Draft
6. Delete Draft
7. Edit Draft
8. Submit Draft
9. Post Immediately to Site
10. Send to Expert for Review
11. Post to Site
3. Travel Story Form
1. Title
2. Description
3. Location
4. Save Draft
5. Delete Draft
6. Edit Draft
7. Submit Draft
8. Post to Site

While there a number of ways you could go about developing this, here are two:

All Features in Progress, None Done

In both approaches, our iteration is 3 weeks long. In the horizontal approach, the team focuses on building up collection of requirements for all story form types. This is followed by developing, testing, reviewing, and releasing the forms, all at once.

As we move from left to right on the time axis in weeks, we see that there is no actual working software delivered after 3 weeks, or 6 weeks of effort. In the 7th week, we potentially have finished the Standard Story Form, followed by the other two in subsequent weeks. After 9 weeks, 3 deliverables have been made.

	Week 1	Week 2	Week 3	Working Software Delivered	Deliverables Remaining	Business Value Accrued
Iteration 1	Standard Story Form Requirements and Design	Emergency Story Form Requirements and Design	Travel Story Form Requirements and Design	0	3	0%
Iteraion 2	Standard Code and Test	Emergency Code and Test	Travel Code and Test	0	3	0%
Iteration 3	Standard Review, Revise, Retest, Release	Emergency Revise, Retest, Release	Travel Revise, Retest, Release	3	0	100%

One Feature in Progress Until Done

In this approach, the situation is very different in terms of both Time-Value-of-Money and Return-on-Investment for our customer, and in terms of reducing risk for ourselves.

As we move from left to right on the time axis again, this time we stay FOCUSED AS A TEAM on the Standard Story Form and going all the way from requirements to release before the end of three weeks. After three weeks, we see positive numbers in the final three columns! Compare that to the double easter eggs above, and you will agree that staying focused as a team with One Feature in Progress Until Done is a much better approach.

	Week 1	Week 2	Week 3	Working Software Delivered	Deliverables Remaining	Business Value Accrued
Iteration 1	Standard Story Form Requirements and Design	Standard Code and Test	Standard Review, Revise, Retest, Release	1	2	33%
Iteration 2	Emergency Story Form Requirements and Design	Emergency Code and Test	Emergency Review, Revise, Retest, Release	2	1	66%
Iteration 3	Travel Story Form Requirements and Design	Travel Code and Test	Travel Revise, Retest, Release	3	0	100%

TODO: Complete