Culture is a combination of three things: how people treat each other, what people can discuss, and what the organization rewards. Team 1 has a project manager who believes in collaboration. She encourages people to move work across the board, regardless of how many people it takes to finish a story. The team members joke
In our projects, we solve problems all the time. We might solve customer problems—how to make this feature work the right way. We might solve project problems—how to get to continuous integration or how to build enough and the right kind of test automation to make it easier to release. We even solve so-called people
One of my colleagues wants to standardize all his agile teams on one process. He happens to like iterations, so he wants everyone to use two-week iterations. He wants them to use Scrum rituals and ceremonies. I understand what he wants to accomplish: gaining the ability to look across the projects and see the same
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:
It seems as if everyone is talking about “scaling” agile. What they mean is a strategic collection of projects with one business deliverable: a program. We don’t have “best” practices for agile program management. However, you might find some reasonable practices help you use agile or lean even better. Think Product, Not System Sometimes, we
I like to be efficient. I like finishing my work quickly, without wasting time, money, or energy. But it’s also important to be effective—working on what matters most. One of the legacies of waterfall approaches is that too often, our focus is on efficiency and not effectiveness. Efficiency is how fast you can do something.
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
A number of my clients are attempting to use agile as they transition from a strict waterfall to a more adaptive approach to their projects. One problem the change artists have is this: The managers, product managers, and maybe even the customers want to define all the requirements up front. I have not found the
The discussion to now: Resource Efficiency vs. Flow Efficiency, Part 1: Seeing Your System Resource Efficiency vs. Flow Efficiency, Part 2: Effect on People Resource Efficiency vs. Flow Efficiency, Part 3: Managing Performance Resource Efficiency vs. Flow Efficiency, Part 4: Defining Accountability When you move from resource efficiency (experts and handoffs from expert to expert)
There’s a twitter discussion of what people “should” do in certain situations. One of the participants believes that people “should” want to learn on their own time and work more than 40 hours per week. I believe in learning. I don’t believe in expecting people to work more than 40 hours/week. My experience is that