RSS

Tag Archives: improvements

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.

 
3 Comments

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

 

Tags: ,

Three things that matter when embarking on an Agile transformation

When it comes to transforming an organization to Agile, it is far too easy to get caught up in the details of implementing a methodology and its associated practices and lose the focus on realizing desired Business value, i.e., to lose sight of what you are trying to achieve and why. The goal of a transformation is never to implement Scrum, or XP, or SAFe, or what have you; rather, the goal is always to get better at achieving the value that matters to the organization. Having well-defined outcomes and a plan for achieving those outcomes is key to keeping the transformation effort on track.

Simply training employees on the mechanics and implementing the recommended practices often does not lead to, nor guarantee, the desired business results. In our experience helping companies transition to Agile at scale, we’ve found that they struggle to achieve desired outcomes when they start out focusing on the “how” and fail to appreciate the “whys” that underlie the practices. These organizations frequently do not understand which bits can be adapted, which can be jettisoned, and which practices and tools could enhance the process. As Al Shalloway, CEO of Net Objectives says, “Practices are designed to solve a problem in a context. When challenges occur, look at the intention of the practice. Then, using principles, look for an alternative to the practice.” To that, I would add, “Finally, make your decision about what to do next, but define your expected outcomes before starting your experiment (or implementing the countermeasure).”

Nearly all organizations want to improve business measures that matter and the best way to do so is to improve flow, quality, and value delivered. When we reduce the principles of Agile and Lean to their essence, we discover that the goal is to focus on, and continuously improve, the effective, efficient, and predictable delivery of customer value — development teams strive to delivery more-and-more value with minimal waste; managers in turn seek to create an environment of dependable, unimpeded, measurable flow. Success, therefore, requires a focus on three critical aspects: flow, quality, value. These are not one-time improvements, but a never-ending series of small improvements.

1. Focus on: Flow and Predictability

Flow is the regular, never-ceasing, forward progress of products, services, and information to the customer, who might be an external client or user or an internal stakeholder. It is work moving from one step to the next, within the value stream, without delay or rework. Improving flow often involves removing roadblocks that delay or prevent the continual forward motion and throughput of work.

Closely related to flow is predictability. 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. However, before worrying about predictability, you first need to ensure that there is complete transparency and visibility so that managers and team members can see what is really happening in order to make informed decisions.

Without visibility, it is nearly impossible to make and keep commitments with any degree of certainty. Attempts to improve flow simply become shots in the dark and it is not possible to see and evaluate the effects.

The last aspect of flow is the notion that people are engaged and productive when there is a match between their skills and the complexity of work required — lack of required skills can lead to fear and stress; mundane work to ennui. Self-organizing teams should keep this in mind when allocating or self-selecting items to work on.

2. Focus on: Quality

Quality is assessed by the customer. By definition, the quality of a product or service is the degree to which a set of inherent characteristics fulfill a need or expectation that is clearly stated, generally implied, or obligatory. It is more than simply being free of defects. Quality involves meeting customer expectations. And yes, some of these expectations can be subjective. Interestingly, performing higher does not necessarily mean higher quality if the buyer balks at buying the unasked for add-on functionality.

It is a common misconception to believe that you have to proceed slowly in order to produce quality work. But, speed and quality are not dichotomous options and they should go hand-in-hand — you can get better quality and a higher rate of work completion. Companies that invest in automation and in preventing defects (vs. finding them at the end of the development cycle) find that quality does not have to be compromised for speed. Quality affects flow. When work is not done right the first time, when quality is not built into the process (vs. checking for defects after the fact), and when the product or service does not meet the customer’s need, we end up with rework and defects that have to be addressed. This unanticipated rework makes it harder to be predictable, impedes flow, and delays completion of work. Speed and quality are not mutually exclusive.

3. Focus on: Value

Value can be a fuzzy concept. It can be viewed from different perspectives: customer, business/organizational, operational, and individual and each will have likely have a different understanding of value. Imagine how each perspective might think about a “pizza delivery business.”

  • A pizza maker competing with other pizza makers for a single job at a local pizza store
  • The manager of the pizza shop
  • The owner of the pizza shop to whom the manager reports daily or weekly
  • The customer who ordered a couple of pizzas to be delivered to her home

What is perceived to be “value” by one role may not be by another.

Some companies make the mistake of losing sight of who they are building the product or service for — delivering business/organizational value is important but being uninformed about what customers’ value is extremely dangerous. To complicate matters, value is not constant — things can become more or less valuable over time depending on the circumstance.

Once you’ve agreed on what value means and who is being provided that value, you need to define the minimal cohesive increments of functionality that together will meet the needs of the target customer by either solving a problem she has or by making her work easier, better, or faster. To do this, you have to take the time to understand your customers and stakeholders, their problems, their needs, their actual usage of the product or service. This practice of customer discovery is deceptively simple: form hypotheses about the product, about the problem that your product solves, and test these hypotheses with those who could be your potential customers to verify, iterate or exit. An “I already know what customers want” attitude, based on their perception of market opportunity, is a good indicator of failure. Additionally, you need to verify or refute your product’s value proposition, its sales roadmap, business model, etc. After all, you don’t want to develop something if it isn’t worth it to your enterprise.

Lastly, defining a clear value metric across all the portfolio of work being considered makes it possible to sequence the order of implementation of the minimal cohesive increments based on Cost of Delay or another mechanism.

 
2 Comments

Posted by on February 8, 2017 in Agile, Improvements

 

Tags: , ,

Essence of Agility

Kristi (a ScrumMaster at my current client) and I were discussing the state of her Agile teams and we started sketching a framework for our discussions — the seeds of this framework were planted by Sandi Keller and Andrew Fuqua (@andrewmfuqua) in numerous conversations earlier this year. We started with the basic aspects that allow companies to “ship frequently and reflect regularly” — a clear, well-defined, and prioritized backlog; a self-organizing team that produces and delivers product every Sprint; and engaged customers willing and able to accept the product iterations and to provide feedback to the product team.

As we started delving into each of the aspects, we fleshed out additional attributes for each. For example, certain things have to be in place before we can get to a well defined backlog. These might be a Product Owner (or a PO team that speaks with one voice) who spends time with the customers to understand their pains and needs, a PO who can articulate his (or her) vision of the product, a PO who can work with the stakeholders in prioritizing their needs, a PO who can translate these diverse needs into something that teams can work with, and finally a PO who can collaborate with the team and articulate her vision, the customer and stakeholder needs, and the underlying rationale.

Essence-of-Agility

A meaningful discussion was more than sufficient for Kristi and I to determine the next few areas to improve on and we didn’t even have to refer to the assessment that my current client has been using.

This basic framework was enhanced during additional discussions with other ScrumMasters. I’m not going to regurgitate what’s already in the sketch but would be happy to clarify any areas that aren’t clear. Additionally, I would be interested in other simple frameworks you find useful.

 
Leave a comment

Posted by on December 1, 2014 in Agile, Improvements

 

Tags: , ,

Objectivity can be easily destroyed

The known facts of a situation can be easily overshadowed by feelings, opinions, guesses, fears, concerns, prejudices, hopes, expectations, beliefs, interpretations, assumptions, and myths. That’s a lot to fight against and is it any wonder that so few decisions made are based on facts — facts that match objective reality, are independently verifiable, and are backed up with evidence.

As an example, a previous client was ready to initiate a couple of expensive projects to rectify perceived shortcomings in their level of service. We started an A3 for each problem and it quickly became obvious that there were no real (supported by facts) shortcomings/problems to solve. One of those projects was meant to address the perceived slowness in providing daily prices for foreign bonds. The pervasive feeling, within the company, was that they were always the last ones to provide prices while their industry peers were a few hours faster. Facts told a different story — the client was usually in the middle of the pack and once in a while was the last one, but only when there was a special unforeseen event in a particular foreign market (a market that this company specialized in).

My advice to them, “Don’t bother trying to provide prices faster as there is no benefit in doing so. However, if you really want to improve how you approach work take a look at why you spot check calculations and prices 4 times within your process while your peers do so only once (if at all). Multiple checks don’t buy you anything; instead, you waste time and resources that could be utilized elsewhere. Most likely you are doing this because your company culture is extremely risk-averse; however, the risk is an imagined risk.”

I ended up losing some potential billing time but received great satisfaction by preventing the client from wasting a lost of time, effort, and money — I think this exchange was ultimately in my favor.

 
Leave a comment

Posted by on October 14, 2014 in Improvements

 

Tags:

Management’s #1 Responsibility — Remove Roadblocks That Hinder Achievement

Most employees want to accomplish the objectives in front of them, but they often run into what they perceive to be a never-ending series of roadblocks. And frequently these impediments are beyond their ability to fix (based on where they are in the organizational hierarchy).

A few changes at the start of an agile transformation can go a long way:

  • Managers, in an Agile environment, should promptly setup an obstacle escalation process and a mechanism for visualizing the obstacles. In addition, managers should strongly encourage every member of the organization to surface problems affecting the execution of work and the delivery of product.
  • Obstacles, if not readily raised by team members, can be gleaned from the end-of-sprint retrospectives, from failure to meet the Definition of Done, and from interactions with the teams.
  • An obstacle board can be used to track anything that is slowing the team down and is used within an obstacle resolution process.
  • The ScrumMaster in her servant role should do everything possible to remove impediments slowing her teams. She is accountable for making impediments visible throughout the organization via the obstacle board.

At a previous client we instituted a process wherein, an obstacle identified by the team would go on the team obstacle board. If the team and ScrumMaster couldn’t take care of the obstacle within 2-3 days the visibility of the obstacle would get escalated from the team, to the immediate managers, then to the senior managers and directors, and finally to the Vice Presidents. Obstacle status was displayed on large video screens throughout the campus. At each escalation stage, if the obstacle was not resolved or if a workaround was not found within 2-days, the ScrumMaster would move the obstacle up to the next higher level board. The ScrumMaster did not own the obstacles; managers did and they agreed on ownership of the obstacles amongst themselves.

Quick escalations ensured that people higher up in the organization were aware of issues the teams were struggling with and had an incentive to remove the roadblocks quickly. Obstacles would only be considered “resolved” when the ScrumMaster and the team accepted them; nobody else could remove an obstacle from any of the boards. Some obstacles were impossible to fix in a few days — for these, people higher up in the organization were accountable for explaining to the team why the obstacle couldn’t be solved now, what they were doing about it, and by when they expected closure on the item. For obstacles that management could not solve or help with and for which the team itself was best placed to solve the problem, the obstacle would be returned to the team. Even though management was unable to fix the issue they were now aware that a problem existed and could help the team with resources, etc.

This simple process increased visibility dramatically and team members realized very quickly that they did not have to live with the dysfunctional status-quo — team morale improved as did the sense of empowerment. Company leadership also realized that they had a crucial role to play by removing roadblocks and they didn’t feel left out as most do when switching to a poorly run agile transformation.

 
Leave a comment

Posted by on October 6, 2014 in Agile, Improvements

 

Tags: ,

What is the problem you are trying to solve?

I had an interesting initial conversation with a couple of IT Directors this morning. One of their questions stood out for me: “Our teams aren’t meeting their commitments. What should we do to fix the teams?”

My first internal reaction was, “You don’t need to do a thing to ‘fix’ the teams.” My issue with questions of this ilk are:

  1. Why do managers assume the problem is with the team or teams? Remember, half-a-century ago, Deming pointed out that 95% of the problems are systemic problems. And guess who is responsible for the system?
  2. It’s easier to blame others than to take the time to reflect and introspect about how we ourselves are creating the conditions for these problems to come into being — problems we then keep complaining about.
  3. Why do managers (and team members as well) not spend a few minutes thinking about what the problem really is — the root cause and not just the manifestation — before leaping to conclusions?

In this case, there are numerous things that could be keeping the teams from meeting their commitments — lack of skills, lack of appropriate training, over specialization, silos, handoffs, interference from without within the sprint, pressure to commit to more than appropriate, changing priorities, lack of alignment with other groups these teams may be dependent on, technical debt, dearth of testers, large batches with little flow — stories being delivered towards the end of the sprint, large stories, unclear stories, unnecessary steps, non-value add activities imposed on the teams, delays and waiting, and so on and so forth. Without understanding what is actually causing the problem, it’s very likely that you’ll end up solving the wrong thing; thereby, creating even bigger problems.

I use a simple diagram to clarify the issue and teach techniques like 5 Whys, Diagram of Effects, ToC Thinking Tools (especially the CRT), etc. to help teams and managers understand problems and fix root causes so the problem goes away once and for all.

Analyzing a Problem

Analyzing a Problem

How do you handle such situations? Do you have favorite techniques and tools you use? And how much time do you spend teaching problem definition and problem solving techniques?

 
Leave a comment

Posted by on August 20, 2014 in Agile, Improvements

 

Tags: , ,

Inside-out vs. Outside-in approaches to improvements

Inside Out — The usual approach is to look at our existing problems (usually operational) and solve them or to look at the existing processes and change them to make them better, faster safer, or cheaper, in order to better serve customer needs. However, the link between the problem being solved, the proposed solution, and the customer need is frequently tenuous and usually based on unshared, unexamined, unproved assumptions. More often than not, the time and effort expended does not justify the eventual outcome.

Outside In — Start with the customer’s goals, determine what capabilities we need to meet those goals, and then what actions we need to take to build those capabilities. Actions could be changes in leadership styles, process modifications, or changes in organizational structures, rules, policies, norms, etc. This works really well for organizational transformations. For product development, techniques that can be useful are Gojko Adzic’s Impact Mapping and Tom and Kai Gilb’s Stakeholder Value & Product Quality Requirements defined in Evolutionary Project Management.

 
Leave a comment

Posted by on August 10, 2014 in Improvements

 

Tags: ,