In the making of a new product, you have some very few proven assumptions (realities) and a lot of not proven ones. That’s good because those assumptions gives an interpretation of reality, a set of axioms that serve as a starting point to build that product that will change the world, as you are assuming it is.
Failure appears when something you assumed proved to be false. That’s the time to review our axioms, with the honest willingness to change them if necessary.
For a Product Management perspective, the longer you wait to realize an assumption is false, the more expensive it is to change what you built over that assumption.
The “cost of changing what was built” as time passes and the probability of the happening that in fact it was a bad assumption is what I understand as risk.
Here my six practices to embrace and live comfortably with assumptions, risks and priorities:
Associate a risk numeric value to each assumption.
Associate a risk description and the correspondent assumption to each User Story.
Before starting the product development, be sure to have cleared all the higher market, platform, technology risks.
Refine your persona.
Talk A LOT with users fitting your persona.
Continue refining your persona in the process of talking.
Review market penetration of the platform and technology used by your product.
Review market trends.
Review the Business Strategy of your company.
Star developing those User Stories with higher Business Value and those with the higher risk associated. Answer the tougher questions first.
Pay consulting services to a Subject Matter Expert to review the iterations increments. This is a review process independent, not related to the Team Review Meeting. Remember the team presents the increments to the Product Owner, not to the SME, at least of course the PO is the SME.
Start a customer base, even when you have only the concept of the product.
This video is kind of old, but it gives me good stuff to ponder around why agile became to exist:
First of all I don’t like the indiscriminate use of the word “requirements”, it easily buries the fact that a real human has goals to accomplish with the product we are building. Going from user’s goals to specific software requirements is a very delicate process. That’s why I prefer the agile term “User Story” instead of “Requirement” because it preserves the link to the final user. This format is great:
In order to <achieve some value>, as a <type of user>, I want <some functionality>.
However, for the sake of a fluid analysis, let’s keep using the video lingo and discuss each point:
0:13 We are 4 months in to 5 months schedule and I just received the final requeriments yesterday. (And they’ve changed again!)
There’s nothing wrong in changing requirements. That happens all time and it is normal since the final client/customer is reviewing each iteration of course he/she would have a better understanding of what he/she wants while it’s taking shape. It becomes a problem when:
The boss wants to change a Requirement in the middle of the Sprint. He can’t do that. The team commits to deliver a set of User Stories at the end of the Sprint. It is just impossible to deliver the same amount of work in half the time. When some emergency occurs in the middle of the Sprint, it’s time to cancel the Sprint and to start another one, with its proper Planning Meeting for team commitment. When this happens frequently, the boss has no idea where to go. Someone has to scale this and the ScrumMaster, as team protector, is the most appropriate dude to do it,
The project is fixed price and the customer is requiring something that is out of scope of the contract. If so, the contract should have included a foreseen process of Change Request. The Change Request establishes the criteria of charging for extra functionality. If there isn’t a Change Request clause, things are tougher and renegotiation is required. The team is always able to review the Agile Release Plan with new dates or new User Stories.
0:22 I spent half my days in meetings about about how to get more work done. (Instead of working)
Be Lean! Eliminate the waste! Kill unnecessary meetings, make them effective! Certainly Retrospectives able the right tools for detecting productivity problems and for setting corrective Action Items. But if the team is unable to correct a clearly measurable productivity problem after several sprints, you may have a lack of skills problem or a measurement problem.
0:30 My boss read in a magazine that developers using “__” programming language are twice as productive. So he bought us a copy and cut our schedule in half
This is nonsense. Who is responsible to actually put all the bricks of the building? It’s not the Product Owner. The Product Owner needs to have the mental powers to say: “I need this building to make a lot of money”. The developers say: “Ok, it”ll cost you such amount of money in such time”. Who is the Product Owner to say otherwise? What could follow is long conversation about how Product Owner explains functional characteristics of the building, time and costs constrain; while the developers explain what can be done given the constrains and the tools (programming language for instance) available. From a development stand point, the team commits to deliver the Product, the Product Owner doesn’t. The boss can’t commit for the team. The boss can commit with superiors/client once the team has given him the commitment.
0:49 Every day my boss changes his mind about what we’re building
See 0:13
0:56 Dad: People keep asking me to fix their email, so I have no time to code. Son: My daddy has no time for me
Impediments and tasks unrelated to the Sprint are the ScrumMaster’s concern. This can’t happen. A commitment can’t be accomplished if you are not fully committed and accountable. You are in the team or not. If you are inside the team, you can’t attend to unrelated meetings, you can’t run CEO’s errands or whims, at least it’s part of the iteration’s commitment. The ScrumMaster need to have a thick skin to eliminate such distractions at once.
1:10 Some consultants told my boss they could build our next version in half the time, for half the money. He believed them but now they’ve have spent all their budget, used all their time and… are still half finished. Now they are gone and their code is a disaster. We have to fix it and finish what they started.
See 0:30
Eliminate the nonsense
If you pay close attention to the problems pointed in the video, they are flagrant negation of good sense. Set the expectation clearly, set the accountabilities clearly.
Making an unshameful copy-paste act, the list goes like this:
1. Understand that all problems are not the same. So why are your meetings? Does every issue deserve an hour? Why is there a default length?
2. Schedule meetings in increments of five minutes. Require that the meeting organizer have a truly great reason to need more than four increments of realtime face time.
3. Require preparation. Give people things to read or do before the meeting, and if they don’t, kick them out.
4. Remove all the chairs from the conference room. I’m serious.
5. If someone is more than two minutes later than the last person to the meeting, they have to pay a fine of $10 to the coffee fund.
6. Bring an egg timer to the meeting. When it goes off, you’re done. Not your fault, it’s the timer’s.
7. The organizer of the meeting is required to send a short email summary, with action items, to every attendee within ten minutes of the end of the meeting.
8. Create a public space (either a big piece of poster board or a simple online page) that allows attendees to rate meetings and their organizers on a scale of 1 to 5 in terms of usefulness. Just a simple box where everyone can write a number. Watch what happens.
9. If you’re not adding value to a meeting, leave. You can always read the summary later.
Seth Godin is a genius in the marketing arena and product development and you better subscribe to his blog to get digestible chunks of wisdom on a frequent basis.
To that list I want to add:
Make everybody clear how much money the meeting is costing. Sum all the fractions of involved people’s salaries invested in being gathered X amount of time.
Boldly leave the room once the egg timer rings or when your have detected that the meeting has been ineffective.
Don’t wait for your boss. If your boss is late and anyone else is on time, start the meeting. Be consistent with the policy. Make him pay the fine as anyone else.
Identify issues that can be effectively resolved in the meeting.
Define clear Action Items to deal with detected issues that need to be resolved out of the meeting.
Set a person to take accountability on the resolution of the issue.
Measure the issue and set the metrics to know if the issue was clarified or resolved.
At the end of the meeting, review all the agreements reached, action items and people responsible for those action items.
