A new friend in Beijing sent us this. It’s always exciting to see your app in other languages—stoked we got featured in the Microsoft Store!
Here’s a quick read from InfoQ. Author Paul VII gives us Scrum confessions that reveal mistakes he made on the job and how he used them to improve.
Table of Contents
- Scrum Introduction and Recap
- The Characters
- Confession 1: Tools vs. People
- Confession 2: Release-Planning Peril
- Confession 3: Intro to Scrum Gone Bad
- Confession 4: Stand-Up vs. Sprint Review
- Confession 5: Taking the Team to Task
- Confession 6: Retrospective Regret
- Confession 7: The Bloated Bug Backlog
Topics sound familiar? You are not alone. Each is worth reflection. Maybe even a discussion with your team.
Reality… average velocity changes throughout a project. For any number of reasons—level of work, its difficulty, spikes, staff changes, holidays, etc. No two sprints are the same in terms of content so it’s not reasonable to expect velocity to stay the same from one sprint to another. Therefore, it can’t be the only variable to use to predict your final sprint.
Backlog changes too. This is normal. It just makes project tracking difficult unless you have a tool like NextWave ScrumMaster™.
Reading Mick Cohn’s article, Alternative Release Burndown Chart, reminded us why we designed the interactive ScrumMaster™ Burndown graph to project and handle backlog, velocity, and end dates the way we did.
As Mike points out,
“For example, suppose a team had expected to make progress of 40 hours, points (or whatever) last sprint, but the burndown chart only shows net progress of 10. Was the team slower than expected, or was more work added to the release?
It’s important to know the answer to this question, because we cannot really predict when the release will be done without it.”
Absolutely, and Mike shows you how to handle it using Excel.
Or, you can let ScrumMaster do the work for you and then some. As you can see in the video, ScrumMaster automatically projects your ending sprint. It also shows you when, where, and how your backlog grew.
If you are using ScrumMaster, here’s how it differs from Mike’s Alternative Burndown Chart.
- Projections to finish date are simpler… and ScrumMaster does it all.
- Want to see the trend line to project finish? Choose the Average velocity menu option and you get the classic projection.
- Backlog is automatically adjusted at each Retrospective (purple dotted line). You don’t have to add anything.
- All task work is color-coded, Original work plus any new work (Added tasks, Issues found, Software bug, Spike, Technical debt, Meetings). There’s a ScrumMaster Report that tracks and analyses Backlog by type, by sprint.
- You can select confidence levels for velocity and backlog estimates, to make automatic percentage adjustments to the projected ending sprint. The greatest impact is usually seen early in the project cycle.
Make sense? Give us a shout if you have any questions or comments.
At NextWave, we’re Agile. Not just in the way we develop applications and how we put ourselves, our company, and our products out there.
We appreciate the fact that Life is iterative, at every level. And an experiment.
“The problem is that quality is really in the eye of the beholder. For a for-profit company, quality is defined by what the customer wants.”
~ Eric Ries
That would be YOU. For us to constantly improve, we need to know what you like and don’t like about any ScrumMaster application. Speak up! Share your experiences with our blog site community. Feedback and quality go hand-in-hand.
And if you’re not familiar with Eric Ries and some of his thoughts about Lean Startup, you may want to check him out. Here’s just one interview with LinkedIn Executive Chairman and co-founder Reid Hoffman about what quality should mean for entrepreneurs.
Very excited about this latest release, available in the Microsoft Store. If you’re #Agile and running any ScrumMaster version, you should automatically receive an update notice from the App Store.
The new Get More home page menu item organizes Store links, Release notes, and upcoming enhancements.
Make Scrum dogma your own. Take what you need, leave what you don’t. Here’s one more option to add to the article’s list.ScrumMaster™ gives you the option in a Retrospective to take credit for work completed in the sprint. It automatically renames the remaining tasks and returns them to the Backlog… ready for evaluation at the next sprint planning session.
No, this isn’t orthodox Scrum procedure. But it makes sense, doesn’t it? It cleans up reports, too.
Sometimes we need help to improve our team and sharing insights into why some practices and behaviors can sabotage team progress. Take a look at the following observations teams have made to see if your team can identify with them and take action before it becomes a bigger or longer term problem.
We have a lot of stories that are closed by DEV and then new stories for QA testing are created to test what Dev hands over.
Impact to the Team:
- Because the number of stories in the sprint steadily increase during the sprint, the burndown chart will likely look like the team is always behind schedule.
- Individual capacity is extremely difficult to plan during sprint planning because the number of stories at the beginning of the sprint will be lower than reality.
- Forecasting sprint plans and project schedules via velocity is useless here because the…
View original post 988 more words
To our way of thinking, Brian Lawrence nails it. From the stony silence (and arrogance) he received when he broached the topic in an Agile group meeting to his concluding points. However you implement Agile, it needs to fit well with your team structure and needs—and expect those needs to change over time.
Companies, organizations, projects, and teams are unique. Size, project scope, and team talent varies. One size—one dogmatic Agile approach—can’t fit all, even if it’s a good place to start.
The definition and expectations of the Scrum Master role in a work environment shape the type of challenges faced when implementing an Agile approach.
A team may find the natural progression of Agile in their company not only evolves the job of Scrum Master into a rotating role that anyone can do, for some teams, that role becomes that of a scribe: the primary responsibilities are to run rituals (sprint planning, daily standups, and retrospective meetings), record changes in task status, and identify impediments and solutions that need to be escalated outside team.
It helps if everyone is clear about the Scrum Master’s functional role within the team and relative to the rest of the organization. Is the Scrum Master the Scrum dogma enforcer? An Agile approach coach? A mentor in Scrum methodology? What flavour, strict ‘orthodox’ or ‘reformed’? Couldn’t agree more, top down mandates don’t optimize teamwork or efficiency. And when the project stalls, the “I followed every Scrum rule in the book” isn’t a valid management defense or excuse! The only goal is to deliver superior product, on time, on budget. And not make your team’s life miserable in the process.
Does the Scrum Master work with the product owner to establish priorities from a BUSINESS perspective, or is that handled by the Dev Lead that has a deep understanding of the individual project under discussion? If you do rotate the Scrum Master role, you may need to separate out that function.
Having lived in these trenches, this is exactly why we built the NextWave ScrumMaster™ Agile project management tool. Our work tools have to be flexible. We need to be able to use them as it makes sense in our individual situations.
Posted by Brian Lawrence
Nov 05, 2013
The Scrum Guide generally describes the Scrum Master role as one of teaching, coaching, facilitating, and removing impediments. And when a Scrum team is new, these things take time. A team new to Scrum tries to follow Scrum by the book and needs someone that can do a lot of teaching, coaching, facilitating and removing impediments. But what happens when the delivery team matures? Teaching lessens. Coaching lessens, though there is still need for coaching around constant improvement. Facilitating is still necessary, though this takes up very little time. And impediments lessen as the team learns to deal with them on their own. If one of the team members’ full time job is teaching, coaching, facilitating, and removing impediments and all these things have lessened to where that person is only needed ten to twenty-five percent of their time, what do they do the rest of their time?
For us, we took the following path. We started with Scrum, though I wouldn’t say strictly by the book. We came from a world where we had project managers running multiple projects, thus working with multiple project teams. Our first step was to train our project managers in Agile. Several of them took advanced courses. A couple even became certified Scrum Masters and Agile Project Managers from the Project Management Institute. Thus, our project managers (PM) became our first Scrum Masters. Due to resourcing constraints (we had more teams than PM’s) and possibly due to a little foresight, we did not immediately dedicate a Scrum Master to a single team. Yes, that’s right, we violated one of the Scrum rules right from the start. Each of our PM’s generally had two teams they worked with as the Scrum Master. This kept them busy, but did not overwhelm them. Their role, as you might guess, was to teach and coach the teams in Scrum, to facilitate the Scrum ceremonies, and to remove team identified impediments. And this worked for the first nine months to a year.
Fortunately for us, our Scrum teams matured. It became apparent to me that our set up with using PM’s for Scrum Masters was starting to become a problem when during employee one to ones I kept getting asked just what value the PMs (notice they were not referred to as Scrum Masters by the team) were adding to their team. The delivery team members felt like they were being over-managed by multiple people. They had their own functional managers and they had Scrum Masters who were not really part of the delivery team.
We made our first change in the structure. Each team was allowed to select their own Scrum Master from among the delivery team members. The Scrum Master would still be responsible as a full time delivery team member, but they would also facilitate the Scrum ceremonies and be the first point of contact for impediments to the team. What did we do with the PM’s? At first we left them as PM’s – doing some project management stuff such as cross-team coordination. But we also left them as Agile coaches. And coaching became something a delivery team asked for, not something that we imposed on them. This worked well. Those teams that were more mature in their Agile approach and understanding didn’t feel over-managed. Those teams still coming up to speed had someone they could go to for coaching.
One more minor transformation occurred as we continued to mature. We elevated the PM’s to program managers rather than project managers. They now became responsible for cross-team initiatives. These are projects that transcend products and have tasks / stories in multiple delivery teams. We also rearranged our management reporting where we went from functional managers / supervisors to delivery team managers / supervisors, a role we call the delivery manager. And it is the delivery manager that is now responsible for the Agile coaching and mentoring. We’re still working the kinks out of this model, but the teams are delivering well, so it seems to be working.
For us, Scrum Masters started as positions and evolved to roles as we became more Agile mature. We took the responsibilities of a Scrum Master and divided out the coaching / teaching parts from the facilitation / impediment removing parts. This works well for us allowing the teams to feel self-managed and allowing them to mature at a sustainable pace, as coaching has become something asked for rather than imposed upon them. It also allows more team members to experience the role, as many of the teams will rotate Scrum Master at set time periods. And we’ve found that any type of delivery team member can be a Scrum Master. We have business analysts, developers, and QA testers all being Scrum Masters. We’ve also found that even the coaching / teaching is staying within the delivery teams with the Scrum Masters, as the ones that gravitate to that role are the ones interesting in learning Agile principles and imparting that learning upon their teams.
Finally, the bottom line that makes management happy is that we have less people doing the same amount of work. We have sixteen delivery teams. Without the need for dedicated Scrum Masters, we’ve saved the need to have sixteen more people and with a fixed budget, that really breaks down to being able to have sixteen delivery teams, rather than only having thirteen teams because we’d need those extra people to fill a position that’s really a role.
My concern and the reason for this article, is really a warning to all of you out there beginning your Agile journey. If you hire a slew of full time Scrum Masters, which is happening at least here in St. Louis, you need to have a contingent plan as to what you’ll do with them as your delivery teams mature. And at least here, most of the Scrum Masters being hired are coming out of a project management background. Nothing wrong with that, but again, be prepared to answer the question, “Okay, now what do we do with all these PM type people that used to be Scrum Masters?”
About the Author
Brian Lawrence is currently an IT Director at TriZetto Provider Solutions in St. Louis, MO, where he is responsible for several Agile and Kanban product development teams, as well as application architecture. He has been a process junky since the days of Edward Yourdan. During his career he’s taken development organizations through several methodology transformations, including Rational Unified Process, Essential Unified Process, and Agile. He loves process improvement and looking at ways of developing software better, faster, and cheaper. His current passion is looking at ways to manage within an Agile environment.
Agile Project Management That Adapts With You.
Provide your global development team a shared space that adapts to the way they work.
Related Vendor Content
Click below and check out the ScrumMaster™ tool solution.