Tampa Bay Agile Coach’s Blitz

​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.

 

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!

Sustainable Development: Meditation on an Agile Principle

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

  • Anyone who has ever worked in a non-Agile software development environment can tell at least one horror story about late-night-and-weekend death marches to get product shipped. I’ve known developers who worked eighty hour weeks—except when they took vacation. Then they only had to work about forty. (Go ahead and enjoy the theme park with your grandparents, kids! I’ll be here working in the hotel room until you get back!) I’ve worked places where I couldn’t make evening or weekend plans because schedules were so unpredictable. No wonder this principle appealed to me the first time I saw it. It means that Agile environments understand the importance of so-called “work/life balance”—vacations, weekends, and reasonable working hours.
  • On the other hand, it says “promote sustainable development,” not require it. I can see how the principle might be defenestrated if it becomes inconvenient—say near the end of a project, when there is incredible pressure to get the product shipped and revenue on the books. After all, if “Our highest priority is to satisfy the customer through the early and continuous delivery of valuable software,” it means that all other principles take a back seat to it.
  • I suppose that if sustainable development is more of an aspiration than a fact, then the process isn’t really “promoting” sustainable development, is it? Promoting sustainable development in that environment would bring another principle into play: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” figure out why things broke down. Identify a way to keep that from happening in the future.
  • What does it mean for sponsors to maintain a constant pace? In my experience, sponsors are usually the ones trying to drive a crazy pace, by refusing to compromise on either scope or target dates.
  • It’s easier to understand what it means for users to maintain a constant pace. Ever work in an environment where IT routinely dropped hotfixes without adequately testing—or warning anyone that the change was coming? I have, and it frequently resulted in increased workloads for those of us using the system. If Agile is all about delivering valuable software rapidly, it can’t mean that we deliver more problems than solutions.
  • “Indefinitely.” As long as the project lasts, right? That means making sure that the team has enough people. Not just “all the skills necessary” but “all the skills necessary even if someone comes down with the flu and can’t work for a week.”

Agile is the most humane philosophy of work I’ve ever encountered. This principle is one reason why: Agility recognizes that people have limitations, and needs beyond work. When we value “Individuals and Interactions” highly, we create safe, enjoyable working environments that allow everyone to thrive.

These are a few of my thoughts on the topic. I’d like to hear what you have to say.

TBSMG, August 2016

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!