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

Lean Product Discovery

Jeff Patton gave a talk at the UK Lean Conference 2009 on Lean Product Discovery. Jeff starts by sharing a story on how the most influence moment in his life came when he sat behind someone using software he created. He discovered that understanding what people wanted is critical to delivering value to them.

Jeff mentions that in software development we are balancing 2 concerns:

1. Delivery: building of a software product. Analysis, design, coding, testing, documenting… This side is visible.

2. Discovery: learning about the outside world and our product in it. Understanding the world, understanding the product, what problems it solves, what value it provides and how it fits in the word. Understanding customers, market, competition, users. Prototype and validate user experience, create UI, validate working software.

Discovery (problem customers have) and delivery (the solution) work hand-in hand and overlap as we deliver product increments.

Jeff notes that healthy delivery process build software incrementally. It requires a fully formed idea (up front discovery), accurate estimation and upfront product assumption. If we don’t continually ask if this is what we want to build we might end up off in terms of quality and final result.

We need to balance delivery with discovery. Traditionally we are out of balance. We do a lot of upfront discovery and then do only delivery. However, after delivery we learn more from users using the product and then we are back in balance between discovery and delivery, but this re-balance happens very late in the game. Jeff gives an example of drawing a painting, starting and completing one section and then moving on to another section and so on until we finish the last section.

Iterating and incrementing leverages discovery to iterate as we deliver. This allows us to move from vague idea to realization making course correction as we go along. Jeff gives an example of again drawing a painting, however this time we start with a rough sketch of the entire picture, then we fill in more details, and then we add some colors, etc...

Next Jeff discusses how to break things down in a way that lets us balance discovery with delivery. He recommends breaking down large features using these four splitting heuristics:

Agile PMP

At Agile 2009, Mike Cottmeyer presented Agile PMP. Mike starts out by defining traditional project management from a PMPs perspective as managing the 9 knowledge areas of the PMBOK. He defines agile as a combination of engineering best practices, a leadership framework, and project management techniques. The PMBOK and Agile are not exactly the same. But the skills of a PMP are still valuable in an Agile project.

In traditional project management, we are trying to remove uncertainty. We are trying to learn enough up front so we can plan. In Agile we do not to take uncertainty out of the equation. We want to embrace it and manage it.

Next Mike reviews the Agile Manifesto and discuss how we still value the stuff on the right, but we value the stuff on the left even more:

1. Individuals and interactions over processes and tools

2. Working software over comprehensive documentation

3. Customer collaboration over contract negotiation

4. Responding to change over following a plan

Then Mike describes how agile inverts the iron triangle and says cost and time are our primary constraints. We need to figure out how much are we willing to spend and how long are we willing to give it and then figure out what we can deliver within those constraints.



Mike describes time management as breaking the project into releases and breaking the releases into iterations. Iterations are fixed in duration and do not overlap. The milestones are defined 1st, and for each milestone we define how much scope we can fit in it.

In software cost management in generally based on the amount of people on the team. Cost is the amount you are paying people times the time you are giving them.

Scope management is done by rolling wave planning or progressive elaboration, Epics (high level needs and goals) are defined at the project planning level (18- 24 months), features are developed during release planning (3 – 6 months), and stories are detailed during iteration planning (2 -4 weeks). We let details emerge as we learn more and more about the software we are building. At the iteration level is when we make the hard commitment.

Pragmatic Personas: Putting the User Back in User Stories

At Agile 2009, Jeff Patton gave a workshop about how to design and build software that has a better user experience. Jeff starts out by reviewing the different ways that software is built.

• FUBU: For Us By Us. Start with idea to build something for us. Product is built to solve a certain problem we face. Then audience diversifies and product evolves and no longer becomes for us
• FMBY: For Me By You. We take down requirements and hope that everything comes out OK.
• MSU: Making things up design.
• FTBU: For Them By Us.

Jeff explains that if a product is good, it is built for the people that will use it and that is not us.For them by us is user centered design. To build a good product we need to care about the user. Another way is to keep asking users what they want.

Jeff defines a pragmatic persona as a quick exploration of what we know about our users. We want to build them to start discussions about what we know and don’t and help drive mapping your user experience using stories.

Next Jeff goes over the process of creating a persona by walking through an example of a restaurant review application:

1. Identify kinds of users (user types or roles)

Determine the criteria that makes each type distinct. Identify high priority or focal types.
Think of different kinds of people that will use your product as user types (college students, business professional).
A user role describes the relationship a person has with your product. We change roles like changing hats. Think thing-doer (late night pizza buyer, daytime lunch seeker, penny pinching pizza buyer, married daytime lunch seeker). Isolate aspects that are relevant.
Next prioritize. The user types that are the most relevant to design depends on the business and product goals. Figure out which user types are most critical to achieve the goals and objectives. Refer to these user types as focal or primary. A typical system will have 2 or 3 focal users and several more that aren’t (make sure these are listed as well).

2. Profile Users (start with assumptions about users and then add additional info by doing research). Identify information about users relevant to the product. Profiling adds general information to user types like sizing, gender, domain knowledge, pains, goals, motivation, general activities, context, frequency, collaborators, and other products they rely on.

Kanban Adoption at SEP

Chris Shinkle gave a talk about Kanban adoption at SEP during the Agile 2009 conference. Chris described the Dreyfus Model of Skill Acquisition and showed how the team at SEP progressed from one stage to the other as they learned and applied Kanban.
Stage 1 – Novice: Little or no previous experience. It is about following context free rules. No discretionary judgment. Want to accomplish a goal, not learn. Team had clear understanding of project, clear priority of work items, and clearly see progress from the introduction of Kandan boards and standup meetings.

Stage 2 – Advanced Beginner: Still rules based, but start understanding rules within context and based on past experience. Team understood WIP (work in progress) limits, began to collaborate and identify bottlenecks and areas for improvement.

Stage 3 – Competent: People recognize patterns and principles. Rule sets become more rules of thumb. They start to establish guidelines and seek out and solve problems. They see actions in terms of long term plans and goals. The team felt a sense of ownership. They started pulling in alternate practices to optimize the process and solve specific problems. They began to discover and understand lean principles themselves. Things like cause and effect of flow, value, quality, quality, and waste.

Stage 4 – Proficient: People seek out and want to understand the big picture. They perceive a complete system instead of a set of individual parts. They can learn from the experience of others and take full advantage of reflection and feedback and correct previous poor task performance. The team starts to focus on throughput and reducing cycle time. They began to focus on optimizing the whole and reducing the cost of delay and WIP limits. Kaizen moments became more common place.

Stage 5 – Expert: They can look at each situation immediately and intuitively take appropriate action. They know what to focus on and can distinguish between important details and irrelevant ones. Chris’s teams haven’t reached this stage yet.

Chris believes that it is ok to talk about principles but teaching principles does not equate to acquiring a new skill. Kanban provides a framework where principles can be introduced. Then the process in and of itself is going to help encourage those behaviors and allow people to understand them at their own pace.

Next Chris shares the lessons learned:

1. Start by teaching practices, not principles

2. Don’t set WIP limits too low for a new team

3. Keep rules about moving tokens/cards simple

4. WIP is strongly correlated to product quality.

Finally, Chris concludes by stating that Kanban teams mature in a way consistent with the Dryfus model. Kanban is an effective tool for teaching lean principles and managing change in an organization. There multiple levels of maturity and at each level certain behavior guide your focus.

This presentation is available on InfoQ at  http://www.infoq.com/presentations/kanban-at-sep