RSS

Category Archives: Improvements

Can we get out off the Agile weeds?

I’ve been having far too many conversations regarding Agile frameworks, their implementation, and scaling recently. It seems to me that a majority of agile coaches and their clients seem preoccupied with rituals over results and I get the sense that people are too mired in the weeds and losing sight of the few basic things needed for becoming a more nimble and customer centric organization. So, here are some things to ask yourself:

  • Are we truly a customer centric organization? Do we actually get out of the building enough to understand our customers, their needs, their problems, and how they use (and struggle with) our products. Can team members do a “follow-me-home” or some other customer discovery practice – journey maps, customer interviews? Are product teams primarily focused on gaining customer insight in order to better meet their needs? Do we even care about customer delight?
  • Are we open to disrupting ourselves without the motivation of a crisis? Does our culture allow us to preempt crises, without much drama, by reinventing products and services offered or by changing the existing business model? Or are we complacent and reactive and buffeted by what are competitors are doing?
  • Do we have true business and IT partnership? No, I don’t just mean that a PO sits with the team or that there is a Product Manager who ensures that her POs are aligned on the order in which to build the identified features. What I mean is that the business folks and IT have the same goals, the same targets, the same key metrics – and that they together focus on the same desired outcomes (and not just the outputs). Think X-Matrix and OKRs here. Think collaboration (in the true sense of that word) and not just communication, cooperation, or coordination. Think the CIO meeting daily with the Chief Marketing Officer (CMO) to strategize.
  • As a company, are we good at making accurate decisions quickly? Can we get the right information to the right people making the right decisions at the right time? Can we provide the decision makers with relevant and timely feedback about their decisions? And then, do we encourage them to learn from mistakes and improve?
  • Do the IT folks sit together with people from Product, Marketing, UX, Finance, and Operations so that we have true cross-functional product teams? Do these product teams (small, collocated, long-standing, cross-functional) have the autonomy to determine their own best solution to meet the defined goals? Do they have license to experiment and learn? Do senior leaders trust them to do the right thing?
  • Are we providing open collaborative spaces for the collocated product team members? Or are we still struggling with ineffective communication amongst the distributed and/or dispersed team members?
  • Are teams keeping design simple and writing good code? Can they rapidly get feedback by integrating and deploying continuously? Can they release on demand? Do they demonstrate their working product frequently to their stakeholders and to their customers? Yes, inviting real customers to a demo is a good idea.

You’ll notice that these are independent of any agile framework used. You can actually start improving on all of these without even using the term agile. So what’s keeping you from moving off the rituals bandwagon and focusing on what truly matters?

 
Leave a comment

Posted by on November 24, 2017 in Agile, Improvements, leadership

 

Tags: ,

Misplaced Agile Transformation Priorities

Most companies that I’ve worked with begin their lean-agile transformation effort by attempting to fix/improve the development teams. However, the source of most of the problems lies either upstream (lack of sequencing of work, demand far outstripping capacity to do the work, suspect value of work requestsed, etc.) or downstream (lack of environments, wasteful and onerous deployment processes, etc.) of the development teams. And, of course, management struggles in creating an environment that is conducive for high-performing teams is well known and another area for improvement.

A significantly better approach would be to start with introducing the CALMS conceptual framework (culture, automation, lean, measurement and sharing) for driving the integration of development, support, operations and business. Over time, plan and prioritize initiatives and improvement efforts to move each of the CALMS elements forward. Simultaneously, work with the business and with stakeholders to better define and sequence customer-valued increments of functionality.

You have a higher probability of making meaningful improvements and moving the needle on the busniess metrics that matter by changing your starting point. What have your experiences been?

 
1 Comment

Posted by on May 15, 2017 in Agile, Coaching, Improvements, lean

 

Six levels of waste

In a WhatsApp conversation, Charles Protzman, co-author of, “The Lean Practitioner’s Field Book” shared how he categorizes wastes. His words:

We have categorized waste into six different levels:

  1. The first level is obvious waste: low-hanging fruit (or walking on it).
  2. 5S wastes: the easiest wastes to see.
  3. The seven (eight) lean wastes.
  4. Boiled frog waste: the waste that is hard to notice because it is old and we pass by it every day.
  5. Tribal waste or sacred cows: untouchable waste in our culture and systems.
  6. Hidden unseen waste: waste we don’t typically see, as it is hidden behind or masked by other wastes; you really have to hunt for it! The hardest waste to find and yet the most dangerous.

To #3, I would add and emphasize the knowledge work wastes of scatter (lack of focus), hand-off, wishful thinking, reinvention, and lack of system discipline to make the list more relevant to software development.

This is a really good list. What do you think?

 
Leave a comment

Posted by on February 22, 2017 in Improvements

 

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 http://hatech.io/community.html#meetups).

 
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.

 
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: , ,

Andon cord influenced DevOps 20/45 practice

Andon cord or call button influenced 20/45 rule — Problem Swarming

A few years ago, I coached a high-performing DevOps team. This was the company’s first foray into building a more collaborative environment between development (who built embedded software for slot machines) and operations (responsible for ensuring the slot machines worked flawlessly on the casino floor). Additionally, the technology stack was large and new to the company — they had wisely decided to move to a cloud based ecosystem for managing the slot machines and games on those machines remotely without having to send a technician to the casino every time there was a glitch or software needed to be updated. As such, yokotenkai (horizontal/lateral sharing of knowledge, ideas, best practice) was a very important secondary goal.

This group borrowed practices from Lean and adapted them to suit their purpose. One of the practices they made their own was the use of an “andon cord.” An andon cord is a way of signaling a problem (whether real or suspected) and alerting the team that they need help. This team implemented a “20/45” rule — if a team member was stuck for 20 minutes and didn’t have clarity on how to proceed, he was expected to pull the cord, i.e., ask for help. The team (and not just the team leader) would respond immediately and everyone would pitch-in to solve the problem. They had 45 minutes to determine a way forward before going back to whatever else they were working on.

This sounds like a very inefficient practice what with the constant interruptions. However, this turned out to have a number of beneficial side-effects:

  • Whole team attention was brought to bear immediately on a pressing issue.
  • By definition, in-process work is more important than work that hasn’t yet started; consequently, completing what’s in-process trumps new work. This ensured that team members were always focussed on moving existing work items forward.
  • Quality was built-in (team caught problems before they were cemented in place).
  • No one person knew the complete technology stack and experimenting and learning were critical to team success. Consequently, someone not pulling the cord for a week was a red flag. Either the person (1) wasn’t stretching and trying something unfamiliar and uncomfortable, (2) had a fear of being vulnerable and asking for help, or (3) had a tendency to work alone and figure out a solution by himself (wasting significant time, not utilizing the team’s existing skills and brainpower, and often ending up with a suboptimal solution).
  • Everyone’s level of knowledge increased every time the cord was pulled and team brainstormed approaches. Over a two-month period people’s understanding grew by leaps-and-bounds and team members became comfortable with being uncomfortable.
  • The agreed upon way forward was usually better as different perspectives and approaches were considered.
  • Everyone on the team knew what was going on and what challenges they were facing.
  • Team members felt completely empowered to determine the way forward.
  • Team members demonstrated vulnerability by asking for help and loyalty by helping each other complete their work.

It’s now been 2 years since I coached at that company. I recently heard that all Agile teams there are taking this approach — Yokotenkai at it’s finest!

 
Leave a comment

Posted by on September 22, 2015 in Agile, Coaching, Improvements

 

Tags: , ,