The Agile Coaches’ Corner podcast is now available! On the first episode, host Dan Neumann and I talk about why you should focus on doing Scrum well before scaling.
Last week, I delivered the workshop, “From Blank Canvas to Product Vision,” on using Roman Pichler’s Vision Board and Product Canvas to refine an idea into a product vision and translate that vision into concrete product increments. It was very good evening, with a highly energetic and engaged crowd of over seventy people.
For feedback, I used a technique called “Four Square Feedback,” which I took from Training from the Back of the Room. Four Square Feedback presents participants with a 2×2 matrix (hence the “Four Square” moniker) that asks what they feel about what they learned, the most important concepts they learned, what they plan to do with the new information, and any final comments or suggestions.
The feedback response was excellent. I received fifty forms, with some very good constructive criticism sprinkled in among the praise and well wishes. It was exciting to see how many people planned to put the techniques I taught into use. (One person responded to “What I plan to do with what I learned” with, “DO THIS!”)
My favorite one, though, was the person who wrote that the most important concept he learned was how the Daily Scrum helps to adapt the Sprint plan. What amazed me about this response was that I didn’t mention the Daily Scrum at all that night. The participant took in what I was teaching and made a new connection without being prompted.
That’s an exciting thing for a teacher to have happen. It made me feel good about my skills as a coach, a teacher, and a speaker. And it shows that for an engaged audience, we don’t have to lead learners by the nose. To paraphrase one of the principles behind the Agile Manifesto:
Build workshops around motivated learners. Give them the environment and support they need, and trust them to make their own connections.
Photo courtesy of Christy Erbeck.
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!
I’ve added another event to my calendar. On March 22, I’ll present “From Blank Canvas to Product Vision” as the featured speaker for Tampa Bay Agile.
Join me to learn how to use canvases to identify customer needs and potential solutions, refine those ideas into a product vision, and translate that vision into concrete product increments!
I have always had an impulse to help people. As a child, I would always volunteer to help, whether it was around the house, or at school helping the teacher, or at school helping my classmates when they struggled with their studies. It didn’t even matter whether or not I liked the person who needed help.
I’d sometimes volunteer even at the expense of getting my own chores or tasks done. I remember helping a boy in my neighborhood finish up yard chores so he wouldn’t get in trouble with his father. Later, I was grounded for not mowing my own yard. Because of course he didn’t come over and help me with my chores.
I learned never to do anything for him again, but I still overextended myself time and again with others. I was the guy who would volunteer to help run your thing, get your stuff, or collaborate on your project. Often, I volunteered to do things that, on second thought, I really didn’t want to do at all. One example was my service on the board of the local chapter of the American Society for Quality.
Early in my Quality Assurance career, my boss encouraged me to get involved in a professional organization that would help my career, and I attended an ASQ meeting to check it out. During the meeting, they mentioned that they needed someone to serve as Historian for the chapter. After the meeting, I volunteered.
I was not even a member yet.
I joined the next day, and served as Historian for the chapter for about a year. After a few months, it became clear that I’d made a mistake. The organization, both local and national, was heavily geared toward quality in manufacturing. Software was an afterthought. I didn’t gain much in the way of professional development, and as a board member, I felt obligated to attend every meeting whether I wanted to or not.
Fortunately, I had the sense to decline the offer to step into the Secretary position when it became available. I resigned from the board, and stopped going to meetings that I wasn’t getting any value out of.
My impulse to help was one of the reasons I was so strongly drawn to the Scrum Master role when my company adopted Scrum. Being a “servant leader” is all about helping and empowering others.
Being a Scrum Master ultimately made me realize the folly of being too generous with my support. I recognized that the “leader” portion of servant-leader meant helping people to learn to solve their own problems.
Image by Fran Priestly.
Last night, AgileThought hosted the second Tampa Bay Agile Coach’s Blitz. At the first Coach’s Blitz, earlier this year, I was coached. This time time, I served as one of the five coaches. Each of us provided four one-on-one coaching sessions, plus a fifteen minute lightning talk.
I wasn’t worried about the lightning talk. I always go into a presentation feeling that I’m less prepared than I’d like, but I also trust my skill as a speaker and knew that I was comfortable with my topic. I was confident that my talk, “Overcoming the Five Dysfunctions of a Team,” would be received well. I enjoyed giving it and engaging with the audience for a brief Q&A session afterward.
What concerned me was whether or not I would provide individual coaching on the same level that I’d received at the first Blitz. At that time, my now-colleague Christy Erbeck worked with me to identify a plan to grow as a public speaker. That led directly to my giving a presentation at Agile 2017 this year. I got a lot of value out of it, and I wanted to do the same for people who selected me as their coach this time.
The most challenging problem was the person working in an environment where agile terminology has been mapped onto pre-agile processes and roles. Her wanted to know how she could make agile work in her workplace. That was a tough question, but we outlined some ways she could apply the agile mindset to her own work and interactions.
One person had questions about how to structure multiple teams working from a common background. We talked a little about the Nexus scaling framework, and about building her teams around features rather than components. Another was struggling with how to prove to her company’s executives that the value her agile teams have delivered was due to the transition to agile. My final session was with someone who wanted to know how to get started writing and speaking about agile.
That one was pretty easy.
The event was a big success. I enjoyed the opportunity to share with the local agile community, and helping others boosted my confidence in my own skills.
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.
Appelo, Jurgen. Managing for Happiness: Games, Tools, and Practices to Motivate Any Team. New York, NY, John Wiley & Sons, 2016.
Management, Jurgen Appelo writes, is too important to be left to managers. In Managing for Happiness, Appelo provides a dozen principles and practices that (almost) anyone can implement at work to create a happier workplace.
Some practices are harder than others for non-managers to implement. For example, the chapter, “Merit Money” discusses compensation strategies that non-executives would find nearly impossible to put into effect. Non-managerial leaders might implement delegation boards and delegation poker with some difficulty. But other most of the techniques, like value stories, culture books, feedback wraps, and personal maps, could be introduced by anyone in an organization.
Each chapter does double duty, introducing not only a practice, but the principle behind that practice. Readers will come away from the book not only knowing what they want to do, but why they want to do it. The end of each chapter provides suggested variations on each practice to spur the reader’s imagination.
The book’s form factor is its only drawback. The physical book is printed in landscape format, with each page being 9.5” wide. That makes it a little unwieldy to hold at times. Even hardcore fans of hard copy might prefer to get it in an electronic format.
Agile leaders, regardless of their job title and role, will find most of the games and tools in this book to be useful in their Agile practices. The “Moving Motivators” game, for example, will illuminate team dynamics so that the coach can better identify not only what motivates individuals, but the team itself. The “Learning Grid” is a great retrospective technique (Appelo even includes commentary from a Scrum Master to that effect). And the “Happiness Door” combines two common Agile practices to gather feedback and identify team happiness in one exercise. Managing for Happiness adds practical tools to the Agile leader’s toolkit.