There are occasionally some odd situations that transpire during the Agile planning process, and one question that frequently arises is how to stay releasable when certain features cannot be broken down into releasable code prior to the ship date. Ideally, the basic Agile tenets are observed before starting to classify something as out of the ordinary: nightly builds of fully installable and executable software, small increments of working software delivered (2 weeks), continuous testing, and etc. Even if a team is following all of these, there can still be some situations where the team cannot complete a feature to a point where it can be delivered to a customer. This could be a situation where the small increments of the feature, while working independently, do not add up to enough value to complete a useful workflow, or the team may have incorporated some 3rd party tool or product, which instantly overwhelms the team with integration test cases. In these rare cases, teams are left with the question of how do we keep the software releasable but continue working on features which may not make it to the customer’s release. The following list provides some ideas to combat this problem:

• Hide the functionality. This option could include several things such as hiding a tab (via configuration or unreferenced URL) with the incomplete functionality, but allowing access to the product owner, developers, and QA, so that testing can occur in the main branch of the software. It could also involve licensing, where a license key prohibits the customer from accessing the uncompleted parts of the product.
• Wait on delivering the 3rd party product. Even though the team may have spent vast amounts of time implementing new APIs and testing the new product during the release, the incorporation of the new 3rd party product should be constructed such that it does not prevent the rest of the product from shipping.
• Limit the selling points. While it’s never a good idea to have visible parts of the product which are not fully usable by the customer, the important point is to make sure the rest of the product continues to function properly. If other useful parts of the code can be delivered to the customer, the customer may want to take advantage of the other fully working functionality, and this is what should be promoted.
• Document unfinished workflows. As with the option above, release notes and known issues can documented where the product is lacking. With both of these last two suggestions, the limited functionality should not create additional problems nor allow the user to sabotage himself.

Decrease your iteration length. – The Agile answer to how to overcome the problem of breaking down these seemingly large requirements. At first, it sounds simple, but after giving it some thought, it sounds like a Greek philosopher’s answer to the meaning of life. (i.e. Neat answer, but what do I do with it?!)

The two dilemmas that teams face when breaking down requirements are (1) a reluctance by software engineers to develop in a (perceived) less-than-efficient mode and (2) how to use multiple people in a common area of the code, where the ‘9 mothers and a baby’ theory starts to show (no pun intended). I won’t go into all of the ROI reasons to offset both these fears because they are well documented in any Agile process book; however, there are some different ways to brainstorm the large requirement question.

In general, decreasing the iteration length may be taken in its literal form. If using a 4 week iteration, switch to a 2 week iteration. If using a 2 week iteration, the team might experiment with fully accepted story cards within a 1 week iteration. Assuming the team is already using a 2 (or less) week iteration, another way to consider the breakdown is by considering what would be done if only 2-3 days were given to accomplish part of a larger task and demonstrate some progress, no matter how small. Unless the answer is ‘give up and quit’, there is some part of the requirement that can be done in a shorter period of time. As stated before, the team must trust the counterintuitive notion that this approach will not result in the most productive use of everyone’s time.

Since many problems are too large for one person to code within one iteration, it only makes sense to use multiple software engineers. One way to look at using multiple people is to consider a drastic approach of being forced to solve the problem of how to write a ‘say hello’ program with equal participation from 3 people. While a completely ridiculous way to solve this problem (not to mention a ridiculous problem), each person could rotate typing the code on a single keyboard. The point is to highlight that every problem could be broken down (components, classes, methods, etc.), and once again, the team has to make a leap of faith that the paybacks in familiarizing multiple people with more of the code and the benefits of demonstrating working software will make the team more efficient over the long term.

Last but not least, teams can approach the requirements breakdown phase as a mental competition. While many engineers like to exhibit their problem solving skills, the team can make the breakdown process a problem in itself. Peer recognition and other forms of compensation can be added to help change the old mindset of cranking out code to put food on the table. In this case, the baby gets new shoes when high quality code is delivered frequently and not when the super engineer works 24 hours straight to code something no one else understands, which will take 3 weeks to test in the quality.

• Agile Enterprise Architecture
  (tags: via:mrchippy agile software)

For waterfall projects, the classic defect curve is used to determine when a product is ready to ship. This is because most of the features have been “completed” during the first part of the development cycle, and the only work left to do is fixing the remaining defects. With Agile, there is a different approach where the work for the next iteration (2-4 weeks) is determined at the beginning of each iteration. This work should include taking the highest priority items from the backlog and working on those. In an idea environment, any defects are including the backlog and prioritized along with all of the features or enhancements to complete. However, when the defects are separated, the counts take on a life of their own.

These counts create perception issues and also cripple the Agile process because they are not prioritized with all the other work that is needed for the product. For instance, ten defects may cause one engineer to cringe, while a customer may not care about one thousand defects as long as the software performs its job. In addition, these defect lists have to continually be reviewed as a separate work set, which makes overall prioritization nearly impossible. In general, separating the software defects from the rest of the work is a relic of the waterfall days, while the Agile way is an all-encompassing backlog. When looking at a defect chart and waiting for the slope to point downwards, a good question to ask is “Why am I looking at a defect chart?”.