Stuff Bad Scrum Masters Say
If you ever hear your Scrum Master saying anything like the stuff found in this video…you may have a bad Scrum Master.
Hilarious, and totally worth a watch.
How to Introduce Scrum Into a Waterfall Culture
What does one do if they find themselves in a Waterfall-based culture that’s failing? Introduce Scrum, right? Well, yes…but sometimes it’s not that easy if upper management isn’t on board with the solution. How could we gradually introduce Scrum bit by bit, in a way that management won’t be upset by, and that will bring about effective change? The article here provides some good tips on ninja-implementing Scrum into a company’s process.
Scrum From Hell
One of the best things we can do as Scrum Masters is help the team discover what the various roles are about. When everyone has a well-rounded idea of what’s what, it will only help everything go smoother. Here’s a game called “Scrum From Hell”, which is a great team-building exercise that’s sure to increase efficiency in the daily standup.
Assumptions, Scrum Mastery, and You
We’ve all been there: Someone says something one way, you hear it a different way than it was meant, and something unintended happens. In software development, if something can be misunderstood, it likely will be. What can we do as Scrum Masters to help prevent miscommunication on our teams?
1) Be clear. Write it down.
Whether you write it on a notecard and post it to the cork board, or type it into Jira/Greenhopper (or OnTime, or VersionOne, or Agilifant, or Excel, or whatever), you’ve got to make sure the objectives are documented. If you write out a story along with its component tasks, and John says he’s going to work on it, make sure John initials that it’s his story. Implicit verbal contracts usually work, but “usually” isn’t good enough when you’re on a tight two-week sprint. You need to KNOW that the team understands their individual roles within that sprint, and that they’ve taken responsibility for those roles by signing off on them.
2) Be precise in what you say, especially with stakeholders.
When stakeholders ask you for a progress report (assuming the Product Owner isn’t around), they tend to interpret anything you say with an amplified reality distortion field around it. “We’ve had a couple of impediments crop up, but it’s coming along nicely”, will usually be heard as, “We’ve slipped, and now everything’s behind.” In brief summary form, quickly explain what the impediments are, how you’ve dealt with them, and tell them the exact effect it had on the overall sprint (or release, if applicable.)
3) Actively listen to your team, and don’t make assumptions about what they say.
If John tells you a detail, be careful not to assume he meant anything beyond what he actually said. For instance, you’ve got a 10 point story with eight tasks attached to it. John tells you he’s going to work on the first four, then signs off on them. Typically, the implication here is that when those are completed, John is going to work on the next four. That’s a normal logical assumption. This is where specificity is important, and we need to make sure John is going to work on those next four tasks. Luckily it’s easy to ensure this via a quick question to John, and some quick initials on his part. If that short five second conversation doesn’t take place, and John has no intention to do those next four tasks, it can lead to problems later when something falls behind and that 10 point story isn’t done on time.
Assumptions happen. It’s a part of life. Taking a quick moment to clear up tiny working points can go a long way toward preventing headaches down the road, and get you on the right track to continuous delivery.
Scrum Trends
Scrum, and Agile as a whole, is continuously evolving, iterating, and what was best practice last month may not be in vogue next month. Here’s an article listing some current trends. Not all of these trends will apply to every Agile/Scrum-based organization, but it’s worth a glance to see where the industry is headed.
The Agile Manifesto
The guiding principles of Scrum/Agile. As a Scrum Master, focusing on these principles is a meaningful part of your day-to-day work, and will bear good things for you and your team:
The Agile Manifesto
The Agile Manifesto, with its Twelve Principles of Agile Software, is the underpinning of agile product development. We agree to support the Agile Manifesto in its entirety:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
We follow these principles:
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity – the art of maximizing the amount of work not done – is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
What Makes for Good User Stories?
What makes for good user stories? How do we get our teams to write good user stories? In this article, the author suggests that stories answer a simple set of questions: Who? Why? What? If the story is too complicated (or too vague) to answer those questions, it probably still needs more design from the Product Owner/team. Somewhere between being too large to manage (i.e. needing epic decomposition), and being too vague for the developer to actively design/code the story, lies the simple truth of these easy questions. What works for some, may not work for others.
The Scrum Guide 2020 Update
What is the Scrum Guide? It’s a document put together by the creators of Scrum (Jeff Sutherland and Ken Schwaber) that explains in moderate detail exactly what Scrum is. The roles of a Scrum team, the actions that take place during the various phases of a sprint, and how to evaluate the team’s effectiveness, are all covered. It’s recommended reading for new and experienced Scrummers alike. The latest version (as of this post) is from 2020. Click the image above for a link.
Scrum Definitions/Interview Questions
A handy list of updated scrum-based interview questions, current and relevant for 2022. Some great info to be found here if you want to learn something new, or just review the basics.
Is this thing on…?
Welcome to Getni. A personal blog for Scrum/Agile-related info, trends, and practices. There are a lot of sites out there with a lot of Scrum info, so thanks for dropping by my small piece of the Agile world. I hope you find something valuable.