The Manager’s Role in Creating Effective Teams, Part 3 Is it a manager’s job to search through haystacks to find people who can become part of a jelled team? Not really. If you know you have an unjeller, the manager’s job is to prevent that person from being on a team you hope will jell.
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
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
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
As I’m writing the agile project management book, I’m explaining how agile creates and manages WIP (Work in Progress) Limits. Iteration-based agile manages WIP by estimating what you can do in an iteration. You might count points. Or, you use my preference, which is to count the (small) stories. If you use flow-based approaches, you use kanban.
A project manager proudly told me he was agile. “We do standups every day. We work in iterations.” I asked, “How does the product owner like what you deliver every day or so?” “Oh, we only deliver once we have a hardening sprint, after our three development sprints.” He continued to describe what they do:
Impediments will occur on any project; agile projects are no exception to risks. Agile succeeds because you are more likely to see the problem before it becomes a disaster. Two developers got the flu. Your tester has jury duty. The team can’t figure out what the design should be for a specific feature and it’s
You’re working on a project or a series of tasks for some deliverable. Do you know why? The reason behind the project explains the value of your work. You might work on something just for the fun of it. Back before I had children, I bicycled, crocheted, and needlepointed. I made time for these hobbies
Back in the ’90s, everyone was into repeatable processes for software. What that often meant was we were supposed to do all projects in exactly the same way, regardless of the type of project. We were supposed to document what we did and deliver the same documentation each project. It didn’t matter how much innovation