Solvable

I have a deck of journal prompts my wife bought me. The card I drew today asked, “Think of a situation that’s currently got you stumped. How would one of your heroes resolve it?” And I thought, I’m not stumped by anything right now. It’s not that I know how to resolve every problem in my life; I don’t. But I believe that all my problems are solvable even if I can’t see the solution right now.

This outlook grows out of my career as a Scrum Master and an agile coach. The purpose of Scrum is to solve complex problems. The solution to a complex problem is unknowable in advance. You have to experiment your way to success, and success is not guaranteed, easy, or obvious. You fail a lot. You learn from the failures.

I’ve been using Scrum for my own life goals for over a year now. Every week is a Sprint, and every Sprint is an experiment. I experiment with writing techniques. I experiment with improving my health, both physical and mental. I experiment with different ways to improve my performance at work. I’ve come to believe that there are few personal problems that can’t be solved, if you refuse to stop looking for a solution.

LEGO play date

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!

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.

 

 

 

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!

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!

Tampa Bay ScrumMasters Guild March 2016

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!