Agile

Teaching agility online

Sam Falco

I taught an online version of my company’s “Agile Essentials” class for one of our clients. Before the COVID-19 crisis hit, I had always delivered the class as an in-person event. Social distancing and quarantine forced us to re-evaluate our delivery.

I was determined to do more than force people to sit through an all-day Zoom session in which I merely presented a slide deck. I re-evaluated the flow of the class and determined how to teach the same concepts in a different way. Instead of slides, I build a virtual whiteboard using Mural. Some of the exercises we use in the physical class couldn’t be replicated, so I invented new ones that demonstrated the same principles.

It paid off. The participants demonstrated what they learned throughout the class and provided very positive feedback throughout the course. That’s not to say there wasn’t room for improvement. They let me know some things I could do better next time. But I felt good about what I delivered and certain that they gained knowledge that they can and will use to improve their processes and practices when they return to work tomorrow.

When I teach in person, I often come away from the experience both tired and wired. I’m happy to say that today, I have the same feeling. I honestly don’t know how I’m going to get to sleep tonight.

Solvable

Sam Falco

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.

Motivated Learners

Sam Falco

Last week, I delivered the workshop, “From Blank Canvas to Product Vision,” on using Roman Pichler’s Vision Board and Product Canvas to refine an idea into a product vision and translate that vision into concrete product increments. It was very good evening, with a highly energetic and engaged crowd of over seventy people.

For feedback, I used a technique called “Four Square Feedback,” which I took from Training from the Back of the Room. Four Square Feedback presents participants with a 2×2 matrix (hence the “Four Square” moniker) that asks what they feel about what they learned, the most important concepts they learned, what they plan to do with the new information, and any final comments or suggestions.

The feedback response was excellent. I received fifty forms, with some very good constructive criticism sprinkled in among the praise and well wishes. It was exciting to see how many people planned to put the techniques I taught into use. (One person responded to “What I plan to do with what I learned” with, “DO THIS!”)

My favorite one, though, was the person who wrote that the most important concept he learned was how the Daily Scrum helps to adapt the Sprint plan. What amazed me about this response was that I didn’t mention the Daily Scrum at all that night. The participant took in what I was teaching and made a new connection without being prompted.

That’s an exciting thing for a teacher to have happen. It made me feel good about my skills as a coach, a teacher, and a speaker. And it shows that for an engaged audience, we don’t have to lead learners by the nose. To paraphrase one of the principles behind the Agile Manifesto:

Build workshops around motivated learners. Give them the environment and support they need, and trust them to make their own connections.

Photo courtesy of Christy Erbeck.

LEGO play date

Sam Falco

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!

How may I be of service?

Sam Falco2 Comments

all-the-king-s-horses-1309686-1279x769

I have always had an impulse to help people. As a child, I would always volunteer to help, whether it was around the house, or at school helping the teacher, or at school helping my classmates when they struggled with their studies. It didn’t even matter whether or not I liked the person who needed help.

I’d sometimes volunteer even at the expense of getting my own chores or tasks done. I remember helping a boy in my neighborhood finish up yard chores so he wouldn’t get in trouble with his father. Later, I was grounded for not mowing my own yard. Because of course he didn’t come over and help me with my chores.

I learned never to do anything for him again, but I still overextended myself time and again with others. I was the guy who would volunteer to help run your thing, get your stuff, or collaborate on your project. Often, I volunteered to do things that, on second thought, I really didn’t want to do at all. One example was my service on the board of the local chapter of the American Society for Quality.

Early in my Quality Assurance career, my boss encouraged me to get involved in a professional organization that would help my career, and I attended an ASQ meeting to check it out. During the meeting, they mentioned that they needed someone to serve as Historian for the chapter. After the meeting, I volunteered.

I was not even a member yet.

I joined the next day, and served as Historian for the chapter for about a year. After a few months, it became clear that I’d made a mistake. The organization, both local and national, was heavily geared toward quality in manufacturing. Software was an afterthought. I didn’t gain much in the way of professional development, and as a board member, I felt obligated to attend every meeting whether I wanted to or not.

Fortunately, I had the sense to decline the offer to step into the Secretary position when it became available. I resigned from the board, and stopped going to meetings that I wasn’t getting any value out of.

My impulse to help was one of the reasons I was so strongly drawn to the Scrum Master role when my company adopted Scrum. Being a “servant leader” is all about helping and empowering others.

Being a Scrum Master ultimately made me realize the folly of being too generous with my support. I recognized that the “leader” portion of servant-leader meant helping people to learn to solve their own problems.

 

Image by Fran Priestly.

 

Tampa Bay Agile Coach’s Blitz

Sam Falco

​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

Sam Falco

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

Sam Falco

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.