One of my clients wants to use shared services “teams” as they start their agile transformation. Their developers work on a product for months and years at a time. However, the testers and UI people are part of pools of people. The organization calls these testers and UI people, “shared services.” Shared service-thinking denies the […]
Do you have any idea how long it takes you to make decisions? Or, to clear impediments? Or to report to your team or your boss about your action items? Each of those items is a deliverable. That means we might be able to measure the cycle time for each of these deliverables. Normally, we
I’ve been working with several managers at organizations large and small, who want to capitalize their software “earlier.” These managers have some strongly-held beliefs about the people: People are resources Resources can multitask on several projects at a time If “headquarters” does the difficult work, you can move the “grunt” work to lower wage areas
When I teach agile, I explain I like small and short stories. I want to see value in the product every day. Many developers can’t do that. That’s because they have interdependencies with other teams—not developers on their team, but other teams. They can’t implement in the way the picture next to this shows: small,
“George is on his offshoring rampage again,” Cindy said as she slumped down in Ted’s visitor chair. Ted saved his document and turned around. “Oh? Want to tell me about it?” “I need more testers for the feature teams we’re starting, right? I told him. I showed him the project portfolio and the projects we
Shane and the participants and I had a great time at the Geographically Distributed Agile Teams workshop last week. We ran a couple of simulations, and here are some of the emails the teams had: Do you have something for us to test yet? We have completed the card Hi again. I didn’t hear back