Date: Thursday, 2/6/14
Time: 1:00 - 2:00
Location: Orange ballons
Format: Open discussion with attendees
This was a session that I proposed with the purpose of having attendees share their challenges, insights, techniques, and success stories of managing expectations of stakeholders and executives in their organizations. When introducing this session to the morning group, I mentioned that I certainly don't have all the answers, and was interested in input from others as part of the learnings and insights that all participants, including myself, could take away. Below are photographs of the notes, with some commentary on each.
We started to list some issues and some techniques:
The top three bullet points are issues that some people have faced, and the bottom three were some techniques that were used. Here is some more context for a few that aren't self-explanatory:
For photos from the session, go here.
- There is no silver bullet (as Fred Brooks wrote)
- Points don't work
- Differing debt and complexity make teams appear different that really aren't
- Whatever measure you invent can be gamed (developers do invent algorithms for a living)
- Why measure?
- Measuring can be used for differential rewards
- Measuring can be abused when poorly understood
- Repeat: there is no silver bullet
Projects vs backlog items? - create a separate backlog of project level requests
Planning horizons: 1 yr - vague plan and project description. Continue to refine. Teams should have a more solid plan 6 months out, continue to refine quarterly.
You can use generic velocity based on past performance to gauge known work and determine available capacity. Give a rough estimate based on scope to determine budget or based on budget/timeline to determine feasible scope. (Feature-driven projects vs date or budget -driven)
Get clarity on the important stuff early, not necessarily the details. Define what is in scope and what isn't. If you can't prioritize features, do you really know what you want?
Spend some time and money early to decide whether to spend more, I.e. is this project worth it?
Considerations for the value of the project:
- ROI? The value can be purely monetary or based on market factors.
- Cost/Benefit of the project and the project vs other possible projects. What is the opportunity cost and the opportunity lost for this project in general or the timing of this project compared to others?
- How does this project align with business initiatives and goals?
Ask the Five Why's for the project. Define a clear problem statement.
The Question Every Project Team Should Answer
The Principles of Product Development Flow by Donald Reinertsen
Liftoff: Launching Agile Teams and Projects by Diana Larsen and Ainsley Nies
Sent from my iPad
Format of the Meeting:
Explained how to read a CFD
Went through the various scenarios as a group to discuss the stories they tell
Some of the Insights:
CFD's are great Information Radiators
CFD’s tell great stories
It's important to have context of the CFD
Great way to see the flow of work
Could be used at a sprint level, release level, entire company level etc.
CyberSource, a VISA Company