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!

TBSMG, July 2016

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:

  • Share
  • Learn
  • Reassure
  • Practice
  • Network

Guild purpose - dot voting

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.

Guild vision

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!

Tampa Bay ScrumMasters Guild February 2016

At the February Tampa Bay ScrumMasters Guild, David Corbin, President and Chief Architect of Dynamic Concepts Development Corporation, presented “A Comprehensive Approach to Testing.”

David started by introducing his Axioms of Testing:

  • In a perfect world, testing is a complete waste of time—but we do not exist in a perfect world, so testing is crucial.
  • 100% testing of any non-trivial system would require an infinite amount of resources. You can’t prove a system is defect free.

These foundations served as a launching point to discuss a variety of factors that go into creating a comprehensive testing infrastructure. Topics included:

  • Forces that drive testing
  • What do we test
  • When do we test
  • Guiding principles of testing

David will present “A Comprehensive Approach to Testing” at the South Florida Code Camp on February 20th.

The next Tampa Bay ScrumMasters Guild meeting is March 2.

Tampa Bay ScrumMasters Guild January 2016

If you didn’t attend the first Tampa Bay ScrumMasters Guild meeting of 2016 last Wednesday, you missed out on several new faces, announcements about Bay Area job opportunities, and a thought-provoking presentation about “Holacracy,” by Ingrid Bredenberg. Ms. Bredenberg is an organizational development expert and a self-described Holacracy evangelist. Spirited questions and discussion punctuated the presentation, and many Guild members left eager to learn more.

Holacracy distributes authority away from a management hierarchy, across teams and roles “energized” by individuals who execute their work autonomously. Holacracy provides a clear set of rules for how teams break up their work, and defines clear expectations and responsibilities for each role. The rules apply equally to every member of the organization, and provide methods for resolving tensions about what must be done as those tensions arise.

Information about Holacracy is available at holacracy.org.

Ms. Bredenberg stated that her presentation would not make us better ScrumMasters, but I disagree. Learning about different ways of organizing and thinking about work stimulates our critical and creative thinking in ways we can use as we guide our organizations toward greater agility.

The next meeting is February 3. Mark your calendars. You won’t want to miss it!