Workflows are a very common element of software. But they can be hard to split well when you're trying to work in small, vertical slices because the most obvious split turns out to be wrong. In this video from my 80/20 Product Backlog Refinement course, I explain why the obvious approach is wrong and what to do instead. Read More
Here's a short video I made in 2016 (hence the old Agile For All branding) about how my family uses an Agile approach for homeschool and chores: Read More
Last week, I tweeted, Working in thin vertical slices is the keystone habit for agile software development. It enables so many other good practices. — Richard Lawrence (@rslawrence) June 22, 2016 Read More
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
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