Roll your own Daily Scrum

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.

 

The Agilist’s Bookshelf

books-book-pages-read-literature-159866Highsmith, 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.

 

The Agilist’s Bookshelf

books-book-pages-read-literature-159866

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.

 

 

 

The Agilist’s Bookshelf

Patterson, Kerry, et al. Crucial Conversations: Tools for Talking When Stakes are High. New York, McGraw-Hill, 2012.

The authors identify “crucial conversations” as emotionally-laden, high-stakes differences of opinion. Noting that most people lack the skill to deal with such topics, the authors write, “We often back away from them because we fear we’ll make matters worse.” Avoiding these conversations can mean a strategy of silence (any kind of retreat from the conversation), or of violence (verbal attacks on the opposing party). The book contains a quiz that allows readers to identify their own “Style Under Stress,” so that they can determine the best strategy for improving their communication skills.

A flaw of many self-help books is that examples seem contrived, but each chapter of this book provides well-written scenarios that feel true-to-life. In some chapters, the authors present examples that they invite readers to think about before they continue reading, providing an element of role-play practice. A summary at the end of each chapter lists key points to remember and provides an easy way for readers to revisit the material from time to time as they work to incorporate the various techniques into their repertoire. 

Agile practitioners will find Crucial Conversations very valuable not only as a personal guide to better communication, but as a way to recognize the danger signs of broken communication on Agile teams, and mitigate against them. Agile practices require innumerable conversations around contentious topics where stakes are high. Handling these conversations safely and respectfully is key to delivering high-value solutions in happy, healthy working environments.

The Agilist’s Bookshelf

Langer, Ellen J., Mindfulness, 25th Anniversary Edition. Da Capo Press, 2014.

In the preface to the 25th anniversary edition of Mindfulness, Ellen Langer writes, “Mindlessness is pervasive. In fact I believe virtually all our problems…either directly or indirectly stem from mindlessness.” If that is true, this book offers insight into both the source of our problems and the potential to overcome them.

In Part One, Langer defines and examines “mindlessness”— a state of rigid over-reliance on outdated, incomplete, and therefore false mental models. She identifies multiple sources of mindless behavior, including erroneous beliefs in constraints, an education system that values outcome over process, and the power of context to determine our behavior and expectations. Mindlessness leads to narrow self-image, inability to adapt, and stunts our potential.

Part Two defines mindfulness as a life-affirming practice that contributes to good mental and physical health. Mindfulness means the ability to create new mental categories and adjust old categorizations, openness to new information and multiple points of view, and having a process orientation rather than a results-oriented outlook. Chapters cover mindful aging, creativity, mindfulness on the job, decreasing prejudice, and the confluence of mindfulness and physical health.

Agile Coaches may find its insights valuable to deepen their understanding of why Agile principles and practices work. Although Langer cites dozens of academic resources and studies, Mindfulness is written for the layperson. Summaries of experiments are clear and concise, and where data are inconclusive, Langer identifies the shortcomings and possible alternative interpretations. However, it is not a recipe book for mindfulness. The reader will find no instructions on how to be more mindful here; and will have to take a mindful approach to applying its lessons.

Comprehensive Documentation

“Comprehensive documentation” is possibly the most misunderstood phrase in the Agile Manifesto. People see it and they think it means that they don’t have to—or shouldn’t—write anything down. They don’t understand that the value pair statement, “working software over comprehensive documentation,” emerged from an environment in which every decision had to be made and written down in a comprehensive requirements document before we could start writing code. We would spend months creating this artifact that provided no value to the customer.

Valuing “working software over comprehensive documentation” means don’t spend a lot of time writing a specification. Focus on identifying the smallest thing you can build that the customer will find valuable. Build that in a very short amount of time and get it into the customer’s hands so they can tell you whether this is what they were looking for or not. Then repeat the process.

If you need to start a fire, don’t waste time clearcutting a forest when all you really need is kindling and a few branches.

Why Did You Choose Agile?

I once worked for a manager who summed up his attitude toward Agile by paraphrasing Tupac Shakur: “I did not choose the Scrum Life, the Scrum life chose me.” He disliked Scrum, thought Agile was silly, and resented being forced to operate under its guidance.
I did not choose the “Scrum life,” either; it was chosen for me. Like most people, the choice was made for me: my introduction to Agile came about because the company I worked for adopted Scrum. I had doubts at first. I had witnessed new management fads before. Usually, the vocabulary changed, but everything else remained the same.

This time, I saw a difference right away. When my team committed its first Sprint, no one meddled. No one changed our priorities mid-flight. And while we struggled at first to plan the right amount of work—too much the first Sprint, too little in the second—once we found our rhythm, magic happened. When we left work at the end of the day, the sun was still up. We had weekends to ourselves. Death marches ceased.

I became a believer, and when offered the chance to serve as Scrum Master, I jumped on it with both feet. My team was proud of what it produced, enjoyed creating it, and had time for full lives outside of work. This was unheard of for all of us, and the resulting happiness drove me to continue to learn and grow as an Agile leader.

Although Scrum was chosen for me, I chose Agile. I chose it because it is the happiest, most satisfying, and most humane way to work that I have ever encountered.

What about you?

Hat tip to Jessica Wolfe (Twitter: @thejessicawolfe) for posing this question at last week’s Lean Coffee for All Things Agile meetup!