The Organizational Death Spiral
Last Updated on Sunday, 16 June 2013 10:14 Written by Jesse Fewell Tuesday, 18 June 2013 08:13
I’ve seen a pattern at a number of companies recently. It’s a pattern that demonstrates the danger of doing too many things at once. I call it the organizational death spiral.
Let’s say we have several product delivery teams in our organization, and that senior leadership have identified a handful of strategic initiatives that that are our next immediate priorities. Furthermore, let’s also assume that the estimates for each project add up to where we should be able to get them all done during the next quarter. Then we go upon our merry way building new products and services, just as management asked us to.
However, we know that challenges happen. For example, most companies simply are not organized into purely independent teams that can churn out products all by themselves. There’s almost always some kind of dependency on another team for those design specs, or some technical team for that fancy component, or some compliance team for full end-to-end behavior. Inevitably, this means at least a few teams have to shift their local priorities around on a regular basis in order to get anything done.
The problem is that juggling too many things at once decreases our focus, and slows down productivity. This is phenomenon is called “context switching”. There’s a ton of literature out there about how it slows down delivery, and makes us less predictable on delivering on deadlines.
As a result, product leaders are frustrated. We miss a date, which means we miss a market window, which means that project X is no longer worth the investment. So, leaders do what any mature leader should do: they kill the project, and replace it with project Y. It makes perfect strategic sense.
However, as soon as we make that change, we suffer more context switching and more delays in getting work done. Delivery teams become even more fragmented and even more frustrated (“Those executives keep changing their minds. They’re not committed to the long term and are only interested in the latest shiny object”).
After more project delays and slipped delivery dates, management decides “If we can’t get any one thing done on time, then we should work on everything at once.” Which leads to more fragmentation and context switching, which leads to poorer delivery.
…and it goes on…and on…and on.
Delivery organizations often assume that its all the product leadership’s fault for having shifting priorities. Meanwhile, leaders assume it’s all the fault of engineering, or IT, or service delivery for not organizing the work properly to get things done. The heart of the problem is that both organizations are interdependent. Specifically,
To stop the madness, the right people need to get into a room and declare “we doing only the single most important, top-most critical item right now. Then, with whatever extra capacity we have, we are going to repair our delivery organizations to handle more.”
It takes courage at multiple levels in the organization to do this. It requires that admission that we have a problem, and the iron will to do whatever it takes to fix the underlying disconnect between expectations and delivery against those expectations. Maybe you need to reallocate skillsets into different teams. Maybe you need to invest in fixing a quality problem. Maybe you need to implement a disciplined portfolio management competency.
But whatever medicine you take, the first step is to reconize you have to get off the crazy wheel of poor delivery impacting poor priorities, in turn impacting poor delivery.
What about you? Have you noticed that priorities and delivery BOTH impact each other?Learn More
Agile and Sales: Reflections on my first Scrum Sales Team
Last Updated on Wednesday, 29 May 2013 09:06 Written by Eric Kristfelt Wednesday, 29 May 2013 09:06
After working as a sales manager at two different Agile organizations I am often asked if sales can be Agile, and if so, how is it implemented?
At my previous company, several departments chose to align with the development team’s 2-week sprints/builds. The marketing department started using a Kanban/Scrum approach, and it made sense as the marketing goals naturally aligned with the builds and releases. But would a Kanban/Scrum approach make sense for the Sales team? And if it makes sense, where should we start?
Step 1: Training: It is important for the teams to be trained on Agile/Scrum so that they understand the methodology and the goals. It can help everyone if the sales team begins to gain a better understanding of the development cycle. One challenge we faced was determining how to set-up our teams. Typically, sales professionals are viewed as individual contributors and not part of a team. We found that management had more challenges moving to a team approach than the sales professionals. Successful sales people are accustomed to working within a team given today’s complex sales models — which mean working with everyone from sales engineers to consultants to management and even Legal teams. Most individual contributors realize that this is the reality of today’s business.
Step 2: Stand up: Stand ups allow teams to adapt and react quickly to how the process is working for customers and external teams. Stand ups are a natural for sales teams; most sales people are impatient and like short meetings that are to the point, and that can help them resolve problems and focus on accomplishments. At my former company, if a particular impediment was outside the scope of the sales team, we might invite members from other teams to attend the next stand up. Our sales people hated being required to listen to others dig into their own issues, so moving longer discussions to “post meeting” status was popular among our sales people.
Step 3: Sprints and Retrospectives: For sales, the sprint cycle may be much longer than recommended for a typical development team, but it’s important for sales managers to follow the sprint structure. Sales teams often work on monthly goals, so that’s how we set up our sprints–much longer than a development sprint– but a period of time that made sense for our goals. We could determine what we accomplished the previous month, review impediments that were not resolved, and determine our goals for the upcoming month/quarter. These types of reviews are very natural for sales teams; although a step that many skip in the busy day-to-day pursuit of closing deals.
Step 4: Re-interpreting Product Backlog: Our team implemented an EPIC board (Customers) and Tasks were set up as “backlog items” with a “pending”, “in-progress”, or “completed” status. Suddenly, the entire sales and sales management team had a clear visual for the enormity of tasks during the iteration. Velocity (or, in this case, expected sales per iteration) was available for inspection and adaption. This approach allowed the sales team to focus on their workload, and it helped minimize distractions from management. Even the engineering teams would walk by the boards and understand what was going on with accounts and opportunities.
Challenges to Agile Sales Models:
Switching to Agile wasn’t easy on the management team. How would they hold individual sales people responsible? How would they compensate each sales rep? What if someone on the team wasn’t making enough calls? Many executives thought the stand up meetings would be too short to accomplish all of their weekly goals.
The company I worked for set up a true sales scrum team with monthly iterations. The teams hit the goals set up by management, and for 6 months we iterated and worked as a Scrum Sales Team. From a sales attainment perspective, it was the most successful the team had ever been.
For reasons I still fail to understand, the company restructured itself, and the Scrum Sales Teams were eliminated, but not before we realized the power of Agile within sales. It was the first time that entire teams reached quotas assigned to the company, as opposed to just individual sales contributors. Onboarding and ramping up new reps happened more quickly; most likely due to interfacing with successful senior reps.
By following the steps in Scrum, management learned that sales can lend itself easily to an Agile environment. Individuals found that this shared work model led to more consistent revenue and compensation in addition to a more even workload. No longer did the “sales stars” work much harder than everyone else. Each team member focused on his/her own domain expertise.
While we found it difficult to find “Renaissance sales people”, we were able to create the perfect sales person by matching skills, or by filling voids by marrying strengths and weaknesses of individuals within every given team.
Scrum also allowed a better quality of life: Sales teams had time to enjoy vacation or family time because the team could step in to support customers while any single member was away. Our teams were self-managing, and the sales manager acted like a Product Owner as opposed to a Scrum Master.
Let me know your thoughts and experiences implementing an Agile sales model.
–Eric KristfeltLearn More
Getting Teams to Deliver Predictably
Last Updated on Friday, 24 May 2013 01:10 Written by Derek Huether Tuesday, 21 May 2013 03:02
As recently as this week, I’ve been involved in conversations with customers about how we can help make their teams deliver more predictably. How can they meet commitments on all levels of the organization, including project, program, and portfolio?
Well, it’s not easy. There is no silver bullet that is going to allow you to align the organization overnight. I do, however, have one recommendation: Stop trying to maximize the utilization of your people. I know some are going to find that hard to understand. To maximize value throughput, you need to keep your people as busy as possible, right? Didn’t Henry Ford do it that way, when he had cars coming off the assembly line at three-minute intervals? Actually, no, he did not. What he had and what you need is a balanced system.
Henry Ford did not have everyone working at 100% utilization. If everyone worked at 100%, the result would have been congestion — bottlenecks within his (assembly) system and the production of excessive parts inventory. Instead, one of the many things he did was focus on limiting lead times. That’s the time something waits before an activity happens. By understanding his system, he was able to have the right amount of people, working at the right pace, in the right sequence, in order to maximize flow (delivery through the system).
When trying to get your teams to delivery predictably at your organization, let’s look at this from a 100,000 foot view:
- Understand Current and Potential Capability and Capacity
- Understand the Delivery System and Establish Goals
- Balance Capacity and Capability with delivery throughput
- Monitor Performance
That is how you establish predictable outcomes.
Now let’s look at this with some detail.
Understand Current and Potential Capability and Capacity
You’ve probably heard the analogy of a freeway being a value delivery system. If not, let me draw the parallels. On a freeway, we don’t care about utilization; we care about throughput. That is, we don’t care how many vehicles can fit onto the freeway. We care how quickly we get from point A to point B. Measuring the capacity of the freeway is not going to directly help us. Measuring the throughput will. For those who follow Lean Startup, these are referred to as vanity metrics and actionable metrics.
Actionable metrics can lead to informed decisions and subsequent action. Example, I know how fast the vehicles travel on a given freeway, therefore I can plan accordingly to arrive on time. Vanity metrics show that you’re measuring things, but they really aren’t helping you. You need to measure the right things. By measuring the capacity of a freeway and then trying to fully utilize it would be foolish. Strangely enough, I see organizations do that with their people all the time. They try to keep them as busy as possible.
Understand the Delivery System and Establish Goals
We don’t build bigger freeways so they can hold more vehicles. We build bigger freeways because we’re not smart enough to figure out how to limit the size or amount of vehicles on them at the same time. The fewer or smaller the vehicles on the highway at the same time, the faster everyone moves along. To increase throughput (speed) on a freeway, you need to increase the ratio of space utilized by a vehicle relative to the total space of the freeway. If we could increase the (distance) buffers between the vehicles, we’d have fewer start and stops along our commutes. Once we hit higher utilization rates, things dramatically slow down until we have traffic jams.
Balance Capacity and Capability with delivery throughput
It’s the same thing with knowledge based systems! Exceed a 70% utilization rate and you’ll begin to see dramatic performance decreases.
One thing that I have seen that is bringing it together is enabling teams to make their own commitments. Once they have a sequenced queue of work and all the people necessary to complete that work, allow them to commit to, start, and then finish it. You should begin to see the flow of value start to emerge. Don’t pull people from the team to give them “busy” work. Don’t push extra work on the team to keep them busy.
You can tell if your people are over-utilized by measuring the lead times. If their work is properly sequenced, and they limit the size and volume of work they agree to do at any given time, the result should be minimal delays. If you want to go faster, you may have to change the system. Measure how long it takes to get something through your system. Reflect on that. Were there any dependencies on other people or resources that slowed you down? Did you have your people over-utilized? Was the work you committed to too big? Look for an area of possible improvement, address it, and run work through your system again. Did the lead time get shorter?
Going back to the commuting analogy, for those doing the driving, understand the conditions and know the optimal start time to begin your commute in order to avoid delays and arrive at your destination without breaking any laws. For those asking for arrival commitments, respect what the driver tells you. If you don’t, you’ll find people doing things like driving on the shoulder or illegally speeding in the express lane, just to arrive on time. Sooner or later, there’s going to be an accident.
Thinking Together for Release Planning
Last Updated on Sunday, 19 May 2013 09:43 Written by Dean Stevens Saturday, 18 May 2013 08:32
I’ve been noodling on the phrase “Thinking Together”. Thinking Together is one aspect of the mindset that Product Owners need to embrace. I have been using this phrase with new Product Owners to explain why many Agile practices work. But each time I start to write about this simple idea, it gets complicated because I get into process steps and roles and responsibilities.
Yesterday, I returned to a big company with a pretty complex product portfolio where we had done quite a bit of work including starting up multiple Scrum teams. I recalled our first release planning with this group. There was a lot of uncertainty and even some anxiety about this “lightweight” approach.
They were missing their requirements and specification documentation. They were hesitant to assess the value and size of the features, concerned they might leave something out. I prepared a Release Planning agenda for them to follow. I also prepared a list of roles and responsibilities. And I had some one page cheat sheets on the activities for release planning. They needed some process rules initially to learn how to think together.
When I ran into a Product Owner from this big company months later, the changes they had made were obvious. He was facilitating release planning and was excited to walk me through it.
My friend the product owner brought me into the conference room where they were wrapping up their release planning. There were some product managers, the product owner, some tech leads, QA and even a project manager. They were taking a break chatting and smiling. There were some architectural sketches on the white board. There were four flip chart sheets with sticky notes representing epics and features. The flip chart sheets represented the work completed for the past release, the plan agreed to for the next release, and planning for the following release. They had one more sheet with parking lot items.
The product owner showed me the result of their Thinking Together. They had discussed the epics written on blue stickies and wrote all the features they might need on purple stickies and put them under the epic. Then they thought together some more and rated each feature with business value, complexity and sizing. They added some acceptance criteria and clarified assumptions as they went. They did this for several epics. Then they started adding features to the flip chart sheet representing the next several releases.
Now, they realized they would not get everything done that the product managers wanted. So they moved some lower value features to the parking lot and rearranged the features on the flip chart sheets until they agreed on a plan. By Thinking Together in planning the next couple releases, they pretty quickly learned together and gained a shared understanding of the work they would do for the next six months.
They had learned to Think Together to get the end result: a solid release plan.
Scrum Gathering Las Vegas – Large Scale Program and Portfolio Management with Scrum
Last Updated on Thursday, 9 May 2013 04:52 Written by Mike Cottmeyer Wednesday, 8 May 2013 04:04
Hey everyone… I’m out in Vegas this week at the Scrum Gathering. Got invited to speak… which was really cool (thanks Daniel Gullo)… and did the most recent iteration of my Agile Program and Portfolio Management deck. Take a look and let me know what you think!Learn More