Tag Archives: Agile

What is value?

The majority of agile related articles, blogs, books keep telling us that value is paramount and that we should sequence work by value and that we should be value driven. However, none seem to tell us what exactly value is and what exactly the author means. A notable exception would be the well thought out work available at Black Swan Farming’s Web site.

Most likely, this lack of specificity is due to the realization that nailing down the definition of value is hard and we run into all sorts of problems when we try and concretely define what that term really means.

The first question that pops into mind is: “Are we talking about customer value, or business value, or operational value?” Those three are not the same and sometimes what’s perceived as valuable from one perspective is frowned upon by another (e.g., better utilization of pizza delivery drivers/vehicles negatively affects quick delivery to customers). Additionally, the word customer is ambiguous–are we referring to the user or the buyer of our product or service?

To complicate matters further, we often have situations where something may have customer value but no business value. For example, the company may not want to invest in the development of products or functionality because it is too costly relative to the revenue it’ll provide; likely will be hard to maintain; or inconsistent with the company’s strategy, competitive positioning, or brand. In certain situations, the reverse is also true–there are things that may be valuable to the business but not to the company’s customers. A company investing in analytics and business intelligence reporting to better determine how to target customer segments, or a company consciously making a decision to deliberately lose X% the least profitable (or unprofitable) customers, are examples of items with no customer but significant business value. The same line of thinking can be applied to operational value as well–things need to be done to keep the lights on or to improve the ability of existing systems to service current and anticipated needs.

As if that wasn’t enough, a further complicating factor is that value is not a constant; it changes over time. Fashion trends and seasonal clothing are examples where value becomes negligible at the end of a narrow time window. On the other hand, the value of specific tax functionality increases dramatically the closer we get to tax season but plunges once early tax filers discover that the functionality they need doesn’t exists. A similar but smaller window opens up for late filers but that disappears after April 15th as well. What this means is that we cannot prioritize work based on “value” once and forget about it–there is a need to revisit this every so often.

And finally, we ignore the very real possibility that someone else will come along into the market, disrupt it, and refute all of our assumptions. This becomes more likely in competitive environments for high value-add products, services, or features.

A number of IT departments try to get around this problem by treating the business as a customer and by doing what the business asks for in the order asked for. But, the business is NOT the customer! They are partners that together provide value to the customers. When we start treating internal groups as customers we lose sight of the real customers and start prioritizing work based on the (often conflicting) needs or perceptions of the many internal groups.

Common ways of calculating “business value” are ROI–the benefit (or return) of an investment divided by the cost of the investment expressed as a percentage or a ratio–and NPV, that unlike the point-in-time ROI considers the flows of money over time. However, NPV is difficult to calculate accurately due to significant assumptions about discount rates and future inflows. And neither work well when dealing with non-profits–they care about other things over making financial profits. In reality, there are multiple goals of an organization:
– reduce costs
– gain market share
– build better relationships with a customer segment or intermediary (e.g., latino roofing contractors)
– increase assets under management
– code maintainability, security needs

And when we really think about it, doesn’t the, currently in-vogue, term “business value” really mean what is valuable to the company? And shouldn’t everyone and every group/function/division already be doing what the company values? Does the term “business value” as currently used really add any additional meaning?

Considering the difficulties, I’ve come to believe that we need to abandon the idea that business value is a simple formula into which we can plug-in values ahead of time and apply to feature sequencing. Instead, we need to realize that “value” requires interpretation–and sometimes a sole product owner doing all the interpretation does not make work well.

We instead need to focus on the organization’s goals and the desired outcomes. Value of proposed initiatives, then is their ability and degree to address the sought after strategic goals. Lower level initiatives/projects/whatever should be in support of those higher-level goals–the battles should help win the war.

And because, of the rapid rate of change, we cannot know up-front exactly to what degree an individual initiative will contribute to the higher-level goal(s), we must treat the proposed initiatives as hypothesis. As we really do not know with certainty what is valuable and to what extent, we encourage experimentation, learning, and continuously improving our ability to meet the desired goals.

How have you defined and used value when sequencing work?

Leave a comment

Posted by on August 29, 2018 in Uncategorized


Tags: ,

Are leaders and the company culture the real problems to agile adoption?

Most surveys about the state of agile, point to the existing culture and leadership as the primary causes of agile struggles. But are those two, and their derivatives, really the culprits?

Isn’t it curious that our goal, as agile coaches, is to deliver value by ascertaining how best to meet the needs that are determined by the organization, and yet we consider the organization itself to be the biggest impediment to doing so. Is it possible that the problem is not in the organization’s culture and management structure but in our own assumption that there is a singular definition of value and our determination to deliver on that definition despite the organization we are trying to transform? Could it be possible that the client organization understands what is value in ways that we do not?

G. K. Chesterton in this 1929 book, The Thing, said:

In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, “I don’t see the use of this; let us clear it away.” To which the more intelligent type of reformer will do well to answer: “If you don’t see the use of it, I certainly won’t let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.

This paradox rests on the most elementary common sense. The gate or fence did not grow there. It was not set up by somnambulists who built it in their sleep. It is highly improbable that it was put there by escaped lunatics who were for some reason loose in the street. Some person had some reason for thinking it would be a good thing for somebody.  And until we know what the reason was, we really cannot judge whether the reason was reasonable. It is extremely probable that we have overlooked some whole aspect of the question, if something set up by human beings like ourselves seems to be entirely meaningless and mysterious.

There are reformers who get over this difficulty by assuming that all their fathers were fools; but if that be so, we can only say that folly appears to be a hereditary disease. But the truth is that nobody has any business to destroy a social institution until he has really seen it as an historical institution. If he knows how it arose, and what purposes it was supposed to serve, he may really be able to say that they were bad purposes, or that they have since become bad purposes, or that they are purposes which are no longer served. But if he simply stares at the thing as a senseless monstrosity that has somehow sprung up in his path, it is he and not the traditionalist who is suffering from an illusion.

In other words, an organization’s culture has evolved for a reason and has likely been strongly influenced by what the organization has found to deliver value in the past.

Culture is a pattern of shared tacit assumptions that was learned by a group as it solved its problems of external adaptation and internal integration that has worked well enough to be considered valid and, therefore, to be taught to new members as the correct way to perceive, think, and feel in relation to those problems. ~ Edgar H. Schein

Since it’s inception, any organization has had to learn what strategies, values, procedures, behaviors, and norms work within its environment. Those that do not further the company’s mission are discarded; those that do are retained and progressively improved over time. This history of learning, by trial and error, is rarely written down but forms the basis of tacit assumptions and norms — the collected wisdom about what leads to success within the organization. What is valued by the organization, then, gets encoded in the company’s culture and their bureaucracy. To the uninformed, this bureaucracy may at first glance seem capricious, brutal, and wasteful, but it is simply a way for the organization to ensure that people pay heed to what is considered important in that organization. For example, the “burdensome” security scans, reviews, and audits in some financial institutions only point to the organization’s belief that doing right by the client is important and that their personal data must be protected at all costs or that our brand is everything to us and we shouldn’t needlessly take on risk that might harm our brand image and reputation.

The Chesterton’s fence principle applies to agile introductions as well. Again, Chesterton’s fence is the principle that reforms should not be made until the reasoning behind the existing state of affairs is understood. Just because there doesn’t seem to be a readily apparent reason for this fence to be here doesn’t mean there isn’t a reason. What this means is that Agile coaches must first come to understand those values, strategies, and goals that are embedded in the client organization’s culture.

Most agile proponents however, are far too eager to tear down what exists, without first understanding why that exists, in order to put in place what they believe is “agile” and “better.” It is the rare agile coach that takes the time to first understand what the company values — most coaches are aware of one way of doing things (insert the name of your go to agile framework here) and want to jump straight into the mechanics of implementing it. They often do this because they want to demonstrate, to the client, that they themselves are adding “value.”

The result of not heeding Chesterton’s fence is that the agile coaches frequently run into “resistance.” This resistance is chiefly due to the client management’s perception that what they value and what their concerns are aren’t being considered.

Agile proponents come in and say we should discard X and do Y instead in order to not have to deal with the negatives of the existing X.

X     |       Y
+                |
-                |

But clients believe (whether incorrectly or not) that the benefit of the agile evangelist’s point of view (Y) leads directly to a loss in what the client believes is important to her (X). In addition, they perceive that the new approach simply swaps in a different set of negatives.

What coaches could do instead, is to work together with the client to come up with a solution that explores how to get the “new” benefits without losing the benefits of the existing approach/culture. Instead of approaching the transformation in a “big bang,” where the existing culture and structure is swept away in one fell swoop, a measured incremental approach where we learn as we go might be better. Agile coaches could take an agile approach to agile adoption — drive organizational change incrementally and make course adjustments based on what they learn about the organization’s true needs and dynamics.

But clients believe (whether incorrectly or not) that the benefit of the agile evangelist’s point of view (Y) leads directly to a loss in what the client believes is important to her (X). In addition, they perceive that the new approach simply swaps in a different set of negatives.

What coaches could do instead, is to work together with the client to come up with a solution that explores how to get the “new” benefits without losing the benefits of the existing approach/culture. Instead of approaching the transformation in a “big bang,” where the existing culture and structure is swept away in one fell swoop, a measured incremental approach where we learn as we go might be better. Agile coaches could take an agile approach to agile adoption — drive organizational change incrementally and make course adjustments based on what they learn about the organization’s true needs and dynamics.

Leave a comment

Posted by on August 25, 2018 in Agile, Coaching, leadership


Tags: , , ,

Why do organizations limit their agile focus to just development?

Seems like I’ve been suffering from frequency illusion (aka blue car syndrome) recently. I’d been mulling over the fact that a majority of clients I serve don’t invest wisely in DevOps or simply don’t know how to proceed. A recent one, for example, has been crafting a DevOps strategy for over a year with nothing to show for it. Sadly, the DevOps initiative and group is considered separate from all the teams doing agile. Interestingly, I suddenly started seeing lots of data supporting my belief — most likely, I was primed to see it crop up everywhere.

Forrester’s 2014 report, “How Can You Scale Your Agile Adoption?” and Cloudbees’, “Four Quadrants of DevOps Maturity” reinforce the notion that the late stages of the software development cycle are usually given the short shrift.

We know that software development entails more than just development. To keep the discussion simple, software development can be thought of a sequence of activities (and associated information and work product flows) encompassing understanding customer and stakeholder needs, planning, designing the offering, coding, building, integrating, testing, releasing/promoting, deploying, operating, and getting feedback for the next cycle.

While a decent percentage of companies are focusing their agile efforts on the pre-integration stages, less than 15% have introduced agile principles, techniques, and practices in the integration and post-integration steps. So, while companies get better at developing software they still are gated and held back by unnecessary delays in the later stages of the life-cycle.

As an aside, I’m not considering funding, sequencing of work across the stakeholders, and requirements being pushed to teams without regard to their capacity and ability to deliver here — areas that still need tremendous work in most organizations. Also, SAFe has rightly emphasized attending to the team structures but often overlooked in agile transformations are the facts that teams don’t have all the skills needed, team membership is unstable due to shortage of necessary skills, there is a lack of focus on minimizing dependencies (highlighting dependencies is not the same as minimizing them), and the business and teams aren’t often aligned.

This issue of lack of agility, post-coding manifests itself in a few major ways:

  • Teams struggle with lack of environments for developing, integrating, and testing.
  • Extreme risk aversion in the second half of the cycle at times often precludes teams from promoting their own code — they then face significant challenges in testing their work in a timely manner.
  • Deploying to higher environments can at times be a cumbersome, bureaucratic process — infrequent promotions and deployments delay defect discovery and slow down feedback. Consequently, feedback cycles of 2 weeks or less in development balloon to weeks and even months in the latter stages.
  • In a handful of cases, development organizations start using tools (whether open source or not) that Operations does not have the skill or personnel to support.

Quite a few companies treat DevOps and Operations as separate from development. Most don’t treat DevOps as a function but as a team. DevOps teams with managers are just another silo and a significant number of people think they do DevOps just because they have a team called DevOps. Even worse, I’ve far too often seen QA, Automation, and Development as separate groups with their own goals and agendas. Throw in the fact that different vendors (often competing for additional business) often perform each of these activities and you just make the situation worse.

So, here are a few things to think about:

  • How can we change the mindset of the folks doing and managing the second half of the activities to be more agile?
  • How can we create a true DevOps function, where the business, development teams, and operation staff collaborate from the start? How do we break down the boundaries between these roles?
  • How can we encourage larger organizations to start their agile journey with aligning on a DevOps strategy quickly and improving the DevOps function to immediately address the huge delays and waste?
  • How can we make it easy for developers to request and get environments to build and test against?
  • How can we help companies recognize that a repeatable infrastructure and application deployment process is extremely necessary?

We would love to continue the discussion and talk about our experience in making Agile work for DevOps. Please reach out to us (Jon at 702-389-8160 or Alex at 949-667-1008), or if in Las Vegas, attend a DevOps centric meetup (more information at

Leave a comment

Posted by on February 20, 2017 in Agile, Improvements


Tags: , , ,

Increasing Predictability

The previous two blogs (3 things that matter when embarking on an Agile transformation and five stages to organizational agility), listed Predictability as an important initial step on the journey to Agile at Scale, where, predictability implies the ability to accurately answer, “When will it be done?”

Smooth flow — the effective, efficient, and sustainable paced delivery of customer value — and predictability go hand-in-hand; you cannot have one without the other. Uneven flow is usually discerned, on your cumulative flow diagram, by large buildups of work somewhere in the process.

Impediments are a major cause of uneven flow and lack of predictability; however, there are a number of other contributing factors. A partial list would include some of the usual suspects:

  • Backflows (defects and rework)
  • Starts and stops (do-wait cycles — delays between steps, task switching, people being pulled in multiple directions to work on different efforts)
  • Large work items and large batches
  • Work-in-process being canceled and being taken off the Kanban or Scrum board
  • Organizational silos and a lack of communication, cooperation, coordination, and collaboration across departmental boundaries
  • Lack of swarming within the “team” to complete work quickly
  • Scope of work being changed once it has been committed to (often by adding scope or acceptance criteria)
  • Dependency on external vendors or teams
  • Hesitancy in roadblock removal
  • Overtime (initial increase in rate of work completion followed by a decrease due to burnout)
  • Mismatch between available skills and the task complexity
  • Variability inherent in the work itself

To the above, you could also add a couple of other non-readily visible causes:

  • Expediting some items to the detriment of other items — e.g., items in an expedite lane being given preferential treatment, thereby, slowing down all the other work in-process items
  • Non-FIFO implementations (where teams cherry-pick items from their process queues to work on) prioritize some items over others. This results in the non-preferred items taking longer to complete than they would have otherwise, i.e., cycle times for preferred items have been artificially reduced at the expense of the other items.

And, of course, the biggest culprit of all:

  • Mismatched input and output rates that cause work-in-process (WIP) to constantly increase and Cycle Times to lengthen. Ideally, your CFD should have parallel and narrowly spaced, arrival and departure lines.

While one of the main tenants of Lean is waste removal, sustained waste removal is not possible without the ability to first see the waste. Similarly, improving flow is difficult without first being able to see what is impeding flow.

To start your journey to becoming more predictable, do the following:

1. Visualize the work flow

Understand the scope of your system and the activities that help convert the inputs into the desired outputs:

  • Create a flow diagram
  • Identify the boundaries of the system (the input/entry and the output/exit stages) you are concerned with improving
  • Identify the steps and each step’s input, output produced, and policies (conditions of doneness)
  • Identify the Definition of Ready, Definition of Done, cadences, and event triggers

2. Capture data

Agree on what flow and predictability related metrics make sense in your context and then determine what data to capture and where to get that data from. Understand where things currently stand by getting baseline numbers for these chosen metrics.

3. Implement tactics to limit causal factors

Brainstorm, discuss, agree, and implement tactics to limit causal factors to unpredictability and irregular flow:

  • Mismatched rates of incoming work and completion of work
  • Instability of teams (their composition and number)
  • Lack of clarity of requirements and when to implement them
  • Scope creep for in-process work
  • Starts and stops
  • Delays due to waiting (for work to be done)
  • Work being canceled while in-process
  • Arbitrary aging due to blocks, excess WIP, and poor pull (including non-FIFO and expedite)
  • Overtime to compensate for excess WIP and mandated artificial deadlines

An output of this step should be a list of explicit process policies that address the above mentioned. Additionally, an agreement on how the whole team will handle defects, rework, and canceled work on their Scrum or Kanban board will go a long way in reducing confusion and waste.

4. Get to a stable, WIP-limited, pull-based, system

Get to a point where your Cumulative Flow Diagram indicates smooth flow via parallel and narrowly spaced, arrival and departure lines. You do this by tackling the factors that inhibit flow and predictability (item 3 above).

Remember that some variation always exists (and always will) within your system and can be seen in your story completion time scatter plots. Your goal, therefore, should not be to drive out all the causes of variation completely, but to identify and understand the special-cause variations that make your process inherently unpredictable. You can then take actions to address these special causes.

5. Improve flow continuously (start reducing time to market)

Once you have a stable system, from Step 4 above, you are then ready to experiment to improve the process and to increase your ability to rapidly respond to change. A stable, well-running process is necessary even if you are in a lean startup environment where you are trying to figure out your market and making sure that you are building the products your customers want — a smooth and dependable process will give you the confidence to change direction quickly without worrying about delays. Predictability and Adaptability are not mutually exclusive – you can have one with the other.

While Step 2 provides an initial indication of where you are starting from, Step 4 provides a solid baseline for you to base your improvements on. Every improvement you now make should be to improve the baseline measures. For example, if you think that adding an Expedite swim lane is necessary to address emergencies you can track the change on approximate average cycle time and actual throughput to determine the efficacy of the intervention. Likewise, you can gauge the impact, on delivery, of introducing Classes of Service and treating them differently.

Hopefully, the above will help you in your agile transformation journey. Comments and further conversations welcome.


Posted by on February 8, 2017 in Agile, Coaching, Improvements


Tags: ,

Five Stages To Organizational Agility

Building on the previous blog post about the importance of focusing on and continually improving flow, quality, and value delivery, we can turn to the stages to achieving organizational agility. Achieving organizational agility involves deliberately improving the following (in order):

  1. Visibility
  2. Predictability
  3. Time-to-market (Flow)
  4. Value / Outcome driven
  5. Organizational Agility

All steps are underpinned by cycles of: assessing, defining the improvement strategy, training, and coaching.

1. Visibility

Visibility presupposes a culture of transparency, openness, and safety (protection from retribution and loss of reputation, health, money, and relationships). Without such a culture, you will not have true visibility and visual management will be a sham. Michael Ballé, in The Lean Manager, defines Visual Management as “seeing together, so we know together, so we can act together.” When information is hidden, people cannot see together and are likely to act in sub-optimal ways.

2. Predictability

With clear visibility you can begin to gauge and improve the predictability of your overall process. Predictability implies the ability to accurately answer, “When will it be done?” Making your processes more predictable and being able to reliably and consistently meet delivery commitments is the first step in building trust with business partners, stakeholders, and customers. Predictability can be gauged by studying Cumulative Flow Diagrams and work item completion cycle time scatter plots. These give you a baseline from which to start your improvement efforts.

It is important as a first step to regulate the arrival rate of new work to the completion rate of work by the teams. Work should not be started at a faster rate than work is completed. If it does, then you are faced with a situation of ever increasing work-in-process (WIP) and lengthening cycle times — the perfect recipe for increasing unpredictability. Stabilize the system (i.e., prevent cycle times from increasing) to have any hope of achieving the goal of predictability.

3. Time to Market (Flow)

Once you have a baseline and a sustainable stable system, you can begin experimenting with a view to increase flow and predictability. A fundamental approach is to begin by removing impediments. Use the scientific method. Determine what to improve, propose a hypothesis (an impediment to remove), plan the implementation, define expected outcomes, implement the change, compare the actual results to those expected, and then determine next steps: persevere, pivot, perish (or kill).

Improving flow (to shorten the cycle to discover ideas, develop and deliver solutions, and validate learning) can be discerned by the increasing rate of progress of work items from left-to-right on the team’s work-flow visualization board and by the lack of large buildups of work somewhere in the process. Flow is enabled by ensuring alignment around intent while granting autonomy around actions — state the goals clearly, but let teams navigate towards the goals by determining the best approach locally.

4. Value- or Outcome-Driven

While value is important, it has been mentioned fourth for a reason. If the delivery system is broken, inefficient, or unpredictable, it makes little difference what is fed into that system or in what order. With a stable, smoothly flowing, system you can now really start focusing on ensuring that you are providing the most value possible.

Improve your capability to define and deliver working solution increments that meet customer needs and solve their problems. Use a clearly defined purpose and these sequenced increments to align business, technology, and operations. You will now likely run into challenges with how funds are budgeted and allocated to projects and/or products. Having conversations with Finance about alternate approaches will now be much easier because you (IT) already have a track record of execution and predictable delivery.

Being value- or outcome-driven implies building the right thing, being focused on product rather than execution, and having the skills to figure out earlier what to make. Start with the end in mind then ask, “What experiments can be run to affect the outcomes?”, “What capabilities do we need to develop to realize the outcomes?”, and “What behaviors do we need to develop?”

5. Organizational Agility

There is a laser focus on identifying measurable goals, determining probable success factors, identifying necessary conditions for those factors to occur, and implementing a plan that helps create the required necessary conditions. Leaders are proactive in designing organizational structures, rules, and policies that enable agility throughout the organization. Agile practices have permeated the culture and have eliminated most or all of the business pain points. Finance, budgeting, HR, and governance groups are all agile and can work with agile artifacts for satisfying audit/governance needs.

Everyone understands the dictum that “Lean is not about removing waste but about problem solving towards a vision!” and without prompting continually strive to improve himself, the process, and the organization. This is also where leaders can set challenging goals for teams and help them improve via self-development learning cycles.

An Approach to Achieving the Agile at Scale

Table 1 provides a little more information on steps 2-4 discussed above for improving your organization’s ability to deliver value to customers. Over time move from Level 1 to Level 3 for the three areas: Product, Team, Management.


Table 1. Steps to realizing Agile at Scale

This journey is not easy and can easily take you a couple of years or more to become truly nimble and customer-focused. There is significant additional detail about the practices recommended and behaviors required for each of the nine cells above.


While this blog provides a high-level view of the approach we recommend, it doesn’t go into all the detail needed to move from stage-to-stage (visibility to predictability to flow, etc.), what aspects to pay heed to, and how to sell and implement the changes.

We would love to continue the conversation with you. Reach out to us if you’d like more information or if you think you aren’t seeing the business benefits you had originally envisioned before starting on your agile journey.


Posted by on February 8, 2017 in Agile


Tags: , , , ,

Managing Risk on an Agile Program

Somehow, risk management is often given the short shrift when companies are transitioning to Agile. Either they create a risk register at the beginning of the project and then forget all about it, or worse, pay no heed to risk management. Neither is a good option; instead, they can use a light-weight approach to identify and manage risks.

Yesterday, I reused an old (2007) risk management presentation (Risk-Management-eBiz) at the current client and the workshop was surprisingly well received. I thought I’d share. Download the Risk-Management-eBiz PDF to follow along.

Step 1: (5 minutes)

Explain the goals of the workshop, the process that you’ll be following, and show samples of the outputs the group will be producing. Also provide a brief overview of why risk management is important.

Step 2: (30 minutes)

Get team members to identify the risks and opportunities on a handful of dimensions — the attached PDF shows the six I used but you may get more mileage by using other dimensions.

First, encourage team members to identify (without scoring, ranking or solving) as many risks as they can about that dimension. Second, ask them to identify opportunities (“good” risks or fortuitous events), for each of the dimensions, that would have a positive impact should they occur. Examples: consolidating teams geographically, forming an enablement team, getting Chief Product Owner to prioritize work requests with stakeholders, etc.

Use different color stickies for risks and opportunities (blue) to visualy set them apart. You don’t need to create the circle (as shown in the PDF), just blue tape to draw the spokes will suffice.

Step 3: (30 minutes min)

Better understand the impact and probability of the risks occuring by visualizing them in a chart. This is where you qualitatively access the impact and probability of the risks.

Step 4: Optional quantitiative analysis

Use basic quantitiative analysis to determine where the next-best dollar should be spent — compare features from the backlog with the risks to mitigate to determine what to do next: build a business feature, or reduce a risk.

Step 5: (30 minutes)

In the Risk Response Planning step decide what to do about the risks the group has identified, ranked and measured.

Inject risk avoidance, mitigation, and opportunity stories into the backlog. Without explicitly adding them into the backlog, you run the risk of the items remaining unaddressed.

Step 6: (30 minutes to create and seed the initial Risk Radar)

Use a Risk Radar to monitor & control the risks throughout the project lifecycle. Hold a weekly meeting with stakeholders, PO, SM, and management to review the risks and determine new steps. When running properly, risks are identified early and addressed before they become issues.

Risks should pop-up at the outer edges of the chart (still a few sprints away). As time passes, risks if left unaddressed move inwards and become immediate when in the inner most rung. You know there is a problem with:
– risk identification if risks just pop-up in the middle quadrant (i.e., urgent right off the bat)
– addressing risks if they continue marching inwards unimpeded

Use color coding to indicate potential severity: green signifies miminal, red severe. Also, use a foam board, if possible, for creating the Risk Radar — it makes it easy to carry to meetings. Leave some space on the right side of the foam board to (1) stack risks that have been accepted but need to be watched, and (2) risks that have been addressed/mitigated.

Note: When coaching a large program with multiple teams, I use an Excel sheet to identify teams and risk areas to focus on. The attached example Team-Risk-Monitor, is based on a conversation with Dennis Stevens from LeadingAgile. In this worksheet, any team scoring 70 or higher on any of the 6 dimensions (Column C through Column H) is flagged for follow-up/monitoring.

Leave a comment

Posted by on October 13, 2015 in Agile


Tags: , ,

Using #DevOps Blueprints instead of Stories

With the DevOps group mentioned in an earlier post, we also decided to not use Agile stories (as a …, I want to …, so that …). Instead we decided to create “blueprints” that we augmented over time. The team took an iterative approach to adding functionality, often starting with a basic blueprint and then writing a new one to build on the functionality of the first one. The blueprints weren’t assigned story points; the team would take on 2-3 blueprints that they thought they could complete in a week — blueprints could take more than a week to implement though it was rare.

For example, the team’s very first blueprint was to build a POC completely manually, which the team was able to demo one week later. For the next demo they built on that by adding automated windows builds. We found that this process lined up well with the concepts of iterative development and progressive elaboration by allowing the team to refine and improve as the business goals themselves became clearer.

Sample blueprints available at Check Point Firewall POC Blueprint and Zenoss Blueprint

Leave a comment

Posted by on September 24, 2015 in Agile


Tags: ,