Being a Scrum Master, in some ways, is harder than being a Project Manager, because the people on the project do not report to you directly or through a matrix management organization. A Scrum Master is charged; however, with keeping the team on task, setting up and facilitating team meetings according to Scrum methodologies, producing reports, and overall to help facilitate the removal of blockers to help the team to close sprint product backlog items, and deliver releases. It was challenging enough not having direct management responsibilities. Now add a new process, and few tangible, people management incentives, and you would think deploying systems would get more challenging. However, the Scrum methodology, an iterative process, an agile software development framework for managing software projects, once thoroughly adopted by team members, should make the deployment process more dependable, enables your consumers to see incremental progress of products, thus allowing for a course correction, while enabling your team to provide more refined estimates on releases.
A scrum team is formed from all sorts, software developers, release, or configuration management staff performing deployments, infrastructure staff managing hardware, representation from business constituency, and Quality Assurance traditional test or use case validation staff, which seem to be junior developers these days, and they all come together to deliver for each sprint.
As the Scrum Master, depending on the level of process required or desired from your organization, your role may be diminished to a glorified facilitator, if that’s what you believe is glorious. It may be a bit of fun, if you choose to make it, and if you have a great Scrum Master, and elements of a talented team.
NOTE:
A release is a set of sprints, and the duration of each sprint time is constant,e.g. there may be 6 sprints in a release, each sprint lasting two weeks. The duration of the of sprints should be static, and the Scrum master may even setup the calendar date and time in advance for the whole release.
I’ve dissected agile, scrum methodology into six major components, as it has been used in practice on several teams of the teams I’ve been a part of, using this methodology:
1. Meetings
For small or large corporations the agile team works, even if you have a very small team trying to deliver new functionality, and constantly in bug/fix mode, or a large team with a vast amount of resources. If you feel you are always having fire-drill meetings, put down the fire extinguisher, and listen up. There are fewer meetings with this agile process, in fact, if there are too many meetings, we might want to call the meetings themselves out as ‘Blockers’, which we will get to in a moment.
I recommend three types of meetings with agile teams that will help you both deploy and support your product: a daily stand-up meeting, a retrospective meeting, and a sprint open/close meeting, and the final sprint meeting may serve as your release end review.
The daily stand-up meeting, or DSU, should be at most a 15 minute session, which each member of the team says, what they worked on yesterday, what they plan on working on today, and any Blockers they might have. The scrum master facilitates these meetings, and if he or she hears a blocker announced, they try to crawl the group to get some assistance from the rest of the team members to remove the blockers. What can we do to remove the blocker, should be the resounding question, and anything that prevents your progress on the tasks assigned to you for your product backlog items (PBI) is a blocker. To back up one moment, a clarification PBIs are similar to change requests, or modification requests that you’ve worked with before, however, they may be written in an abstracted way, and then there are tangible tasks, which are ‘children’ objects are associated with the Product Backlog Item (PBI).
Next is the retrospective meeting, what can we do better next time, what did we do well this sprint, and so on. There is typically one of these retrospective meetings per sprint, just before sprint close. Finally, there is a Sprint Close and Sprint Open session combined that serves as a PBI demo for the completed items, and an assignment portion for the next set of PBIs to be worked on for the next sprint. This meeting is the bulk of where the processes takes place.
2. Product Backlog Items
In the initial Sprint Open meeting, you review all of the product backlog items, which may or may not have an associated business priority at the time. Some teams use 1 to 1000, where 1 is the highest priority, up to the 100th priority may get ‘Committed to’ for the current sprint, and anything over 100, may get deferred to the next sprint, e.g. 200+. Sometimes, if the team knows they won’t put a product backlog item in the current release, they set the business priority of the PBI to 1000, where it sits in the backlog to be reviewed for a future release.
During the sprint open, the business representative, with input from all of their sources, e.g. marketing, sales, assigns the highest priority to the PBIs they would like to go into the first sprint, second sprint,… and the entire release. This process may actually happen before the Sprint Open meeting with the development leads, who may understand the dependencies of the PBIs to help guide the business people. In attendance is also the scrum master, which is in most meetings to keep discussions limited on any particular item, for example. If the Scrum Master during any of the meetings finds the conversation drifting into a long, and drawn architecture discussion, the team may decide to make a separate PBI for the discussion worth typically 1 point.
3. Points
The Scrum master will sort the order of the Product Backlog of Items by business Priority, 1 being the highest, and that’s the order in which the team goes through PBIs. After each product backlog item (PBI) is assigned a business priority, the development team leads, in the Sprint Open, ‘commits’ to achieving them within the agreed sprint time. During the Sprint Open, the people on the Sprint Open (all team members) may add a bit of color to the description of the PBI, then it’s “Poker Time”.
4. Planning Poker
There are many free web sites, or utilities out there that help you facilitate planning poker. e.g., http://planningpoker.com/ or some teams just cut construction paper, and put a number on each page. We will use the web site in our example. EVERY team member logs onto the site, and sees a set of cards with numerical values 1/2, 1, to 100. Different teams do poker in alternate ways, but what you are supposed to do is correlate the entire effort you think it will take to deliver a particular PBI, regardless of your role or intimate knowledge of the PBI. You may ask questions to get an understanding of the request, but the idea is to vote on it, especially / even if you are not doing the work on the item. This process is more physiological in nature, and should alleviate any deflation, inflation, or wild guestimates over time (e.g. multiple sprints, or releases). There are natural habitual things people do when they provide estimates. The person may want to impress their boss, and provide a deflated, or aggressive estimate. The boss may in fact try to skew the inflation to the business representative(s) to put the product out ‘sooner than humanly possible’, or a person on the project may inflate their estimate to get more time than required on the project for whatever hedonistic reason. All players put in their score of effort, e.g. 1 = 1 person day, for example, and each card is facing down until all team members enter their cards, then the scrum master presses the button to flip the cards, and the negotiation process begins. The scrum master bargains with the highest and lowest scorers, “Can you come down from a 5 to a 3?” and “Would you be willing to go from a 1 to a 3?” to drive a consensus. The team members talk about why they scored a particular item a certain way, and eventually some consensus is reached without using the heaving hand, or the boss persuading the vote. This process helps over time give more predictable estimates from the team, and you may discover the average output of the team, with a few variable factors, such as blockers. In the Sprint Close, the Scrum master may actually show a graph, here are all the PBIs we committed to in this sprint, here is their point value, and here is what we earned, and here is what we tried to earn.
5. Demonstration and Deployment
If you say all sprints are two weeks, rain or shine, you have the sprint close meeting, demonstrate the PBIs that were achieved, and theoretically, each sprint can and may be deploy-able to every environment, including production, if required. Typically, you would wait till the final sprint close before deploying to production, but it doesn’t always happen that way, especially if we have a support bug/fix along the way. That’s why each PBI is discrete and deploy-able on each Sprint Close, so when you assign the item after the points are agreed to, and close the PBI, it must be thoroughly tested (by whomever), and ready for production, that’s why you may associate several tasks to a PBI, such as unit, module, and system integration test case creation and execution. If PBIs that are assigned to staff do not get updated with a status from Assigned to Closed, then those items during Sprint Close get reviewed during the second half of the meeting, in the Sprint Open, and the team decides if they want to move them forward to the next sprint, release, or to the backlog for a future release.
6. Incentives and Detractors
One incentive mechanism for the team is awarding team bucks. This can be a great way to award team members. Each person on the team gets imaginary team dollars, and they are to award monthly their allotment of team dollars to co-team members, and the team member should state some reason, however abstract, why they are awarding their allotment of money to this individual. So for example, the Scrum Master at the end of each sprint, month, or some frequency which makes sense for the release(s) will say to the team staff, it’s the closing of the sprint/month, and you should allocate your, let’s say five dollars, to your co-team members. Team members may divide their abstract money across a few of the team members. At the end of the release, the senior staff, it would be a business sponsor, who is funding the project, would do some conversion, and allocate a monetary value correlation. If it’s a large organization, there may be an internal store that sells company logo labeled supplies, so you might get a company mug, or tee shirt. I have used this technique in at least one place, and it is mildly effective. Depending upon team morale, they can be enthusiastic about it, or feign enthusiasm. Either way, win, win.
One infamous detractor to coming late to meetings or swearing during meetings is “The Penalty Jar”. I’ve used this technique, and heard about it in quite a few places. It’s a basic premise, your late to a meeting, put a dollar in the jar, change, or whatever. A collective donation, which is then used to perhaps buy pizza on the night of releases. Jokingly some managers might off hand swear lightly and put a fiver in the jar, just to uplift morale. It is a physiological counterweight effect, that depending upon the team attitude and company policy, some may say enforce swearing, but it’s light handed, and the fiver is meant to imply the manager is ‘paying forward’ to encourage the team toward the end goal, the release.
Conclusion:
I hope this was an easy read. Many teams are using these methodologies today, but surprisingly, some have yet to adopt this process. At times, this process may be challenging when interacting with on and offshore teams that have great differences in time zones because teams prefer to have the DSU in the morning or midday the latest, while the blockers are fresh in their minds, and able to help others get un-blocked after the call. I’ve seen it work well with a 9 AM <->12 PM timezone delta although it could be done with a middle person playing the role as the off shore liaison. However, even if there are no language differences, the lack of full team interaction may inhibit team members to unblock someone for some cases, which require direct peer to peer team staff interaction. Alternately, staff sometimes work off-shift to solve some blockers.
