You adopt practice to “make the team go”. However, every practice you adopt has a cost. The time you spend “making the practice go” is somewhat then a cost of making the team go. I like to talk about the cost of your practices as “Feed the Beast!” But what you really want to make your team go is to “Ride the Beast!” where the practices we have adopted start to carry the team faster than they could go without them.Continue Reading
Posts Tagged with scrum
Sprint Rationale
People tend to use the terms Sprint, Iteration, and Time box interchangeably. For the most part this is true, but there is some nuance:
Sprint is a term popularized by Mike Beedle and Ken Schwaber in creating the Scrum methodology. They chose the word because it implied a desire for fast pace. It’s not a death march (Yourdon), its a sprint.Continue Reading
Agile Delivery Manager vs. Project Manager
When you adopt agile practices, especially agile life cycle plans – it is really simple to have your project manager become the scrum-master, right? Isn’t that what everybody does? After all, it’s just swapping a gantt chart for a burn down chart, right?
It certainly is what all of the project managers do when their companies start to adopt agile life cycles – but is it the best thing, or even a good thing? Continue Reading
Product Owner Training
How do you develop the mindset and skills needed to be a successful software product owner?
In a technology organization, (software vendor, tech startup) product owners tend to come out of a technology background. They are ex-developers, ex-architects and sometimes ex-sales engineers.
In a non-technology enterprise (a normal company) the product owner is more likely to come out of a business background. In client facing software products, that background is likely to be marketing or business product management. For internal facing software products that background is likely to be that of a business practitioner, or a business analyst.
Regardless of background, product owners need to be able to do the following activities:
- organize stakeholders into specific communities based on desire for specific value delivery.
- sell the existing value propositions of the product into the stakeholder communities.
- elicit new value propositions for the product from the stakeholder communities.
- distill problem statements / value deficiencies from specific feedback from stakeholders.
- maintain a prioritized/sequenced backlog of deliverables, contemplating the sponsoring stakeholder community, value proposition and business strategy.
- sell/explain business value propositions to technical team.
- evaluate whether proposed technology solutions add the value expected by stakeholders.
- develop high level test cases for acceptance for each deliverable.
Maybe there are some additional things, but this is the core list. You can see that depending on background, some might gravitate to activities from this list that are more comfortable. Training product owners is about helping them grow abilities to perform outside their comfort zone.