The Organizational Death Spiral

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.

The story
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.

The Reality
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.

The problem
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,

The solution
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?

Visual Evidence of an Agile Release

Written by Peter Callies Wednesday, 12 June 2013 02:54

Below is a fancy release burnup chart (click it to see the full image) that visually shows the work of a team from a recent release by a LeadingAgile client.

The red line effectively is the amount of risk. You can see that the team started the release with about 50% of their stories unsized, but consistently drove that down through the first half of the release.

You can see the impact of end-of-release hardening in the flatness of the shaded blue area on the right side of the chart.

In the shaded gray area, you can see the team performing backlog grooming, breaking down the work into estimated stories and even cutting scope mid-release (the gray area increases as the red line decreases).

The flatness of the shaded blue area early in the release shows the impact of a backlog that isn’t well-groomed, but as the team drove that red line down, the blue area takes on a more-consistent positive slope.

Cool stuff that demonstrates the impact of a groomed backlog and the effectiveness of a team.

Building the right software…right, It’s easy…RIGHT?

Written by Isaac Hogue Tuesday, 4 June 2013 04:45

We encourage the teams we coach to keep their eye on the ball: Delivering a product that reaches a defined goal and thereby delivers value to its stakeholders in the most efficient, predictable and reliable way possible.  This process of delivery frequently includes helping teams improve their internal product elaboration and development practices through the use of Behavior Driven Development (BDD) and Test Driven Development (TDD).   And in doing so, it is my observation that there is a bit of confusion over the distinctions between how to focus teams on building the right software, and building the software right.

It seems that one of the key drivers for this confusion has to do with where Acceptance Test Driven Development (ATDD) fits into the development lifecycle.  At present, BDD and ATDD both loosely describe a clarification process for iterating or incrementing around acceptance criteria for a given business goal that results in a just-in-time scenario or example-based specification.

What if we clarified things a bit…?

Perhaps we could reduce confusion around “building the right software… right” by redefining the specific meaning and places for BDD and ATDD as follows:

- Formalize the meaning of BDD around the practice of defining the “right” product through goal-oriented behaviors or scenarios.

- Formalize the meaning of ATDD around the practice of building the “right” product  by connecting behaviors to automated acceptance tests.

How about the following as a high-level map for “building the right software… right”:

This approach clarifies the terms and provides a specific meaning and place in the development lifecycle for BDD, ATDD, and TDD.  In my experience the above map has reduced confusion around how to “Build the right software… right”.

Let me know what you think.  I’m eager to hear your thoughts and concerns around such a mapping.

Agile and Sales: Reflections on my first Scrum Sales Team

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.

Lessons Learned: 

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 Kristfelt

Getting Teams to Deliver Predictably

Written by Derek Huether Tuesday, 21 May 2013 03:02

queue size compared to utilization

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.

Monitor Performance

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.