This week, I filled in as host of the Agile Coaches’ Corner podcast. My guest, Adam Ulery, talked about tips for new Scrum Masters. Check it out!
At last night’s Tampa Bay Scrum Master’s Guild, we did a simulation of a scaled Scrum project. We used LEGO bricks to build the components of a zombie defense system. It was fun, of course. How can LEGOS be anything but fun?
At one point, when several members of my team were off coordinating with other teams, my friend Jessica and I remained at our table. As we caught each other up on what we’ve been doing since we last saw each other, we idly assembled pieces of our teams design. It was very relaxing to be engaged in what amounts to children’s play while we talked of the challenges of adult life. Maybe, the next time we arrange to get together for coffee, we should bring a bucket of LEGO bricks to play with, too!
Yesterday, Scrum.org released an update to the Scrum Guide, with mostly minor changes to Scrum practice. The new guide clarifies that Scrum is for delivering complex products (rather than being limited to software), refines the Scrum Master role, and clarifies that Scrum events time boxes are maximum lengths. It also states that each Sprint Backlog “includes at least one high priority process improvement identified in the previous Retrospective meeting” in order to foster continuous improvement. That has been a common practice for many Scrum teams, and it’s a welcome addition to the guidance.
To me, the most significant change was to the description of the Daily Scrum. Previously, the Guide mandated that participants answered three questions to examine the team’s progress toward the Sprint Goal:
- What did I do yesterday that helped the Development Team meet the Sprint Goal?
- What will I do today to help the Development Team meet the Sprint Goal?
- Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?
Those questions are still provided, but instead of prescribing them as the specific, required practice of Scrum, they are only an example of how a team might inspect and adapt its plan to complete the sprint goal.
This is a big deal. The Guide states that “Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum.” Prior to this update, if you were doing something different in the Daily Scrum, technically, you weren’t practicing Scrum. In some case, it led to rigid, stale Daily Scrums that were more like a classic status report.
Now teams may be more likely to experiment and find the practice that is most useful to them. Early in my Scrum Master career, I had a team that twice modified the Daily Scrum to suit its needs quite dramatically. The first time, they did away with the “What did I do yesterday” question. No one found that valuable. The Scrum Board showed that quite clearly, and they wanted to spend more time talking about what they would do that day, and what impediments were likely to get in the way.
Later, they realized that answering the questions in turn led to confusion, because it presented the progress of backlog items in an out-of-sequence manner that made it difficult for them (and for the Product Owner) to understand. Instead, they switched to a “walk the board” process. They would look at the highest priority item on the list, and talk about what was necessary to complete it. What was the next task to do? Who would do it? Did anyone need any help? And then we went to the next one on the list, and so no, until they’d accounted for each backlog item in progress.
Neither of these practices were technically Scrum, because the guide prescribed a different practice. But both changes made the team more productive, and helped them achieve sprint goals with greater ease and speed. I’m glad to see that the Guide now welcomes this kind of innovation.
Highsmith, James A. Agile Software Development Ecosystems. Addison-Wesley, 2006.
Agile Software Development Ecosystems is divided into four sections: “Problems and Solutions,” “Principles and People,” “Agile Software Development Ecosystems,” and “Developing an ASDE.” Sections I and II discuss the problems facing the software development world, and delve into how the basic principles of Agile can solve them. Case studies illustrate the concepts, and Section II also presents interviews with the creators of each of the six Agile systems described elsewhere in the book. These interviews shed light on why and how each system was developed.
Section III presents thorough descriptions of the major systems at the time the book was written: Scrum, Dynamic Systems Development Method, Crystal Methods, Feature-Driven Development, Lean Development, Extreme Programming, and Adaptive Software Development. Though Scrum (leavened by XP) has come to dominate the Agile landscape in the intervening decade, it’s important to remember that there are other options and what environments they serve best. Plus, it is interesting to know the history of ASDE development.
Section IV covers “Developing an ASDE.” These chapters are aimed more at enterprise organizations for which scaling issues complicate the adoption of team-level Agile systems. In “Articulating Your Ecosystem,” Highsmith discusses how to determine the key elements of an organization’s culture, and match that culture to the right Agile system. The final chapter, “Designing Your Agile Methodology,” provides in-depth guidance for adapting an existing methodology, or designing one from the ground up.
Every Agile practitioner should read Agile Software Development Ecosystems, from team-level coaches and developers, to managers and executives in organizations trying to adopt—and adapt—Agile.
This month at the Tampa Bay Scrum Masters Guild, we followed up on the vision for the Guild that we decided on at last month’s meeting:
To take an active role in building up Tampa Bay as a major technology hub.
That’s a pretty tall order! Before we can decide how to make it a reality, we needed to decide how to recognize when we achieve it. We used a variation of brain storming called “Brain Writing” to generate a list of ideas, then used dot voting to select the five best indicators of success:
- Increase in startup funding for tech companies/actual tech startups on par with major cities like San Francisco or NYC
- Major technology conferences are hosted in Tampa
- National media start to report on “Tampa Tech”
- Increase in tech-related degrees awarded at area colleges/universities
- IT salaries increase to be competitive with existing tech hubs, i.e., the Research Triangle or Austin
The next step will be to decide what steps to take to make those indicators happen. It’s a topic on the Trello board; vote for it if you want to see more progress on turning vision into reality.
We closed the meeting with a report on the Agile Alliance conference in Atlanta. Sam Falco (that’s me!) talked about two themes that cropped up in several Agile 2016 sessions: making work a safe space for experimentation and innovation, and the future of Agile. Both topics fed into a group discussion of “Modern Agile” and how its four principles map to the values in the Manifesto.
Next month’s guild meeting will be held at Grow Financial on September 7. Don’t miss it!
I missed the last few Tampa Bay Scrum Masters Guild meetings, but I was on hand for the July meeting at the offices of Mad Mobile last week. I’m glad I attended, and not just because of the food supplied by Clearly Agile. At this meeting, Adam led us in exercises to refine and clarify the Guild’s purpose, vision, and values.
Why do we meet? What is the purpose of having the Guild? We split into four groups to brainstorm the Guild’s purpose. Each group presented its list. Dot-voting selected a list that forms the peculiar acronym, SLRPN:
The third exercise re-visited the Guild’s list of values, created in one of its first meetings. We kept some of the original values, and added more. Look for Adam to post the new list on the Guild’s Trello board soon.
In between those exercises, we generated a vision for the Guild. This exercise aimed to give us a wider goal than the Guild’s purpose: not just “why do we come here,” but “what do we want to be known for.” Once again, each group brainstormed and then put its best vision forward for a vote. The clear favorite was:
To take an active role in building up Tampa Bay as a major technology hub.
To close the meeting, Adam asked for suggestions for topics for future meetings; one of the suggestions was to start figuring out how to turn our new vision into reality. That topic, and a few others are on the Trello board. If you have other suggestions, please add them!
The next Guild meeting will be August 3. Don’t miss it!
With our captain, Adam Ulery, out sick, Julee Belomo and Christy Erbeck took the wheel and kept us on course for this month’s meeting topic: Fostering Strong Teams. We also had delicious food and dessert courtesy of Clearly Agile.
Helping teams learn to work together can be the most challenging part of a ScrumMaster’s job. In this month’s exercise, we gathered in groups of four or five and considered how to help the team in one of three scenarios.
- A “cowboy” developer who does what he thinks is best, without consulting the team.
- A team that limps along, mediocre but unwilling to use retrospectives for continuous improvement.
- A development team member who, after being promoted to manager, remains part of the team but runs roughshod over them.
All three scenarios reflected real world problems that many ScrumMaster grapple with, and each group generated a lot of food for thought as to how to handle them, and situations like them.
Each scenario also each hinted at something awry at the core of the organization’s Agile practices–it might be worth revisiting them to go beyond, “How do we help the team,” to, “How do we guide the organization to improve its agility?”
We closed out the meeting by soliciting suggestions for the May meeting topic and asking everyone to vote.
At next month’s meeting, on April 6, we will celebrate the Guild’s one year anniversary. Don’t miss it!