Part of what makes an agile transformation difficult is the cultural change required. That’s what makes an agile transformation a journey. A client said to me, “I want the agile. The agile is good stuff: faster delivery of smaller stuff that we can get revenue for. I want it now. How fast can I get […]
I’ve been thinking more about possible measurements in an agile transformation journey. The first Possible Measurements post focuses on product throughput measurements. This post will focus on measurements you might see when the culture changes with an agile transformation. Again, do start with your why. Without knowing why you want to use agile approaches throughout the organization,
“What should I measure???” is one of the questions I see when I work with people going through an agile transformation. Too often, managers measure people as individuals. (Traditional measurements focus on resource efficiency instead of flow efficiency.) Resource efficiency measures don’t measure what the organization delivers or what prevents the organization from delivering. This
If you read my scaling agile series, you can see that becoming an agile organization requires seeing your organization as a system with a culture. You can start with teams, move to programs and the product part of the organization. If you don’t also address the cultural problems of rewards, you won’t continue with your
Agile culture is about the ability to change. (You need to know why you want to change, but once you know that, agile cultures promote change.) We (as agile teams and organizations) deliver something to get some feedback and learning. We use that feedback and learning about what we just did to challenge our assumptions
When I talk about Minimum Viable Products or Minimum Viable Experiments, people often tell me that their minimum is several weeks (or months) long. They can’t possibly release anything without doing a ton of work. I ask them questions, to see if they are talking about a Minimum Indispensable Feature Set or a Minimum Adoptable
Productive Vs. Busy I received some fascinating responses to Do You Want More Productivity? One correspondent told me that managers need to move people—especially testers—from one project where they are not busy to another project where they could help. His experience matches mine—many projects do not have enough testers. However, we do not share the
If you are organized as platform team, middleware, and front-end teams, you have a component team organization. That made sense at one point in your history. But if you are transitioning to agile or have transitioned, and if you want to use agile on a program, that might not make much sense now. If you
In a recent estimation workshop, one of the participants asked, “How do we estimate something we’ve never done before?” “Is it a feature or a project?” I asked. “A feature,” she said. “How do you do things now?” Based on her previous comments in the workshop, I suspected she was pretty good at what she
Johanna’s 2013 New Year’s Tips Every year, I provide you three New Year’s tips, to start your year off right. Here are my three tips for 2013: Tip #1: Experiment. I’ve noticed that many of my clients and colleagues are looking for “best practices.” Well, how about “pretty good” practices or “practices that might work