Bob Sutton (@work_matters) tweeted this the other day: Perhaps companies ought to stop using “IC” or “Individual Contributor.” It seems to absolve such employees from helping others I retweeted it and we had some back-and-forth about what to call people i organizations. Let’s eliminate these words for people who are not managers: Individual Contributor: There […]
Note to my dear readers: As I write, I realize this series is growing. Thank you for your understanding in advance. In Defining “Scaling” Agile, Part 4: Sharing Agile Outside of Product Development, I wrote about an independent workgroup with one stream of work. I used Customer Support as an example. Support has one stream:
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
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
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
Many people use an iteration approach to agile. They decide on an iteration duration, commit to work for that iteration and by definition, they are done at the end of the timebox. I like timeboxing many things. I like timeboxing work I don’t know how to start. I find short timeboxes help me focus on the