From Concept to Product Backlog

At Agile 2009, Gerard Meszaros gave a talk on the steps needed to get to iteration 0. Iteration 0 is an iteration dedicated to setting up the development environment before the 1st real iteration is started. It usually includes installing development tools on workstations and team tools on servers, and priming the user story backlog so that it is ready for the iteration 1 planning meeting. A secondary objective includes calibrating the development team’s velocity and learning any new technologies that will be used.

Gerard shares some examples of poor upfront planning. These include situations where customer was learning on the job and they did not have the productivity to get things going and as a result they could never catch up on the story tests. Another was when fit tests kept breaking due to new logic being introduced and another was when user interface contained many inconsistencies.

Gerard attributes these problems due to lack of upfront planning leading to sub-optimal results. The big picture was missing. In agile planning these is constant tension between BDUF (Big Design Upfront) vs. LRM (Last Responsible Moment). We need to find the right balance between up front planning and decision deferral, and the right balance between high ceremony just because and just enough, just in time. Some ways to achieve this is by prototyping or staged style funding.

Agilists in general are familiar with the five levels of agile planning: Product vision, product roadmap, release plan, iteration plan, and daily plan. However, there is planning that needs to be done before we even get to this stage. Concepts need to be broken into ideas and then into core features. There needs to be an elevator statement and a description of the behavior of the product as well as a high level architecture, cost estimates, and eventually user stories. Gerard describes this as:

· Product Envisioning: concept, major features, and product design

· Product planning: risks, benefits, test strategy, release plan, effort estimate, cost estimate, skills list, budget.

· Project Execution: User Stories, story tests, business staffing, tech staffing, iteration plan, story tests.

Product Envisioning

The goal of product envisioning is to get a collective understanding of the product. We need to get everyone working towards a common purpose. Get everyone’s input and buy-in of the product and help everyone understand the big picture. This is done by workshops for envisioning the product to be built using brainstorming, listing functionality, users, and value. Outputs include the elevator statement, product box, major and differentiating features list, and low fidelity user interface prototype.

Strategies for Effectively Managing Legacy Systems

At ThoughtWorks Quarterly Review, Amir Uttman and Derek Longmuir discuss strategies for effectively managing legacy systems.

Legacy system have the following characteristics: Expensive to maintain, unchangeable, old-fashioned, unreliable, complicated, old, COBOL, mainframe, single point of failure, untested, undocumented, obsolete (no vendor support). However, legacy systems work, are business critical, are the system of record, and are familiar to the employees. Most importantly, legacy systems currently provide business value.

Next Amit and Derek define a legacy system as a system in which the quality has degraded to such an extent that it needs to be replaced. A legacy platform is a software or hardware system that is no longer supported. Thus, with time, the risk of using a legacy system gradually increases.

Amit and Derek then cover some options for replacing legacy systems. These include the build vs. buy option, the hiding the complexity option (usually does not work – nice front with spaghetti code behind), or the big bang replacement option(usually fail due to trying to create a prefect replacement). They give real word examples like Hershey’s ERP system, FBI Virtual Case Files, and Windows Vista.

It is important to remember that the real cost of systems is 10% to build and 90% for maintenance.

Amit and Derek next discuss effective legacy system replacement strategies and techniques:

1. Technology asset portfolio: Figure out where you are right now, what is the current state of the technology system(platform and software), what skills you have to maintain that system (operational, technical, and business skills). Based on that, you can figure out what kind of risks you face. How long is the system going to be around? How old is it? Who are the vendors that can support it?

2. Governance: Continually review your assets

3. Systems Health Check: Use several tools to visualize code complexity and ensure you have the basics of Source Control Management and Automation.


Some problems of migrating legacy systems:

1. Tendency exists to take existing logic and recode it as is on the new platform. No thought is put into new features. Sometimes, same bugs are ported over.

2. Code that no one knows what it does.

3. No benefit in investment until way later in the project.

4 Challenges and 5 Guiding values of Agile Software Development

At Agile 2009, Brian Marick shared challenges and guiding values in agile software development. Brian1st covered 4 challenges that we face when starting with agile development:

1. Courage: ScrumMaster should have the courage to create an open workspace even if it is against company policy. There job is to move immovable objects for the good of the team. ScrumMaster, business analyst, programmers (learn new languages), testers (learn automation) all need courage.

2. Working software: Open workspace appears to the outsider as noisy, messy, undisciplined, uncontrolled, and unprofessional. They will have the urge to restore order. As ScrumMaster, you have to resist that and the best way is to deliver frequently working software that is better than what was delivered last week.

3. Naiveté: Pair programming, test driven design work. Do not prejudge before trying it out. Have an eagerness to believe in the ability of the absurd. Much of agile is deeply counter intuitive.

4. Slicewise Design: Always taught to 1st build infrastructure and then drop features on top of it. Problem is that infrastructure comes too late. By that time, client has become inpatient about not seeing working software. 2nd new feature come up that do not fit in the infrastructure. Instead build a feature and try to delight the client. If not delight then work on the little changes to satisfy the client and then move on to add another feature. As you go along, you will end up incrementally (refactoring) building the infrastructure with the features on top of it.

Next Brian covers 5 guiding values of agile software development:



1. Reactive: Agile teams value fast feedback, and visibility, but also value being reactive. We have always been taught to be proactive. When coding and later we discover a better way to doing things, we can back up and go in a better direction. However, using version control, we need to know when to take a snapshot to enable us to back up to the right spot. Another approach is to have smooth programming process where we can code forward towards a better path instead of backing. We need to become good at reacting to new knowledge that we did not proactively deal with. Each time we do that we improve our skills and increase our opportunity to learn.

2. Ease: Image hammering with a hammer that has a loose head. You will constantly be concentrating to make sure the head does not fall off instead of simple hammering away. Typical software has short cuts and workarounds. Agile teams clean up awkward code to make it easier for the next person. It is uncompensated near term work for a teammate’s medium or long term advantage.

3. Solidarity: We will all fail or succeed together. Foster solidarity with the platinum rule instead of the golden rule of do unto others as you would have them do unto you. The platinum rule says do unto others as they would have you do unto them.

4. Decency: React to irritation or difficulty by treating fellow with decency. Don’t be afraid to lose an argument. In agile it is not a threat to be wrong. You can always adjust back in the right direction.

5. Joy: “This is the greatest project I have ever worked on” is the reaction we should have when working on an agile project instead of “We suck less now”. You should have the courage to bend your work in a joyful direction.

Brian concludes that you should drive the environment instead of having the environment drive or limit you. You should seek to gradually add ease into your work and make it fun.

This presentation is available on InfoQ at http://www.infoq.com/presentations/4-challenges-5-values