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 it?”
This manager is not stupid. He’s using terms that might sound funny to some of us, “the agile,” but he’s got the right idea. And, if he was just talking about a project framework, maybe he could get it fast.
I wrote a scaling series of posts last year to show how your journey might proceed. I don’t know of a journey that does not start with teams. However, depending on your questions from your why, you might proceed in a “non-linear” fashion. As with all agile cultural change, your journey is your own, too.
As things change in the organization, people will experiment with different changes. The measures you need will change. As the culture changes, the measures to reinforce the culture you want will change. The journey continues.
If your organization’s agile journey seems to be stuck, please join Gil Broza and me at the Influential Agile Leader workshop in Boston, June 7-8, 2018. The early bird registration ends May 1, 2018.
You’ll have a chance to assess your progress, your system, and culture. Once you do that, you’ll be able to create action plans that will unstick your agile transformation. Do join us.
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, you can’t generate reasonable measurements.
In this post, I’ll address the collaboration measures you might want to consider. (I often use the idea of two coffee cups to prompt my ideas about collaboration.)
Again, what do we want more of and less of? Here are answers many of my clients have suggested:
More collaboration within teams
More collaboration between teams (the left hand and right hand problem I referred to in the why post)
Less work in progress (WIP) due to waiting for other people
I’m going to suggest one more thing: fewer not-so-useful meetings.
Meetings are the bane of everyone’s existence. Too many of us are not in charge of our calendars. We run from meeting to meeting with barely a bio break. We waste time and no one in the organization has any idea how much time. (I’ve been estimating Cost of Delay for some decisions in my clients’ meetings, and it’s quite depressing. The CoD waiting for decisions outweighs the supposed lateness of the features.)
I like collaboration in the form of people working together to solve problems. I prefer to call these meetings “workshops,” as in:
We are workshopping (refining, planning) requirements for the team
We are workshopping what we learned over the past day, week or two weeks (retrospective)
We are workshopping the product roadmap, the project portfolio, etc.
Each of these meetings/workshops has a possible agenda, which we can send out in advance and requires the necessary people to succeed.
Number of meetings that revisited the same decision. (I see this in the project portfolio a lot. The Director-team or the PMO make decisions and the senior managers remake the decisions. The result is whiplash for the teams.)
Number of wait-for-decisions at a meeting. This could mean the wrong people are in the meeting, or that they don’t have the authority/autonomy to make this decision.
Number of meetings planned and actual where we plan to learn and we do learn. This might be Community of Practice meetings, staff meetings where the staff has a backlog of learning, or other learning opportunities, such as book discussion groups.
Yes, these look like quantitative measures but are really qualitative measures. They “measure” the culture. Here are the problems I’m trying to visualize:
We need to make the most of our collaboration time. If we can’t decide or have the right people in the meeting, let’s address that problem first.
Waiting for decisions is a form of inventory, WIP. I want to see that.
If we are not learning as a community at all levels, we are not mastering our jobs. We might learn about technology (languages, architecture, testing), interpersonal skills, product ideas, and about strategy or customer needs.
Remember, workshopping produces product-based artifacts. Other meetings might produce decisions.
If your agile transformation is stuck, consider rethinking your measurements. Consider the data people need as individuals and as (management) teams working across the organization.
That’s one of the reasons Gil Broza and I are offering the Influential Agile Leader workshop in Boston, June 7-8, 2018. The early bird registration ends May 1, 2018. You might look at your system and current culture and decide to create other measurements to see what you can change. Do join us.
“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 measurement question can be the prompt that changes your culture and your system. It might help people realize there are reasons for change and help them create small, safe-to-fail experiments. I like to see the questions reflect the why for your organization’s agile transformation.
First, consider asking yourself these questions:
What do we want more of? (I often discover the answers are about throughput and collaboration.)
What do we want less of? (These questions often lead me to think about defects and delays.)
That might lead us to consider these possible measures:
How often do we deliver something our customers need? (Lead time trends)
Can we deliver what we want when we want? (A simplistic qualitative measure of organizational agility)
Do we have work as inventory, stuck somewhere? (Where are our bottlenecks?)
Do we incur costs because we don’t release that inventory of work? (Cost of Delay)
Do we know our flow, our value stream, and where we add value and where we wait? (More about wait states and adding value)
Do our employees (all of them) like working here? (This is a partial measure of engagement. I find it telling when the senior managers like working here and the individual contributors don’t. One reason might be because they are “individual” contributors.)
Do our employees believe in our mission? (Have we defined why we exist? Nobody exists to make money. Making money is a side effect of the mission. An important side effect, but a side effect.)
How well does what we deliver reflect our mission? (Are we delivering improvements on a regular basis? Trying to keep up? Falling behind?)
I’ll stop there. Notice that there is no mention of velocity or burnups or any of that nonsense. While project teams might use velocity and local burnups, and projects might report on feature charts and product backlog burnups, those measures are not sufficiently strategic. (See Velocity is Not Acceleration for the discussion and examples of feature chart and product backlog burnup charts. Also, see Create Your Successful Agile Project to differentiate between measures teams need and project-reporting measurements.)
Notice that all of the measures, qualitative or quantitative is a trend over time.
One manager started with just two measures: lead time for projects and if people felt they had finished valuable work that day. The teams could report on their lead time. And, every team had a flip chart paper with a supply of yellow and red stickies next to this flip chart.
Each person on the team assessed the value of their work done that day. The yellow stickies were a qualitative assessment. The higher the yellow sticky, the more valuable people felt their work was. The lower the red sticky, the lower the value the work.
Some teams discovered their assessment of value was about their ability to deploy. Other teams decided value was more about collaboration in the team. Yet other teams decided it was about what the end customer could do with the released stories.
Each team could decide what value meant to them.
Team1 used their graphs and lead time as part of the data for their retrospectives. They (slowly!) moved their deployment time from two weeks to one week to three days to one day. They released something valuable to customers every single day.
Team2 learned to deploy once a week, which appears to be sufficient for them now.
Team3 was a little suspicious of Team1’s and Team2’s success. Team3’s lead time was quite long and they decided to focus on just lead time for one month (two iterations). Because their PO felt compelled to change the iteration contents inside the iteration, the team had an urgent column on their board. They also measured the number of items that flowed through the urgent column and the number of items they’d planned for.
Team3 discovered that their lead time for the Urgent work was between 3-6 days. They also discovered that their planned work lead time was about the same, 3-5 days. The difference was the quantity: they often had five items in the Urgent column and four items in their planned Ready column. They had a ton of WIP (Work in Progress). They switched to a kanban board, using what had been iteration boundaries as a planning and retrospective cadence. Team3 discovered they needed more data to understand their work.
After a month, they decided to track their daily perceived value, too. They start mostly with red stickies below the neutral line and progressed to more yellow stickies above the line.
For all three teams, as the lead times decreased, the perceived value increased.
That’s when the managers asked the teams to help them decide what to change next. The teams decided to change their measurements to take a closer look at their value streams and Cost of Delay. The teams asked the managers to look at their decision-making processes. Why did the PO feel such pressure to change what the teams had planned?
The managers measured the lead time from when they put a possible project on their board to when they gave that project to a team. That delay was longer than any of the projects (manager decision lead time was often 18 months, and the projects were anywhere from 6-9 months). The managers needed the teams to be able to deliver more often and the managers needed to manage the project portfolio better.
That prompted a discussion of how the managers influenced the product roadmaps and the project portfolio. It turns out that the managers were measured and incented by resource efficiency, not flow efficiency. They had to change their reward and bonus system in order to bring sanity back to the roadmaps and the project portfolio.
Your organization may decide to measure other data. However, it’s worth thinking about what to measure so you can create small, safe-to-fail experiments for your measurements.
If your agile transformation is stuck, consider rethinking your measurements. Teams still need team-based data. And, teams need to report project data. Managers might need data about their work because their decisions create and refine the culture (agile or not). When you think about an agile culture, teams and managers often need different data.
That’s one of the reasons Gil Broza and I are offering the Influential Agile Leader workshop in Boston, June 7-8, 2018. The early bird registration ends May 1, 2018. You might look at your system and current culture and decide to create other measurements to see what you can change. Do join us.
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 transformation.
You know why you want the organization to use agile approaches. You’re practicing change. How can you see your system and your culture?
See Your Organization as a System
When I talk about seeing your organization as a system, I mean how the parts work together and reinforce each other.
When managers don’t make the (quite difficult) project portfolio decisions and ask people to multitask, they create a system that:
Causes and reinforces a lot of organizational WIP (Work in Progress)
All of these problems make managing the project portfolio even more difficult.
The system of work is one where people feel as if they are on a hamster wheel, running around and around.
It’s no one person’s fault. It’s the system.
Edgar Schein defines culture as how people treat each other, what people can discuss, and how the organization rewards people.
If you have a system anything like the above, the managers often feel as if they must reward the heroes, not collaboration. That action reinforces solo work as experts, more resource efficiency, not flow efficiency or collaboration.
The system creates the culture and the culture reinforces the system. You might not have these particular problems. You might have others.
Saying “reward flow efficiency” or “ask people to collaborate” might help small pieces of the system and the culture. However, they are not enough. That’s why Practicing Change and Knowing Why are a part of an agile transformation.
If you and your organization struggle with this part of your transformation, please join us at the Influential Agile Leader, Boston, June 7-8, 2018. Once you see both your system and culture, you can start with small, safe-to-fail experiments to create allies and transform your organization.
The super-early bird registration ends Mar 1, 2018. We can help you see your system of work and your culture. We’ll help you build allies across the organization and see your options for change. Do join us at the Influential Agile Leader.
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 and experiment with our next (small) batch of work. That’s the essence of double-loop learning. (Teams deliver features, Support delivers fixes/workarounds, and managers deliver decisions.)
Many organizations—and people—are not too facile with change. Some organizations have multi-year plans, rely on predictions without feedback for project planning, and leave people in the same positions for years and years.
You may have heard of companies that didn’t realize they needed to change their product lines over time. (Xerox might be one of them.) You might work for one of these companies and they want to use an agile approach.
These organizations have the same products for years and years. They can’t seem to create new products. And, they don’t retire old products.
It doesn’t matter if these organizations have research groups, or something called “advanced products” if the organization can’t deliver something new. All too often, these organizations have the same products, the same people in the same positions making the same decisions, year after year.
No wonder their agile transformation gets stuck. The organizational culture works against organizational change.
One way to use agile approaches is to practice small changes. You might even start with yourself.
When I work with managers on their agile transformations, I ask them what they can personally change to get some feedback and rethink that process or product. I sometimes use the word experiment, but not always.
One manager said he could change how he drove his route to work. A week later, on our coaching call, he had not managed to change his drive yet.
He had reasons, some of which were:
He liked to check his voicemail on the way into work and if he changed his drive, he would have to pay attention to his drive and not the voicemail.
He had already discovered (eight years ago!) the fastest drive. He didn’t want to take more time.
He forgot. He worked more by checklists/remote control/not really thinking in the morning. He had trouble thinking.
I asked if he wanted some coaching or did he want to consider something else to change. He laughed a bit and said, no he’d take the coaching. He realized he was going to learn something from this.
I’ll spare you the actual coaching conversation. He decided to try these things, which we did not call experiments, but were:
Research three alternative routes, write down his expected trip duration and the actual trip duration. He would try these routes on his workout days (Mon, Wed, Fri).
Because Tuesday and Thursday were his non-workout days, he felt as if he had more time then. To prepare for Tuesday morning, he left this sticky on his steering wheel on Monday evening: “Try a different route. Turn right out of the driveway instead of left.” His sticky for Wednesday evening was a little trickier: “Instead of taking the country route A, take country route B.” He was supposed to write down his expected duration and actual durations for the Tuesday and Thursday drives.
Wear sneakers to drive instead of his normal dress shoes every day. I wasn’t sure if he could do this, but he decided this was an alternative he could live with.
He discovered some fascinating results:
Every single drive beat his “regular” drive time by at least two minutes. He hadn’t noticed that the construction and changed roads had increased his drive times by 10-15 minutes over the previous 8 years. When he researched and tried different alternatives, he discovered he was not faster.
He couldn’t leave the house in sneakers. Just could not. He wore his dress shoes.
Here’s the problem. If we want an agile culture of collaboration and experimentation, we have to learn to embrace change, to use experiments and create new possibilities.
This manager’s experiment with drive times—not products, not how he made decisions at work, just driving—helped him see he had many more alternatives than he’d originally thought. He learned the value of experiments and collecting data. He learned about challenging his assumptions.
Teams practice change when they finish one item and move to the next item on the backlog. Managers can practice change in many other ways, almost always with experiments.
When you use experiments, especially small, safe-to-fail experiments, you can practice change and become good at it. Each experiment minimizes your risk.
You can help your agile transformation in the same way. If your agile transformation is stuck, or you are in the messy middle, please check out the Influential Agile Leader workshop in Boston, June 7-8, 2018. The super-early bird ends Mar 1, 2018. We can help you articulate your why and what that means for your transformation. Do join us.
I’ve seen several agile transformation challenges. Since I want to address those challenges, this is a series of posts about agile transformation. The problems I’m planning to address are:
Understanding why agile, why now
Change and why we might not be so facile with change and how that challenges a transformation
How to see your agile transformation as a system and culture problem.
Selecting a handful of possible measurements you might select, to reinforce behaviors you want to see.
Recognize a cultural transformation is a journey
I reserve the right to add to this list as I write. I’m not smart enough to write it all in advance. Although I prefer to think I am agile enough that I can take feedback as I write.
Let’s start with why we want to work in a new way.
Why Do We Want to Transform into an Agile Organization?
I wrote a Pragmatic Manager called Define Your Agile Success. If you define the business reasons for using agile approaches (and I have yet to see an organization utilize just one agile approach), you can decide on an agile transformation roadmap and learn to create your agile culture.
Note that the teams might have different reasons than the managers might have for using agile approaches.
Here are some terrific business reasons I’ve seen:
Our lead time, the time we put a project on a team’s todo list to the time they complete it, is too long. There are systemic reasons for this, and agile approaches will help expose those reasons.
We want to have more collaboration across functions and teams because our products’ quality suffers. We know our right hands and left hands don’t know what each other is doing.
We need to deliver more often to our customers. We used to be able to deliver one major release and maybe a couple of minor releases a year, and that timing is no longer sufficient. (The idea of hot fixes is in here, too. I’ve seen too many organizations deliver hot fixes that need to be fixed and fixed and fixed… all because they can’t deliver a real release every month or so.)
We need to change what we thought we needed to do much more often. We used to be able to create a five-year plan and revise that plan once a year. No longer! Now we need to change our big plans every year and rethink that planning every couple of months. We might need to change our mix of products and services even more often.
We want to create a culture of change, where we challenge assumptions and change our products and how we think. We want this culture of change because our customers have it!
You might have another reason.
There are many micromanagement reasons to think you can use agile approaches and it’s too depressing for me to list them. I’m going to assume your agile transformation has a great business reason.
That said, you might be one of those people whose agile transformation doesn’t have an explicit reason. That might be one of the reasons your transformation is stuck.
I hope you decide to check out the Influential Agile Leader workshop in Boston, June 7-8, 2018. The super-early bird ends Mar 1, 2018. We can help you articulate your why and what that means for your transformation. Do join us.
I was on vacation last week, thinking about value. Depending on my role, I might think of value as:
Delivery of a feature or story, assuming it’s the right level of quality and when I want it.
Information about the story. This might include information from the team about what they think about this story, especially in context of the entire feature set.
Information about how story might change what the team thinks we should do next, or other roadmap information.
Notice that only the very first way to think about value is about the delivery of this feature. The other two ideas are about information for the product owner and possibly the product manager.
When product owners have feature-itis and treat teams like feature factories, they miss all the juicy information the team might have about this feature and what it means for the feature set and the roadmap.
One PO had what he thought was a high value-low cost story. The story created an easier way to import new data. The customers would be independent of their IT group if this import worked. The team finished the story, demonstrated it and asked if they could watch the PO demo the story to just one of their customers. The team specifically asked to watch this customer.
The PO didn’t quite understand, but he decided the team had good ideas so he did. He demoed the feature to this specific customer. The customer was thrilled and asked many other questions about other data sources and the general cleanliness of the data.
The team took a ton of notes, especially about the questions about other data sources. The PO checked with the customer about the frequency of those data sources. They had a spirited discussion.
Afterwards, the team explained that other data sources were known to have what they called “unclean” data. The import would not be as fast and the customer would have to scrub the data. The other imports would not be low-cost. The team couldn’t tell how high-value the other imports would be.
That discussion helped the PO review the roadmap with the customer. The PO and the customer agreed that the team would provide only one more automatic import. All other imports would be their own little projects to scrub the data as they proceeded.
That meant that of the feature set of 15 possible data imports, the team implemented two. The team provided their customer enough information to request (demand) that the vendor scrub their data before they would consider it for import.
This PO didn’t treat the team as if they were a feature factory. The PO treated the team as valued partners.
The PO didn’t treat the internal customer as if their wishes were king. The PO treated the customer as valued partners who could understand the problems the team might have.
The customer explained to the vendor the problems with the data. If the vendor wanted the customer to buy this data, the vendor had choices about scrubbing it.
Notice how everyone here collaborated to find the best solution for now? When we think about value as not just a delivered story, but also about information, we can change how we work.
Teams can provide more than finished features. In fact, teams should. These teams need a full-time PO to be able to understand and process the information.
Consider thinking about value in these three ways:
What you can deliver to your customer to make their lives easier
Information about this story in context of the entire feature set
Information that might change the roadmap, where the entire product might go.
More information might help us collaborate better, inside teams, with customers, and even with vendors.
Sprints, by definition, are a timebox. You’re supposed to say, “Pencils down!” at the end of the sprint, show your work and reflect.
One of the big problems with new-to-agile teams is their inability to finish work inside a sprint. Each team is unique. However, I’ve seen these causes most often:
Team members multitask, so they don’t finish their work inside the sprint. I’ve seen this when team members multitask across too many stories (too many stories started at one time), and when managers ask team members to work on multiple projects.
People work as experts, across the architecture, not as a team through the architecture. This cause often creates WIP (Work in Progress). When people work across the architecture, they often create “UI story,” “Middleware story,” “DB story,” and “Test story.” That’s great for resource efficiency. You can show everyone that people are totally utilized. (Yes, a little sarcasm there.) However, software, especially with an agile approach, is about flow efficiency, where people work as a team to finish one story at a time.
The stories are too large. The team can’t finish one story, never mind whatever they estimated, inside a sprint. Too-large stories have several possible causes. I’ve seen this when a PO doesn’t look for the first possible value in the feature set. I’ve also seen this when teams don’t know the state of the code or the tests and the problem is too complex to finish in less than a couple of months. I’ve written about small stories before. Sometimes, the story is too large because the code doesn’t have unit tests to support changes. You think you can change this little thing over here and bam—it blows everything up.
What can you do if your team doesn’t finish work inside a sprint? Here are the three tips:
Work as a team. I keep talking about pairing, swarming, and mobbing, and that’s because the team focuses on moving one story down the board, as a team. That solves the too-many-stories-in-progress problem. And, if your manager asks you to work on something else, you can say no. That’s because your team depends on you to work with them.
Make sure people (especially leaders and managers) understand about flow efficiency. I like to track cumulative flow so everyone can see the inventory of not-yet-finished work. (See the image below.)
This is a cumulative flow chart from a real project. In this project, the PO tried to “get ahead” of the team. He successfully did. He “finished” creating stories the team never developed. I would call that waste.
The team did a pretty good job of workshopping stories (the analysis) part, but had a little trouble with the developers having work in progress.
The developers had WIP because sometimes their functional managers pulled them onto other projects. This team wasn’t so excited about swarming or mobbing, so the managers felt as if they could pull people off.
The entire team (PO and technical staff) had to learn together what a story was. It took them most of this project to get to one-day stories. Part of their problem was that the story “should” have been small. However, they had a legacy code base with very few unit tests. The team spent tons of time creating unit tests to support their work so they could know if their changes were correct.
This team wasn’t perfect—and they didn’t have to be. They found that visualizing their work was critically important to stopping the multitasking and finishing stories. And, once the team got to about the 11th iteration, they had much less WIP.
Here are the things this team tried:
Track the progress of the story through the team. Track the cumulative flow.
Visualize any “other” work any team member has while everyone is supposed to work on this one story.
Select the smallest story you have. Work on it as a team. Yes, work on one story at a time.
You might have to explain to your managers that you are experimenting so you can increase your velocity. Remember that velocity is capacity, and you are learning about your velocity so you can estimate better.
If your team can’t finish work inside the sprint, don’t automatically carry over work to the next sprint. Visualize where the work is, select the highest ranked work, and work on it, one thing at a time, as a team.
Increase your WIP limits only after the team successfully finishes one story at a time. If you need more help, read Create Your Successful Agile Project. Your problem might not be in the stories or teamwork, but somewhere else in your project system.
When teams don’t finish their work in a sprint, it’s a project system problem. That’s an indication the system has to change. Use all your qualitative and quantitative tools (including retrospectives) to diagnose and experiment with your team.