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.
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 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!
This year, according to popular imagination, has been a particularly bad one. Zika. Celebrity deaths. Brexit. ISIL. And, of course, the horror that was the U.S. Presidential election. An annus horribilis, to be sure. And yet, it is a mistake to view the year solely through that lens.
Dwelling solely on these negative events leads to tunnel vision, so that we don’t see what is good in the world and in our lives. For me, it was a very good year:
- I completed the first draft of Target Striker faster and with higher quality than any novel I’ve written previously.
- I got to travel, making trips to San Diego, Santa Clara, Atlanta, New Jersey, New York, Puerto Rico, and Estonia.
- In Puerto Rico, I fulfilled a long-time dream of visiting the Arecibo Observatory.
- I experienced professional successes, including teaching well-received workshops on Scrum, attending the Agile Alliance 2016 conference, facilitating meetings of the Tampa Bay Scrum Masters Guild, and finding a new job.
- I got to attend four Copa America Centenario games, including the final match.
In addition to the major items, the year was filled with smaller joys: good books, evenings spent with Carolyn, and board games with friends, to name only a few.
Was everything in 2016 good? Of course not. But it is too easy to dwell on the negatives, and give in to despair.
2017 promises to be a year full of challenges. Among other things, the United States will install an authoritarian, white-nationalist government against the will of the majority, and good people will have to find the strength to resist it. It’s important not to lose sight of all that is good in our lives, so that we can draw strength from those experiences and memories.
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!
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!
Here’s a little something I put together for an Agile education initiative. Click to embiggen.
The Scrum Field Guide, Mitch Lacey.
Although it’s subtitled “Practical Advice for Your First Year,” Mitch Lacey has loaded his book with so much good advice that even veteran Scrum Masters will find themselves reaching for it from time to time, especially when creating new teams or joining a new organization.
Succeeding with Agile, Mike Cohn.
Another excellent resource for Scrum Masters introducing Scrum to a new organization, including lots of advice on how to start from scratch in companies that have never been Agile.
Scrum: The Art of Doing Twice the Work in Half the Time, Jeff Sutherland
Jeff Sutherland helped create Scrum, and his recent book explains not just what Scrum is and how it works, but how and why it was designed the way it was. Any Scrum Master who has been stumped by questions about why a Scrum ceremony or artifact is important will find the answer here.
As a Scrum Master at my last job, I often interviewed developer candidates to judge their experience with and appreciation for Scrum. Almost all had some experience with it, and opinions were mixed. Many were non-committal. Others rhapsodized about it. And one told me she hated Scrum, because “It’s a waste of time.”
Of all the complaints I’d heard about Scrum, this was a first. Scrum a waste of time? I asked her to elaborate.
“You have a two week Sprint, and deliver the code, and then you wait around doing nothing for two weeks while QA tests it and tells you whether it was accepted or not.”
I assured her that what she described was not good Scrum practice. The Scrum Guide states that, “A new Sprint starts immediately after the conclusion of the previous Sprint.” She didn’t see how that was possible. How, she wanted to know, could code be considered complete before QA had blessed it? How does Quality Assurance fit into the Scrum development cycle?
“Scrum recognizes no titles for Development Team members other than Developer,” states the Scrum Guide, and Scrum also does not recognize sub-teams. The team should be cross-functional, and can accomplish its work without relying on people who aren’t part of the team. Does that mean that a Scrum can’t have testers? Of course not. Scrum recognizes that “Individual Development team members may have specialized skills and areas of focus,” including testing. It just means that testers have to be fully part of the development team, and code should be tested throughout the development process, not at the end of a project. What this woman had endured wasn’t Scrum—it was miniature Waterfall with a two week development phase. No wonder she was turned off by it.