First of all, I don’t believe there’s something like Scrum Release Planning. Let me get this straight: Scrum is the alternative for traditional Project Management, it is not the substitution of Product Management. The PO is immediate responsible for setting up a Release Plan, and the ScrumMaster is responsible for requiring the Release Plan.
By the way, remember that the Product Owner role is a subset of the Product Manager. That is, the Product Manager is the best fit for being the Product Owner.
That said, what you are going to see in ScrumMaster trainings are the practices and values the ScrumMaster has to monitor thought the Sprints. I had the luck to have a short discussion about the Agile Release Planning during my training three years ago, but as far as I know that was an extra.
I hihgly recommend therefore this couple of posts about agile release planning:
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.
I came across this wonderful short post entitled “User Stories: Value and Size”. The most interesting paragraph for me is this one:
Maximizing work not done is the art of our trade. The business value of a story is looked into precisely for this reason. If you don’t have a good reason business value) behind a given piece of functionality (story), you are wasting time by working on it.
Brilliant. I can’t add more but this few words: If you are building products maybe finding the Business Value for a User Story is hard, really hard. But if you can’t find one, you loose credibility of the team. The team will have the feeling that you are making up the value of the feature. So talk with customers, talk with them a lot, talk with many of them in order to find how much the story is worth with respect the total price they will pay for each copy, and then project the revenue this story will have, given how much copies you are going to realistically sell. That will be just an estimate, but a very educated one.
Agile adoption is accelerating. It’s very common to find panelists or podcasters recommending the adoption of agile. Therefore, if you are thinking seriously about adopting agile, I have some important pieces of advice about the ScrumMaster role.
Resetting your Project/Product Delivery mindset
Don’t try fit the roles of agile into the traditional role structure of your company. Agile needs a complete different position structure. Don’t try to treat a ScrumMaster as a Technical Lead. Don’ treat a ScrumMaster as a Project Manager. Those roles are a not the same. That’s why is wise starting with a project, let it execute and finish for you to understand all the implications of having a new structure in the company. Note: when finding a good candidate for the ScrumMaster role, normally Project Manager or Technical Lead is a good fit after training and coaching.
ScrumMaster as a full time job
Don’t fool yourself thinking that there isn’t a more laziest job than ScrumMaster. Specially if the company is in the early stages of agile adoption. The impediment resolution is the hardest part when managing an agile team: Finding a suitable workroom, a taskboard, stopping chickens interference, monitoring advancements of the Action Items agreed last Retrospective meeting, monitoring progress along the Sprint, monitoring quality, convoking and facilitating meetings, fighting IT, promoting the vision, helping to find resources, pushing to keep the backlog, the taskboard, avoid the team over commit, avoiding confusion between tasks and User Stories, get the team committed, cheer leader, etc..
Every time the ScrumMaster role is degenerated to a part-time role, the Scrum practices are poorly followed at best.
Doing something because we really believe in doing it is the best moral code one can have, there’s nothing better than the celebration of reason and the standing of the “Why?”.
Doing something because I say so, because is mandatory make it sounds like “just because”. Even more, forgetting the “Please” particle ignores the existence of the order’s recipient, transforming him in a entity without volition.
Companies start loosing perspective when they start giving the message that in the company’s magnanimity, the employee has the job benefit of, well, having a job. That easily degenerate from leadership to direct management. Thinking that the employees don’t have any other job choices encourages patronizing. Ok, in the current economic turmoil, maybe job choices are really scarce. However, the huge challenges that such turmoil is creating requires a strong, adaptable and High-Performance company.
Surviving in the current market requires having a compelling performance purpose that exceeds sum of individuals goals. Requires joint work to integrate complementary skills. And guess what, just leadership can inspire a bunch of employees to do that.
There are several angles of good leader, however I want to focus in the foundation of leadership: Credibility.
James Kouzes and Barry Posner, authors of the best selling book “The Leadership Challenge”, lay out the common phrases many company employees have used to describe how they know credibility when they see it:
Leaders practice what they preach.
They walk the talk.
Their actions are consistent with their words.
They put their money where their mouth is.
They follow through on their promises.
They do what they say they will do.
People first listen to the words, then they watch the actions.[...] If people don’t see consistency, they conclude that the leader is, at best, not really serious, or at worst, an outright hypocrite.
Are you saying you are very innovative company but in reality you don’t have the money for a R&D Department or new Product/Services initiatives? Do you promise a extra benefit or promotion, but you are not sure you have the money to do it? Do you say you listen to your clients but your products and/or services hasn’t evolved for a while and they won’t? Do you say you are building something but zero effort is on it? Are you serious at all with this credibility thing? Good employees are smart and wary, specially technical ones.
Don’t ask for a leap of faith if you haven’t proved how trustworthy your judgment is. Don’t encourage a company culture where there isn’t any. Don’t complaint about lack of communication when you have enforced silos.
Commitment and loyalty are patiently built on credibility. Once they are built, and with the right skills, your company will go beyond surviving.
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.
Many productivity problems I’ve found in teams are closely related to collaboration barriers. Really, any time frustration or problem your team is up to, please take the time to see if the roots of the problem is because your team is not fitting the following description:
A group of people come together, create a sufficiently shared understanding of an equifinal meaning that enables coordinated behavior, and then the actual activities of task identification, decomposition, distribution, coordination, and integration of outcomes are accomplished in a manner that lasts long enough for the goals [...] are realized.
A False dilemma “involves a situation in which only two alternatives are considered”, states the Wikipedia, “when in fact there are other options”. Do you remember “If you are not with us, you are against us.”? Well, that happens when you fall in fundamentalism.
Fundamentalist anti-agilists got deeply offended because they say agile doesn’t follow a scientific approach, that it is offensive not treating Project Management as a Computer Science, alas! Turing is wallowing in his tomb!
Fundamentalist anti-cascadists say that traditional software management techniques are obsolete, that it ignores the innate nature of uncertainty of every software project, the virtue of self-managed teams always outperforms past management practices.
Before continuing, let me state clearly that I am a truly believer of High Performance Teams (HPT). In the way of getting a HPT you will inevitably ended up practicing the agile principles.
That said, HPT’s are not always needed. So practicing agile is not always needed. Although most of the software projects fall in the uncertainty levels suitable for Agile, there a bunch of cases when direct and cascade-like managing is the best fit, so a group, rather than a team is needed.
Take the case of some massive web agencies or software sweat shops (very common down here in Costa Rica), or a well established and reliable software migration processes. They are a typical production line. They’ve got efficiency through specializing and strongly documenting every phase of the project development (or better said: production line). Of course, there are parts of those processes that can be significantly improved by implementing agile practices. Even more, those kind of companies would want to jump to the “Product Creation” wagon where Agile is the best.
Be wise and take time for analyzing the complexity of the problem/project about to start. To do that, make your homework and use the Ralph Stacey’s Agreement & Certainty Matrix against the project:
Identifying management decisions on two dimensions: the degree of certainty and the level of agreement.
When issues are Close to Agreement and Close to Certainty, Stacey says:
Much of the management literature and theory addresses the region on the matrix which is close to certainty and close to agreement. In this region, we use techniques which gather data from the past and use that to predict the future. We plan specific paths of action to achieve outcomes and monitor the actual behavior by comparing it against these plans. This is sound management practice for issues and decisions that fall in this area. The goal is to repeat what works to improve efficiency and effectiveness.
That is: use Cascade.
When issues are in the edge of chaos (Complex gray area), Stacey says:
This is the zone of complexity where the traditional management approaches are not very effective but it is the zone of high creativity, innovation, and breaking with the past to create new modes of operating.
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.
More and more I see Products/Start-ups failing to sell once they go out to the market. Here’s my take on their main reason of failure.
Problem: The Product Manager has an Idea for a Product and starts throwing User Stories to the Team. The Team consumes them using the discipline they have devised by themselves thought the Sprints. Because we are doing Agile and Usability Studies, everything just have to end up fine, right? So at the end of the engineering effort the website will progressively go from glugging some sales to enabling more servers to control the fire hose throwing sale requests. Reality? if your are managing your product as I just described your are playing at the jackpot. You will have chances to have a fire hose throwing sales, but those chances are the same as hitting the jackpot.
Listen! Synthesize!
A Product Manager has to have conviction of his/her vision and the understanding that detractors will try to take the Product down, I mean, we live in the human jungle, don’t we? However, such a conviction has to be tempered with Company’s Business Strategy, market trends, with Subject Matter Experts opinions, and, most important, with fact your Product is changing the world for better, that you are solving a real pain. So listening has to be the key factor when envisioning a Product. After you have listened to all the aforementioned stakeholders the following two hardest steps are ahead: 1) Synthesize all that input into something really remarkable, feasible to implement and affordable for customers. 2) Communicate that synthesis to stakeholders and team in order to go for it.
The Mirage of Bad Assumptions in Review Meetings and Usability Studies
A Review meeting becomes obsolete if you don’t have a Subject Matter Expert to evaluate the Sprint results. If you are doing software for kids, guess what, the final acceptance word is for the kids to give, not for you. When I say Acceptance Word, I mean: From a Product stand point, we got a increment, which is apart from the achievement the team has accomplished. If the team delivers what you asked for but displeased your final user, congratulate genuinely the team achievement and blame your inability of transmitting what the user needed to be solved. Although is vital to have team members skilled in the Product domain, I strongly recommend not to have a SME inside the team. Paying consulting hours to a external SME disconnect him/her from the fear of trying to please the Product Owner. The SME doesn’t have to fear telling the Product Manager “Your baby is ugly” or “Your baby is cute but the bodysuit that is wearing today is horrible”.
On the other hand, Usability Tests are tricky. First of all, Usability Studies are not a substitution of Marketing Studies. The latter are inputs for the former. Why? Because as Usability Test Facilitator will always be able to find users that fit a wrong characterization of your persona. The persona can easily represent a market segment that is not big enough to make your product profitable.
Let’s dot the i’s and cross the t’s
Scrum and popular Agile practices are good to deliver complex products on time assuring Product Owner satisfaction and fulfilling his/her vision. But Scrum and popular Agile practices don’t cover all the responsibilities of a Product Manager, even more, the Product Owner role is a subset of responsibilities of a Product Manager. The ScrumMaster needs to receive a vision from the Product Owner to transmit it to the team. The Product Manager articulates a continuously validated vision and Product Strategy and then articulate a continuously validated Product Backlog. Don’t forget build an Agile Release Plan with clear milestones.
