80/20 Facilitation (or, all the study on facilitation most people need)

In response to my recent post on developing your skills in 2016, several people mentioned facilitation as a skill they want to grow. As with many things, you can become good enough as a facilitator in a short time...and you can spend your life refining your skills. For most ScrumMasters, internal agile coaches, or agile leaders, I recommend two resources to grow enough facilitation skill so that facilitating’s not your constraint. Read More

Turn The Ship Around – A View Into Agile Leadership

Note: This post is adapted from some posts that I originally created on Adobe's blog while I was an employee there. I recently finished reading former U.S. Navy Submarine Commander David Marquet’s book “Turn the Ship Around". It is a powerful story of learning what leadership means and the struggles Marquet had putting it into place in his role as commander of the Los Angeles-class fast attack submarine USS Santa Fe (SSN 763). Read More

Laloux Cultural Model and Agile Adoption

Peter's Update: March 2021 The post below, as is true of all historic writing, describes my perspective at the time. That perspective has evolved quite a bit over the years as I've worked with hundreds of leaders in dozens of organizations. My current opinion, informed by teaching it and trying to apply it, is that Laloux's descriptions of Teal are probably more high Green, though the organizational case studies include a mix of Green examples and what I'd consider legitimate Teal thinking. The key move from Green to Teal is an abandonment of what people "should" value and an embracing of how each value set provides some benefits that are important for different contexts, what the original researcher behind the model Clare Graves called Life Conditions. Through that lens, Teal does not equal "no hierarchy", but includes situations where hierarchical structures match the life conditions, needs, and context of the organization. In my opinion, the organization in the book that best exemplifies this value set is FAVI, which integrates the needs and value sets of all of the  color stages from Red through Green. A person with any of these values (the need to be powerful, the need for stability, the need for achievement, and the need for loving connection) would be happy working at FAVI. With that preface, I humbly share the original below, unedited. I had invested years of my life in a ground up, large-scale agile adoption. The early years of the adoption seemed to go at breakneck speed. Teams were adopting scrum with great success. People were feeling more engaged, products were getting better, and the company was benefiting. And then it felt like we hit a wall. Despite what felt to me like a groundswell of support from teams, managers, and directors, we were struggling to make the leap to real organizational agility. Read More

Agile Homeschool Update

Last year, I wrote about how we use an agile approach for homeschool. Since then, we've refined our approach. This school year, we updated our board to reflect some of those changes. Read More

Org Structure, Software Architecture, and Cross-functional Teams

Some 46 years ago, Melvin Conway wrote, "Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure." This idea is known as “Conway’s Law,” and the converse is known as “Reverse Conway’s Law.” It’s as true today as it was a half century ago. The basic idea is this: Your organizational structure drives a particular software architecture. And your software architecture drives a particular organizational structure. People who work closely together and communicate frequently will create software that reflects this and vice versa. This dynamic leads to one of the major points of friction for established organizations trying to become agile: Read More

3 Ways to Handle End-of-the-Year Holidays on Your Agile Team

The period from mid-December to early-January can be disruptive for an agile team. You're used to working on a regular cadence, maybe in 2-week iterations. Suddenly, there's an avalanche of company holidays and vacation time that throws off your velocity and cadence. Here are 3 ways you can make the end of the year a useful and productive time rather than a few weeks of frustration and waste. Read More

Focusing on the Right Things in Your Daily Scrum

"Yesterday, I was in Sprint Planning..." I hear it once, and I'm suspicious. By the time the third team member says this, it's clear the Daily Scrum I'm observing is broken. Everyone in the room knows we did planning yesterday—we were all there. It's not valuable content to help the team plan its day. Too many Daily Scrums are a waste of time. It's not always this blatant, but if everyone knows what they're going to say in advance of the meeting and nothing changes as a result of the meeting, that team is probably missing the point. So, what is the point? Read More

Agile Homeschool

My wife and I have been homeschooling our 3 boys since our oldest, who turns 13 tomorrow, started kindergarten. From the beginning, we've tried to apply the Agile, Lean, and accelerated learning principles I use in my work. After 8 years of experimentation, we've settled on a system that works really well for our family. This post isn't about why we homeschool, what curricula we use, etc. Rather, I'd like to give a glimpse into how we apply some of the principles and practices I use and teach in my classes to a non-software context. Read More

Change Happens—So Make it Cheaper

Change on software projects is expensive; it leads to wasteful rework. Change is risk. We can deal with risk one of two ways. We can reduce the likelihood of the negative event occurring. Or we can reduce the impact of the negative event when it does occur. (Of course, the two can often be combined.) The traditional approach says, "Let's put more effort and thought in up-front and avoid that expensive change." (That is, let's prevent the negative event from occurring.) The problem, as decades of experience have shown, is we still can't seem to avoid change. Here's why: the kinds of change that plague software development can't be eliminated by thinking harder up front. Read More