Wednesday, January 20, 2010

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:

Friday, January 15, 2010

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.