|
|
|
Thursday, March 17, 2005
This morning I hope to attend Mary Poppendieck's talk overviewing product development techniques which will greatly enhance your project efforts. Mary will argue that you need to take a look at the full lifecycle of a project, both the development cycle as well as what happens once it's in production, if you want to get it right. You also need to take an incremental approach to both learning and funding as you proceed during development.
I've attended Mary's talks before, and have been lucky enough to have some very interesting conversations with her, and have always learned something which I can apply in practice with my clients.
6:04 AM
Don't forget the importance of working with project/program manager for project success.
Interesting points made:
1. Products are ongoing things, not just the development of a single release.
2. Product development funding is usually a stage gate approach, it's funded on an ongoing basis depending on need/viability.
3. With an earned value approach to measuring project success, quality and customer satisfaction often falls between the cracks.
4. Delivering to a specification doesn't gaurantee that you've delivered something someone wants.
5. To measure product success you measure by the golden triangle (customer satisfaction, time to market, and market share). Profitability is the key measure. However, scope and cost often falls between the cracks. With product-based approaches you want to spend money to make money.
6. With a product-based approach, the development team remains with the product over time. They maintain tacit knowledge, they only need conscise useful documentation because they're going to have to use it themselves.
7. The product team needs to maintain a balance between maintenance and new features. They must also maintain contact with users.
Best practices from product management which we can apply on software development projects:
1. You should take an experimental approach using short learning cycles (iterations) with hopefully an early release to production.
2. Long-term release plan should be large grained, and is subject to change based on feedback. I wrote this concept up at www.ambysoft.com/essays/projectPlanning.html
3. Think product lifecycle, not project/release. You'll be living with this thing for years (IMHO, this is critical to success, and is one of the drivers of the addition of the Production phase in the EUP, www.enterpriseunifiedprocess.com).
4. Streamlined information flow is critical. You want good communication between the customer and technical team. You also need upstream (architects, designers, ...) and downstream (help desk, operations, maintenence folks, ...) technical people working together effectively. A good book is Product Development Performance by Clark and Fujimoto (early 1990s).
5. Another good book is "The Toyota Way" published in 2002/3. One of the things that they do is condense what they know into single sheets of paper.
6. One of the fundamental wastes is hand-offs between people/groups. It's better to have a cross-functional team that works together, not specialists handing things off between each other.
7. You want to support condensed learning by using effective artifact practices. Well written requirements requirements, perhaps one page use cases, and common code ownership is critical. You want to use the best artifact for the job, a primary message of Agile Modeling (see www.agilemodeling.com/essays/modelingTechniques.htm for exactly this sort of advice).
8. Continuous builds and tests are very useful because they provide rapid feedback.
9. Why not make your SRS as executable tests instead of a written document? A huge portion of your SRS can be replaced with tests, reducing your documentation and traceabilty burden.
More good ideas:
1. Step one is to simplify your problem. Get your business process as simple as possible, then automate it.
2. Integrate in small steps. "Big bang" integrations, e.g. waiting to QA at the end of a project, is a major mistake. Test and integrate as you develop.
3. Refactor aggressively, keeping your code of high quality at all points in time.
4. Anything that is hard to do you should do more often, so you can get good at it. For example, if you know that your code will need to change to support changed requirements, you want to get good at changing it.
More good ideas:
1. You want to rotate people through different groups/positions for broad understanding.
2. People should have increasingly demanding assignments to help them grow.
3. With set-based engineering, critical decisions are scheduled at decision points. You want to make decisions as late as you possibly can, as best as you possibly can at that time. Your designs should converge over time.
4. At the beginning of your project, you have feasability decisions to make. This is likely one of your highest risk points.
5. Deciding as late as possible is determined by your situation. People who are expert in a domain are good at this sort of thing. It's hard to define a generic process for doing this, you really need to know what you're doing.
6. Complex sheduling systems never work in the face of variation, surprises, and unknowns.
7. You want to reduce your cycle time. In software development this is the time that a stakeholder defines a need (e.g. requirement) and software is provided fulfilling this need.
8. You want to reduce variation, and the best way to do that is to have small work packages.
9. You want a steady rate of service. A good way is time-boxed iterations.
10. Avoid queues in your process. E.g. approvals, serial development processes, lengthy deployments.
Some of the factors that are
influential to the outcome of a
software project can be seen at:
http://www.davidhecksel.com/projectcontext/projectcontext.html
http://www.davidhecksel.com/projectcontext/whitepaper.html
David Hecksel
http://www.davidhecksel.com
Some of the factors that are
influential to the outcome of a
software project can be seen at:
http://www.davidhecksel.com/projectcontext/
projectcontext.html
http://www.davidhecksel.com/projectcontext/
whitepaper.html
David Hecksel
http://www.davidhecksel.com
Hi Scott W, Ambler. I've been looking for downloadable software information and came across your site. I was really after downloadable software related info but I came across your site and found it a good posting even though What's Wrong With Projects? was'nt exactly what I was after. Thanks for the read
Hello Scott W, Ambler. I was looking for some information on cad software and came across your site. Not really what I was after but I found it very interesting. I was looking for cad software related information. Glad I found your site even though it was not exactly what I was after. Keep up the good posting - thanks
Hello Scott W, Ambler. I was looking for some information on small business software and came across your site. Not really what I was after but I found it very interesting. I was looking for small business software related information. Glad I found your site even though it was not exactly what I was after. Keep up the good posting - thanks
Ich bin endlich, ich tue Abbitte, es gibt den Vorschlag, nach anderem Weg zu gehen. cialis bestellen forum cialis online [url=http//t7-isis.org]levitra online[/url]
Felicito, que palabras adecuadas..., el pensamiento excelente http://nuevascarreras.com/cialis/ cialis generico espana Quale messaggio di talento [url=http://nuevascarreras.com/cialis/ ]cialis 5 mg [/url]