Overview of the Six Week Solution


Chapter 4

business goals


We should have written this book years ago. Independently we had worked to ship software in a timely manner, aligned ourselves with the business part of the company, and shipped software frequently, sometimes quarterly, sometimes even weekly. We had worked on automating the build process with checks for unit and integration tests and had a deep desire to automatically validate code for correctness and complexity. When we met, the concepts were not new to anyone; instead, we realized it should all be brought together and formalized. Thus the Six Week Solution idea was born.

One major project that highlighted all the failings of software development occurred at a very successful company in the mid-1980s. The project began with lofty goals of providing what would later be termed as peer-to-peer networking with a protocol that worked across UNIX, DOS, and Macintosh operating systems, including tackling the dreaded UNIX-to-DOS text file compatibility. Even file names were to be mapped between the limited DOS 8.3 character file name standard and the possibly long and case-sensitive naming convention of the Macintosh and UNIX platforms. Print support was to be consistent across all platforms, as was the user interface with a centrally managed security protocol managed on a UNIX machine.

Looking back, this all may seem rather quaint, but in the 1980s it was cutting edge. It was also an enormous failure.

Here was a classic approach of specifying everything before the project began and ignoring what was learned along the way because the file transfer protocol should have been a spin-off product all by itself. Some of the requirements may have been valid, but the need for all the different platforms was never well understood by the development staff. To make matters worse, the operating systems were changing rapidly and the current Windows/286 was incredibly unstable, often throwing a user back to a DOS prompt without warning. There were not enough staff or hardware resources available to hit the window to get the product to market. It was assumed that no software could be released until everything was ready.

1980s Company culture

At the time, the company was all very cutting edge; there was a cafeteria, two volleyball nets, running paths in the office park, and showers in the office buildings. The company was clearly catering to developers, and it should have been a paradise where they could write code, maybe attend a few meetings, work out every day, and still have a life.

Yet on a Monday in November, the entire engineering staff was laid off.

Why did this happen? There was a collection of really smart people working as hard as they could for long hours who couldn't deliver anything and they were never done. All the concepts, development work, solid teams, and money were all thrown to the wind. The need for a rhythm was clear to make the entire process of creating a software product, from conception to delivery,more bearable for everyone. From management to development, there were no visibility or regular checkpoints to keep everyone informed of the needs and progress. The Six Week Solution was created to address classic problems like these.

Additional Problems

Too often, product management lets requirements of a software project change. This was as real a problem in the 1980s as it is today, and with the speed of communication through the Internet, it is a more significant problem now. Software companies exist in a competitive marketplace where new technologies of hardware, software development languages, and operating systems sometimes change drastically within six months. The temptations to chase the newest bright shiny object are enormous and if you don't chase that object, your competitor will introduce even more FUD (Fear, Uncertainty, and Doubt) regarding your company and product into the marketplace.

Product management

Product management must rein in the draw of chasing the latest buzzword, but yet that buzzword must be studied. The time frame of development must be quick, but still allow for significant development to be accomplished with quality. It is not acceptable to have a three month roadmap that is out of date in a month due to an announcement from a competitor. Yearly releases, attractive from the standpoint of not overwhelming a customer, are not acceptable; conversely, releasing every week because the objective of a sprint is met is not acceptable either.

Long- and short-term goals

The balance between achieving a significant amount of work and staying on top of technology is a concern addressed by the Six Week Solution. There has to be the ability to work on long-term goals while still addressing quick wins and the ability to react to a changing marketplace for product management to be successful.


On the street, sales often has no confidence in which features, bug fixes, or functionality is included in what release and no faith in the delivery date of a release. It is impossible for sales to promise a customer when a bug would be fixed or a new requested feature will be built. Without any knowledge of what was coming when, sales resorts to the only thing they can do: promise the customer anything and everything.


Like sales, marketing is also left flapping in the wind with no good information for what to present at the next trade show or to put into a brochure. Typically, no one in the company, even product management, can communicate the state of the software to sales and marketing. Both sales and marketing need feedback loops to know what is happening with the product and to prime the pump of development with new ideas and needs. With emphasis on committing what work is being done in each development cycle, the Six Week Solution seeks to address this problem.

Developers are typically broken into silos, with developers on one part of a large project not communicating with developers in another part of the project. While the separation may be physical or managerial, delays are forced into surprising locations within a project. Any product of significant size must deal with hardware, operating systems, drivers, business logic, and presentation layers. Yet these various technical disciplines are typically separate from one another, allowing what appears to be a small change in a foundation percolating all the way up the technology stack, only to be found at the last possible stage in QA. To address this, the Six Week Solution puts all the technical disciplines in the same physical location (called a "bullpen.")

Developers' common flaws also contribute to failing projects. In a sea of churning requirements thrown up from a stormy marketplace, software developers attempt to remain in an ivory tower on an island with a huge seawall to protect themselves. Developers will sit in meeting rooms with a large white board and many colors of grease pens calmly stroking their beards and softly murmuring about best practices and object-oriented software development. They use words such as "polymorphism", which sound vague and undefined to the rest of the company as if they came from some ancient dead language. Developers sometimes relish the position they are in as the "smart" people, reinforcing this belief with difficult-to-use software when they finally do deliver something. Clearly something needs to break this approach and get the software development resources engaged into the rest of the company; this issue, too is addressed by the approach of the Six Week Solution.

Quality software cannot be built in a day. No amount of crisis management or adding resources will increase the velocity of development or correct the software quality deficit. A cutesy phrase that gets repeated by developers when management attempts to add additional human resources to solve a delivery timeline or quality problem is: "Nine women can't have a baby in a month." It takes what it takes to build quality software and the processes have to be created and the right people in place before the project begins.

Advance planning

Contrary to so many endeavors of creation, such as building a house, software development cannot be fully planned out in advance. Attempting to define every requirement, every use case, and every actor who will use the software, every possible machine communication has been tried in the past with only limited success. Shifting market demands and new customer requirements for new industries that sales will inevitably attempt to penetrate require that any software development effort be comfortable with some level of uncertainty. The term coined for attempting to define everything up front is "analysis paralysis". Many consulting dollars have been spent in requirements gathering, but if the concept of the product is not understood at the outset, it is doomed to failure. Requirements simply appear and shift too quickly to gather them all before a single line of code can be written.

It's like building a house, only it is not

Attempting to build software like building a house leads to disaster. When building a house, there are hundreds of years of craft and science built into the process. Blueprints are standard, the framers know which page to look at to find out where the 2 x 4s go, and even the 2 x 4s themselves are standard. Electricians flip the blueprint to the page defining every junction box, outlet, light switch, and panel. Likewise, plumbers have standard fittings and pipe sizes and ways to adapt such as fitting a copper delivery pipe to a sink, which may be independently replaced later.

Software has no such permanent standards that have existed for such a long time and weathered so many storms to find out, by trial and error, what works and what doesn't. In recent years, attempts have been made to standardize at least the plumbing of software where machines must communicate, but even these "standards" are at most decades old (like, for example, technologies such as TCP/IP). Other "standards" have only been around for less than 20 years and while they define the envelope of what is sent, they do not define the contents. Contrast that fact to the existence of different size pipes for natural gas and water and different fittings, which not only define how something is being transported, but also what is being transported inside the pipe. Software has no prior standard for the full stack of an application.


The Six Week Solution has three core components for aligning your development team to the business's needs and priorities. Those components are:

Putting the business and the development team in step, targeting the same goals, and with parallel motivations puts the business much more effectively in the driver's seat of your development efforts.


Everything in life needs a rhythm. We are accustomed to seasons, and the changes nature goes through at each transition point whether the activity is growth, hibernation, reproduction, or survival.

Establishing a rhythm

Once we decided that we needed a rhythm to software development, we needed to find the perfect interval. A week was too short to deliver major functionality; two months seemed too long as the business would still view development as a black hole. And development needed to consider the business thought process of quarters and all the planning that goes into what will happen in what quarter of the year and how that all impacted the bottom line and fiscal calendars.

Business thinks in quarterly periods. The confidence that a marketing or salesperson can show when answering questions in quarters resonates with business. New requests from potential customers should never have to be stretched out more than 11 weeks, and if a piece of functionality needs to be done sooner and the scope fits, there needed to be a mechanism built into the process that allowed, and contained, the inevitable change request.

Overall, the process must be simple and visible, providing the mechanism for communicating the business need to the development shop and provide understanding of what is happening, why it is happening, how it is happening, and who is doing it. The journalism piece of the process has to be built in from the start. It's not simple because there are many moving pieces both human and electronic, but it's also not brain surgery.

After several attempts at finding the perfect rhythm, it was finally clear that six weeks is optimal. Every quarter provides two natural cycles, which provides two chances to get requests into a development cycle with two opportunities for immediate requests in addition to each cycle.

In 12 weeks there are only six major meetings to attend, although there are many other opportunities to influence the outcome and contents of what is developed within a development cycle. Even with two deliverables per quarter, and eight releases in a year, there still is enough padding to give plenty of time for vacations around the Fourth of July and Christmas where the majority of employees will request time off (in the United States). In the end, we selected six weeks as the optimal balance among business needs, the velocity of software development, and the human requirements of some downtime to recharge.

The need for rhythm

Too often a software organization is built around a single long-range goal such as to deliver the next release and planned with some monstrous Gantt chart plotting all the tasks and interrelations of tasks to complete the next upgrade (in some cases even plotting approved bathroom breaks!) Nothing in nature could survive this level of planning, for eventually something such as a storm, unexpected cold temperatures, or a new mutation of a virus would destroy the plan. Unlike nature, software development has attempted to define everything up front and get it all on a meticulous Gantt chart. Once the chart is created, the death march begins. The first time a milestone is missed:

In the massive Gantt chart approach, there generally is no defined time for research, no intermediate delivery to gauge achievement, no natural point to adjust requirements or direction based on new information, and no time to evaluate changes in technology and the marketplace. If someone actually did plan for all of those checkpoints, when the first slip occurs these checkpoints are the first thing to be removed from the Gantt chart.

One key goal of the six week development cycle is to provide each individual and the team as a whole with a sense of rhythm to the natural alignment of the business functioning on quarters. Additionally, the assessment points built into the cycle provide their own suspense to complete quality features for demonstration and eventual release.

For the following reasons, the six week development cycle is the perfect time frame for a development organization.

FIGURE 4.1: Six Week Solution calandar: the entire year

Manageable time frame

Six weeks is a short time frame. Tasks must be relatively small and well defined in order for them to be achieved - with the required quality - in six weeks of development time. This time frame enables us to focus on our tasks and give the tasks the attention they require. (For a diagram showing how the Six Week Solution fits into an entire year's calendar, see Figure 4.1.)

Note: We have worked in one environment where releases were done weekly. Weekly iterations sound good in theory, but in the real world, weekly product releases are very difficult events for both customers and the company.

Most things can wait

One of our goals is to prevent external interference and distraction from cycle commitments. Although there are always exceptions, most things can wait until the next cycle to be properly prioritized, assigned, and resolved. This also solves the problem of "sea gull management" and "knee-jerk reactions", which both serve to destroy software quality and in the end do nothing to reduce the time required to produce functional software.

Boundary to benchmark progress and make commitments

Much like the corporate world expects results on a quarterly basis, the Six Week Solution gives other groups within the organization a time frame in which to expect results from software development. Cycle commitments are identified at the beginning of a cycle. These commitments let other departments know the focus of software development for the next six weeks. At Mea Culpa, we identify whether we can complete a task in a cycle. Finally, at cycle sign-off, we can address the specific cycle accomplishments.

Two cycles per quarter

A wonderful side effect of the six week cycle is that it fits very nicely within the corporate world expectation of four quarters within a year. There are two cycles per quarter with one extra week to remove most holidays from the cycle rhythm. Two cycles per quarter allow you to define in greater detail and more thoroughly complete tasks for the quarter, in many cases without a great deal of upfront planning attempting to fully define functionality. This timing, along with checkpoints, gets all stakeholders in the overall business and in software development to focus on what is really important and delivering the important functionality on time with high quality.

Opportunity to change direction

Business priorities and technologies change. Six weeks is a good time frame to build checkpoints and possibly change long- or short-term goals if needed. The short time frame allows the freedom to change short-term goals to deal with inadequacies or environmental changes. Checking back every six weeks to identify long-term goals provides the flexibility to change these goals as situations change. (For a diagram showing how the Six Week Solution fits into a single quarter, see Figure 4.2.)

Forcing scope

An enormous hurdle to get over in any software process, especially when creating a better mousetrap, is to move in small, incremental steps. In the process of building software, you simply must be prepared to throw out a prototype. Instead of starting over from scratch, you must be mentally prepared to force incremental changes. Don't re-create the storage mechanism at the same time you are changing the presentation layer to use a new technology. All structural changes should be made with upstream and downstream systems untouched so that solid testing can be performed. Having a process made up of six week periods forces scope in each cycle to remain at a manageable level.

six weeks
FIGURE 4.2 Six Week Solution Calendar: one quarter.

Cycle Commitments

Each cycle revolves around a cycle commitment document. This document is a contract between the business and the development team that specifies the expected deliverables for the development team in the current six week cycle. Collaboration between the business and development to build out the details of these commitments is a key component of the Six Week Solution. Signing this document should be an event, and what keeps it from being an empty ritual comes next.


The cycle document codifies the business's priorities, but it does not yet motivate the developers to focus on it. To create a culture that is focused on satisfying the businesses needs, a crucial part of the Six Week Solution structures part of a developer's pay as a bonus paid at the end of each Six Week cycle. Base salaries are set a bit below competitive wages to align developer's motivations with the business costs of missed commitments. After all, the business is going to make commitments to customers, spend money on marketing, line up resources for rollout and maintenance, and buy hardware for deployment based on the development plans. The pay structure is described in more detail in the Compensation section of Chapter 5 on page 57.

Key elements of the bonus structure include:

Provides Motivation

The compensation structure is the glue that keeps the development team in line with the business. While developers are frequently not primarily motivated by money, the compensation factor motivates the team on several key levels.

It creates a culture where success and failure are fundamentally defined by delivering what was promised, to the business, when promised. It may seem odd, but development teams rarely function that way.

The compensation structure keeps the development team glued to the rest of the business.


The nature of software development has changed: it is no longer possible to take four years to deliver the next upgrade or even produce the initial product. Six months may be a risky time span given the competition you may be facing, so any methodology to reduce the time to market while still delivering quality is a benefit. We know that you have to produce and get profitable quickly and the Six Week Solution is a methodology to get there. (For a diagram showing a single Six Week Solution cycle, see Figure 4.3.)

Breaking your development windows into six week chunks allows quick delivery of new opportunities, fits well with how businesses think and plan, and lets you target changing needs as your product and client base grows. In addition, rewards and penalties are built into the system to ensure that you have a quality product at all times.

By strictly time boxing your investment in software development to six weeks, you enable experimentation and can afford to explore some directions that may turn out to be blind alleys in the long term. It has been a fairly standard thought process in developing software to attack the risky portions of a project early in the development to reduce investment in bad approaches that may not result in a viable product. We embrace that concept and further divide investment into a manageable time frame of six weeks. This time span is long enough to produce a significant amount of work, yet short enough that the investment is not so large that it must be seen through to the end.

six week cycle
FIGURE 4.3 Six Week Solution Calendar: one cycle.

The Six Week Solution provides a sharper focus to the development process than even other Agile processes do for several reasons:

By engaging everyone in the development of a software product, with each individual contributing at his or her highest level, strictly limiting the time spent to create software, changing the physical layout of the office, measuring the quality of the software produced, and rewarding for success, it becomes possible to dig out of the hole that many software projects have dug for themselves.


The Six Week Solution transcends the writing of software, documentation, and meetings and extends into the physical workplace by defining not only how to hire the members of your team, but also how to lay out the office to promote effective software development. The codification of a bullpen area for developers, QA, and technical writing sitting next to one another in an open space leaves the excesses of the 1990s style software development with its ping-pong tables and green rooms in the past where it belongs and moves into development focused on delivering functional and maintainable that delivers high value.


The big bang of creation for each six week cycle is the kickoff week. This is when all the stakeholders get to express their desires and concerns for the next development cycle. All known feature requests and bug fixes should be expressed and prioritized for cycle kick-off week. Whether strategic or tactical, everything is on the table to be evaluated for inclusion into the cycle.

Optimally, the cycle kick-off meeting is early in the day on Monday morning for the development staff. This forces some preparation by product management in the weeks leading up to cycle kickoff to help "herd the cats" and collect all the input.

The cycle should start with some kind of brain dump by a strong representative of the business. Someone to explain the wins and losses. Explain the features that may or may not exist that would help close more business. It should not be a long discussion but it should certainly bring the development team into the business world for the moment so they have a glimpse of what the challenges may be. The developers will be very interested and they may have some feedback into how the system works today that no one on the business side is aware of.

The interests of everyone should be represented: the simple but hot new presentation that marketing needs, the critical care and feeding feature enhancement that support needs, and the groundwork for the major architecture change that the database developers want. Everyone should be given some time to clarify the reasons for why their top items should be considered. It is important that everyone gets their time; equally important is that their request is treated with respect. You will need a very knowledgeable arbiter for this meeting to ensure that no group's interests or proposal overruns the meeting. There should be enough information at this point to give some initial inclination about whether the request can be considered. Time must be spent prior to the meeting to define the high-level task(s) necessary to complete the goals and hence the groundwork for beginning to scope the time and resources necessary to achieve the goals.

The goal of this meeting is to take the first pass at the things that will be built in this cycle. The meeting should end with everyone having a good idea of what may be possible. There should be a list of research items and follow-up meetings to refine requirements and scope further during the balance of kickoff week.

One other note to both developers and businesspeople: everything you agreed to has been put in writing. Be careful what you agree to at this stage because you will not get to change your mind later.

Sample Kick-Off Items

Revisit charting controls to produce larger screen space for chart

Evaluate <Insert latest data cube technology here>

Define schema for <Insert newest feature here>

Planning week

The planning week is the time when everyone will think about and plan the research and design required to complete the goals. Each person or group will take high-level tasks from the cycle commitment document and break them down into subtasks. At this time, they will identify what other resources are needed to complete the tasks and manage the various dependencies. Each group or person will determine a realistic time estimate to complete each task as well as the goals. In addition to doing a high-level breakdown, all of the dependencies need to be identified and assigned as well. The time estimate will need to fit into the remaining five weeks of the cycle following sign-off.

Large tasks

A critical concept during the planning week is that some tasks are simply too large to fit in six weeks. Fortitude is required to stand up and say, "Dude, that's too much!" followed immediately by, "But here's what we can do quickly, and then we can do this really cool thing!" This kind of feedback is not always easy to hear, when the tasks are of particularly high importance for the business. There is a common pattern for someone in authority to push back and say that it has be done anyway, so work evening and weekends and do whatever it takes. Situations like this have failed before they even kick off. For a number of reasons we will discuss elsewhere, these kinds of efforts destroy software projects, and generally leave both a product and a team that are no longer functional.

A better approach is try to break up the necessary tasks into smaller pieces of functionality, each of which provides deliverable business value. Those pieces then can be prioritized and fit into multiple cycles based on their relative priority. That process feels uncomfortable to many at first, and it is tempting to say the task cannot be broken up, or we cannot live without all of it, but an experienced team almost always can find a way.

You get to play with technology

To developers, this week provides the ability to play with technology and we don't mean the latest real-time strategy game or latest release for the game console du jour. "Playing with technology" at this phase is why lions bring wounded prey home to the kittens to practice killing their own dinner. You play to learn, experiment, and come up with a swift kill. Just as biting a mortally wounded gazelle teaches young lions how they can provide for themselves later, playing with technology allows for a chance to evaluate choices and practice for the best method of working to produce a quality result.

Developers also have the responsibility for tracking down any fuzzy requirements to get more details. Recipients of the product have the responsibility to define any loosely defined requirements to get an honest appraisal of what is being requested. Throwing up requirements consisting of several latest buzzwords strung together because a deal was signed is not a cycle requirement. If you expect honest answers from your software development group, don't ask for fuzzy undefined things such as "what we really need is these data in a Web 2.0 format" and then be upset when that software development group asks: "Which Web 2.0 format?" You need to be able to answer that question because the developers don't know if you are asking for one of many standardized messaging formats or something for pumping messages to Twitterholics. You have the right to know what is being developed and the responsibility to know and understand what you are asking for. Given the right input, you can expect truthful estimates.

Cycle finalization

Before the final document is prepared, the team will gather and make one last pass through the tasks and make sure that everyone is comfortable. This is probably the hardest part of the process. Fairness and full utilization are critical. You want to ensure that the workload is distributed properly over the team. You want to have goals that are achievable but require a stretch. It is very important for the continued survival of this methodology that the business has a feel for the work and believes that the team is pressed. Never should a cycle commitment document be a cakewalk, and neither should it be a death march. Finding the balance is critical.

A document identifying each separate task that makes up the goal and the responsibility for completing that task will be drawn up. At this same time, a document with the identified goals will be written; this is the document we will physically sign, in ink, by our own hands.

Cycle sign-off

At the cycle sign-off meeting, the development organization and the business come together once again to sign the document for the cycle. Each person on the team will sign this document reflecting his or her understanding of the team commitments. This process should be assigned all of the formality of a contract, as that is what it is, a six week agreement between the business and the development organization.

Ideally at this point there are no surprises, but it is a good practice to review all of the items on the document. Make sure that everyone, inside and outside of software development, understands what each item means and the expected scope.

We like to have verbiage at the top and the bottom of the document with the dates of the cycle and the commitment to work as a team.

Sample Top

The staff of ABC herby enters into a mutual agreement to work as a team, support one another, and do everything in their power to successfully complete the following development deliverable in Cycle #1 beginning January 1st and ending February 16th of the year 2010.

Sample Bottom

I firmly understand the scope of these commitments and will do everything in my power to avoid deviation from this scope. Additionally I will do anything I can to support the other members of the ABC team in the completion of their commitments for this cycle.

Signed this day, January 12, 2010

What's in the middle of a cycle commitment document is up to you.

Initially, the line items may be very specific and directly reference the change to be made. This specific approach is useful for new teams or to help new members of existing teams ring the bell of success and have something concrete to point at to mark their contribution to the cycle. The other reason to have specific line items is to help train the wider audience attending cycle meetings for what they can expect to get done in a single development cycle. The specific items may simply reference reports from a bug tracking or ticketing system. Items such as "Fix bug #1245 for Customer XYZ" are perfectly acceptable and still useful even with a mature team.

As the team or team members mature with the process, it is possible to be more open with the commitment, such as :produce a web service to process <something>" because the size of the commitment is well understood by everyone inside and outside of software development. This approach does require other documentation to capture what is being accomplished by this line item, although typically a concept that cannot be defined by a couple of pages is either not well understood or too large for a single developer within the time frame of a single cycle. With everyone's signature on the commitment document, we should now have set our development team in alignment with the current business needs. Knowing that they will be paid out their bonus at the end of the cycle based on satisfying those needs will help keep the development team on track for the next six weeks as they work to satisfy those commitments.


At the midpoint of the cycle, we will have a meeting to review the tasks and goals and talk about our progress. This is the time to address your concerns, remaining dependencies, and loss or addition of resources. We will adjust our goals based on this meeting.

Please note that this is not the opportunity to just replan, but rather acknowledge that as development occurs, we will learn more about what is involved. Sometimes that means making an adjustment to the schedule. In addition, we may have dependencies on items that are outside the software development group's area of responsibility. We may need to adjust our schedule based on an outside group's schedule.

Mea Culpa ("my fault" in Latin) is the opportunity for everyone to do a checkpoint. A straightforward evaluation of the work done to date and work remaining must be performed.

Gut-check time

Development may come to the table explaining that a task turns out to be too large. They may come with a discovery that there is a better way to proceed that could dramatically change the time required for delivery. If things have exploded, then it's gut-check time. What can be thrown out? Can anything be rescoped or a feature reduced to ensure delivery? These questions are hard, and many times participants (software development included!) are not willing to remove an item from the list. It is important to understand that taking an item off the list isn't throwing it away for all time, because it can come back in the very next cycle.

Business may come with a critical item that needs to be addressed. If the schedule was set up where it should be, with a bit of a stretch to accomplish all the goals, then it is again gut-check time. Just like exploding requirements, something has to give. The same questions have to be answered.

Regardless of where a change in scope comes from, there are only a few choices for the outcome. If too much work was assigned and something didn't get done or the quality of the work that was done is garbage, it will need to be revisited (almost always more expensive than doing it right the first time) in a later cycle.

Another reason for a change at Mea Culpa is finding out that some technology that looked awesome in the first week of planning turned out to be a dud when the amount of data exceeded its design limits. This could be performance, space, or maybe the amount of code required to work around the limitation. Maybe it's a combination of all three. Maybe the licensing of the component prohibits modification. Regardless, it takes guts to throw out work and go another path. Here is where it becomes important that when you slip, don't fall. Is there another path or alternate technology that would solve the problem? Either you must find a way around the blocking factor, throw out the code, and go another route or you will be forced to push a rope uphill. Is it worth dragging an albatross around your neck for what could be years when you could go another route in the next six week cycle? Making the difficult call to remove or redirect a line item, while upsetting in the short term, can save millions of dollars and thousands of man hours in the future.

Other Mea Culpa issues

Other conditions can cause a radical shift at Mea Culpa. External factors play a large role when an expected partnership agreement did not close or a business is realigned. Here again, the scope may change radically and require a real investment of time to accurately scope what is now required.

For these and many other reasons, the Mea Culpa meeting is scheduled for a Monday. This is chosen for cases where any realignment of direction cannot be decided within the confines of what typically is an hour-long meeting. Performing this meeting Monday morning gives time to regroup and come up with a plan for execution.

Remember that the meaning of Mea Culpa is "my fault" or, in the vernacular of the early 21st century, "my bad." Simply put, "oops"; if you are going to "oops" something, do it early and communicate. What you want is for Mea Culpa not to turn into "mea maxima culpa."


It goes without saying that this process cannot work without a good testing discipline. By the final week of the cycle, you should be feature complete and 100% in test mode. QA has been side by side with the developers all along, which is the main reason why QA also sits in the bullpen so that they know what to expect and, in a mature team, should have been entering bugs as soon as the feature was ready. This week should be like finals week in college; a good student already knows the material and therefore the last week should be a blast, not a long series of all-nighters! But all too often, individuals haven't worked to complete functionality before the final week and it can be a difficult experience. Your goal is to minimize the trauma to the workplace and be "feature complete" before Monday of the last week of a development cycle.

Cycle sign-off

The final meeting is the sign-off meeting. This should be all high fives and "when can we have that in production?" Schedule this meeting at 2 pm in the afternoon and present all the new bright shiny features, bug fixes, minor modifications, and other improvements to the interested representatives outside of development. Have fun, show off, and go home ready to come back on Monday and start it all over again.

At this point the product is complete and deployable. Development should be done.

It takes a team: no one can win alone

The sign-off meeting is a great opportunity to let your team shine and point out individual contributors and what they accomplished. While a team lead may be performing the presentation, it is important to say "Mikey built feature XYZ and wants to show some unexpected neat things" and then turn the presentation over to them for five minutes. It's also a good opportunity to point out heroic efforts and folks who pitched in to help others. Use this sign-off meeting to inform the rest of the company and to point out publicly the value that individual developers are producing.

There is no "I" in "team"

Sure, it only matters for the bonus that everything on the cycle document was completed. And you want every member of each bullpen to have the feeling that "we did it." Maybe someone hit a home run or stole a base at a critical moment, but it is the team that won. Everybody had to do their job to get to the goal. This should also be a big moment for the development team, because at this point, they should know whether or not they are getting paid their bonus for their efforts this cycle. If they are, then the combined motivations of delivering on what they know the business needed, and seeing the additional money in their bank account will reinforce the alignment of their efforts. If they did not make it, or they "missed" as we often say, it is a harder day, but that also reinforces the importance of the commitments they make.


All of this process is structured to allow us to deliver what the business needs early and often. There are a number of benefits to that, but the most important thing is the opportunity to maximize the return on investment in the project. Whether it is a commercially released product, an internal IT project, or even a nonprofit, the project exists to produce value, which is simple and measured easily in a commercial product in the form of sales.

For an internal IT project, the goal is often to provide value that allows us to reduce spending taking place on another business solution. Even in a nonprofit, a development project is still a value-added proposition. For a business to maximize the value of their project, they need to target the most valuable functionality first and ship it early. Commonly, projects deliver a big bang at the end of a roadmap that has a complete feature set. However, if the most valuable pieces of that feature set are completed halfway through the roadmap, then waiting for the rest is throwing away the value you could be getting from those features in the interim. In addition, you lose not only the value that could be gained with the extra time, but also the possible advantage of having reinvested those gains early. In other words, you lose both the early money and the time value of that money. In the six week solution, you are getting deliveries of features every six weeks and they should not be of requirements, documents, or risk assessments but always be business identified most valuable features possible.

Avoiding obstacles

In a nine month long project, not only have you gotten four software deliveries six months into your project, but you have four meaningful feedback loops. (Actually, you have more, but we will talk about that further in Chapter 6, Managing the Cost of Change on page 89.) Those feedback loops give you the opportunity to see that development is going in the right direction by getting your hands on their product. Then you can correct mistakes, change development direction based on new information or changing business needs, and revise business plans based on actual progress made.

Feedback loops are crucial to software development. Occasionally criticized as "Ready, Fire, Aim!" approaches, iterative development realizes that it is aiming for a moving target. The farther in the future a plan is set, the lower the certainty that the goal is correct or will still even be relevant by the time we get there. Waterfall projects are dependent on a fixed, predefined goal. Iterative projects give frequent opportunities to reassess the progress and goals of the project and adapt to change, both to maximize the value of the project or to stop it all together when it has ceased to make sense. This high-level feedback loop allows for the most dramatic changes of direction as needed by business priorities, but making feedback loops as small as possible protects a project from wasted investments by allowing the development to be redirected away from erroneous or obsolete efforts as soon as the very first moment it becomes obvious that those efforts are fruitless. A healthy development project has feedback loops taking place from the scale of moment-to-moment coding decisions to daily team tactical decisions, all the way up to iteration planning, with quite a few in between.

Delayed decision making

With regular iterations and checkpoints, we are given the ability to push off making decisions until the last responsible moment. If you are like us, you hear a voice in the back of your head telling you that it is a bad idea to put off your responsibilities. However, as discussed in the section entitled "Waterfalls and Crystal Balls" on page 19, we are often forced by software processes to make decisions when we are the least prepared to do so. Delaying decisions allows us to wait until we are as educated on the project as we can be and are as informed on the state of shifting conditions as we can be.

The key phrase in that sentence was "until the last responsible moment." When is that moment? Well, naturally, it depends on the decision being made. If an architecture decision is going to impact the funding necessary to acquire needed hardware, obviously that would need to be made farther in advance so that the funding, or the hardware, could be acquired. If the decision is whether feature A or feature B will be included in the next release, it is often very helpful to delay right up to the start of an iteration. An example of the value of that could be that between the time that the need for the features becomes apparent and the time they make it to the front of the development queue, the marketing department has been to several industry conventions and has seen that feature A is becoming much of an industry-expected feature than we would have guessed, so it has become more of a priority than feature B.

The challenge for the business

One of the wonderful advantages of this process is that short deliveries of high value make it very easy and desirable to hit business tactical goals. For example, a big sale would close if only we had feature x, so we get that on the next cycle and win the deal. One of the significant disadvantages is that large, less iterative projects are forced to evaluate very carefully what their long-term strategic goals are in advance and target those. A Six Week Solution team should have those goals defined, but can easily limp along without them and never accomplish those strategic items if the business yields to the temptation to continuously target small-scale tactical goals for cycle commitments. Unfortunately, this is a problem we cannot solve for you in these pages. Prioritizing investment in a project between short- and long-term goals is a broader business problem all of its own.

Hitting a wall

Software projects in general do not have a high success rate and are subject to a marvelously wide array of technology risks, political risks, and marketplace changes. (This concept is discussed in more detail in Chapter 2, "The Problem: Why Software Projects Fail" on page 11.)

A common question to ask yourself is "What are we doing to manage the risks in our project?" A common solution is to prioritize our work according to what seems riskiest first. Unfortunately, that assumes that you know and can fix those risks, which is rarely the case. Instead, in pursuing the highest value return we can for each cycle, we address two scenarios of unexpected failures:

Because we have built the most valuable features we can all along, we end with the most valuable work we could have done to show for the project. If we had spent our time chasing risks or, worse, just analyzing and documenting, we would have been very likely to end the project with nothing but paper to show for the investment.

When to quit

Programmers solve problems and build tools. That is what they do, and given a cool problem and time to work on it, they will keep building solutions indefinitely. Very likely they will be very cool and powerful tools, but for you, there is a very simple question: "Are these problems the right ones to solve?" Every development cycle that your company goes through costs your company a measurable amount of money. Very likely, it is a significant amount of money. At some point, possibly long before the developers have provided all the value they hope to, the return on the project will stop being worth the investment you are putting into it. At that point, spiral life cycles allow you to have a frequent, fixed point to close the project down, with all the value of he software developed to date available to continue to provide value to your business.

A feature that works, performs its function in a reasonable amount of time, and is of the quality level expected in the marketplace is worth far more than something that might be really cool someday in the future but you don't know when. Sometimes developers, even great ones, have trouble letting go of the software because there is just one more cool feature that could go into it and it will just take a few more days/weeks/months/whatever. "A bird in the hand is worth more than two in the bush." The six week cycle works against developer release constipation by requiring that something useful be bundled up and delivered every six weeks while still allowing future work on the "next really cool thing."

I worked on a project where the product manager would never let anything out the door. She had us completely rewrite working features eight times and it was still never perfect enough to ship. She had us spend three months trying to get the exact perfect shade of blue gradient on some box drawings that she wanted. The project floundered for two years until the company was acquired and the project was cancelled for not making any money. Last I had heard, no customers ever saw the product.   Java Developer