Here’s where we are so far in this discussion of what it might mean to “scale” agile approaches: Part 1: Creating Cross-Functional Feature Teams (Teams that can produce features on a regular basis) Part 2: Programs of Cross-Functional Feature Teams (Programs (multiple teams working together) that deliver features on a regular basis) Part 3: Agile Product […]
As I finish the agile project management book (Create Your Successful Agile Project), I am working on what stays in this book and what I use in the agile management book (next up after the PO book). That leads me to this question: What do you call a transition to agile approaches? Is there a
I spoke with a potential client the other day. He said, “I want all the teams to use Scrum, and I want it yesterday!” Okay. I asked him, “Are the teams all collocated and cross-functional, with all the capabilities and roles they need to finish work?” “Almost all of them.” I asked, “Do the teams
In the “Scaling” Agile: Part 1, I wrote about cross-functional collaborative teams. The cross-functional collaborative feature team is the basis for “scaling” agile. In “Scaling” Agile, Part 2, I wrote about programs. I realized I need another part before my original part 3 :-). This new part 3 is about creating agile product development capabilities.
The first post was about scaling functions to working as collaborative agile teams. See Defining “Scaling” Agile, Part 1: Creating Cross-Functional Teams. Now, let’s talk about moving to multiple teams working together, a program. The good news is that you have a few cross-functional teams. They’ve been delivering as project teams. And, now you have a
I keep encountering confusion about what scaling agile is. I’m writing what I think is a 4-part series to define it so we all talk about the same thing. When I ask people to define what they mean by scaling agile, they talk about these possibilities: They have agile developers. They want agile testers. This is
Have you ever worked on a project where the management and/or sponsors felt it necessary to provide you warnings: “This release better do this or have that. Otherwise, you’re toast.” I have, once. That’s when I started to use release criteria and check with the sponsors/management to make sure they agreed. I happen to like
I know of a geographically dispersed team across three continents and many time zones collaborating on a product. They work in one-week iterations and have weekly virtual meetings to collaborate in real time. They never have standups because the logistics are impossible. They have handoffs instead. They retrospect at a month-long cadence. (I might like
Own Your Leadership, Part 3 I started this story back in Own Your Leadership, Part 1: Dave and Sherry collaborated to facilitate their team’s ability to deliver one completed feature at a time, to improve the team’s throughput and quality. In Own Your Leadership, Part 2, Sherry realized the team doesn’t have a real PO,
Several years ago, I wrote a post for a different blog called “Why Team Size Matters.” That post is long gone. I explained that the number of communication paths in the team does not increase linearly as the team size increases; team communication paths square when the team increases linearly. Here is the calculation where N is