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.
