RSS

Monthly Archives: September 2015

Simple work priority guidance for #Kanban teams

The following is a very simple suggested order of work for #Kanban teams that has worked for me in the past:

  1. Fix an unhealthy increment (broken build, recently introduced defects, etc.)
  2. Help remove a flag (Block)
  3. Help an existing swarm move their work forward
  4. Refill a queue (if low before the bottleneck) but don’t exceed the WIP Limit
  5. Start a new item. However, if all at limits, join an existing swarm

The guiding principle is to start new work if and only if you cannot contribute to the completion of an item already in-progress.

 
Leave a comment

Posted by on September 28, 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: ,

Our Agile #transformation is struggling without #management support — can’t we just fire them all!

While nothing is easier than to denounce the evildoer, nothing is more difficult than to understand him. ~Fyodor Dostoevsky

A significant number of agile coaches and agile zealots often portray managers as evildoers. But, how often do these agilists:

  • Practice empathy and try to put themselves in the manager’s shoes?
  • Consider the very real fears that managers have to face — fear of looking silly, fear of all their effort over the years coming to nought, fear of being sidelined, fear of taking “unnecessary” risks, fear of not delivering and looking bad?
  • Say what needs to be said without embarrassing, humiliating, or otherwise offending the manager’s self-worth?
  • Make the managers “feel felt?” Not just heard, but also being aware of and demonstrating awareness of how the managers are feeling and the emotions they are grappling with.
  • Take the time to understand what managers want, what they feel, what they struggle with, what they enjoy, what irritates them, what they fear, what pressures they face, …?
  • Realize that managers feel lost in the new world and are asking for help in making the change stick?
  • Suggest approaches that works smoothly and take a load off managers’ shoulders?
  • Spend time 1-on-1 with the managers to guide them in impediment removal and more importantly in creating the right structures of fulfillment?
  • Spend time 1-on-1 with the managers in co-designing a step-by-step approach versus just talking in generalities?

Not very often, I presume. It’s so much easier to point fingers than to consider your own role in exacerbating an “unseemly” situation. So is it any surprise that a potential ally is often turned off by the behavior of the change agents?

 
1 Comment

Posted by on September 22, 2015 in Agile, Coaching

 

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

Why most #agile and #lean #transformation efforts fail

I’ve seen far too many change efforts run into a stone wall and fail to achieve the initial expected results. In simplistic terms, C-level managers who are less than happy with the results they are getting (or not) determine that doing things differently is the right way to obtaining the better results desired. Makes sense logically, but works rarely!

People do the things they do for a reason — their actions are guided by their beliefs that have been formed based on past experiences. For example, I might believe that making mistakes is career limiting because I experienced this firsthand somewhere or saw what happened to a peer who tried to make an improvement and “failed.” Beliefs like this may lead me to value, “avoid risk taking.” Now when you, the Agile proponent, come to me and say, “Alex, I’d like you to experiment and inspect and adapt,” I’m more likely to have a visceral reaction and to write you off. Experimenting might make sense theoretically, but that’s not my perceived reality. And that’s the challenge — asking people to do different things (or things differently) doesn’t work if what you are asking is counter to the person’s existing beliefs and conditioned values.

Successful change happens when the champions of the change attend to the management systems (leaders’ behaviors, expectations, tools, common practices, etc.) and also engineer new experiences that lead to a questioning of the validity of existing beliefs. Sadly, few leaders are good at either.

 
Leave a comment

Posted by on September 16, 2015 in Coaching, Improvements

 

Tags: , ,

Adhering to the iron triangle is not the goal

Most of the managers in the large traditional companies I coach are overly concerned with the project management triangle (aka iron triangle) and its three sides of “scope/functionality”, “time/schedule”, and “cost/budget”. Decision making by-and-large revolves around these three and often the organization sets unrealistic goals for the iron triangle. However, what they fail to realize is that these are only constraints on the delivery of quality product and not the real objectives per se.

Sadly, rarely discussed are the real objectives: providing Value (by releasing product increments frequently) and ensuring Quality (product released is reliable, adaptable, usable).

Finally, the term “scope” is inadequate as well. Scope usually refers to the tangible output produced but leaves the desired and expected “outcomes” and “impacts” unaddressed. Without an understanding of outcomes (finite and measurable objective changes) and longer-term impacts (broader and the longer term effect of an outcome), it is no surprise that organizations get stuck in “featuritis”, the belief that more is better.

To be agile, an organization doesn’t need to just get better at producing stuff but to also pay heed to what is being produced and why. Until this is addressed, agile as mistakenly implemented will continue to disappoint — benefits expected from an agile transformation will fail to materialize.

 
Leave a comment

Posted by on September 15, 2015 in Agile

 

Tags: ,

What does an Agile leader do?

What does an Agile leader do? Set the vision, establish priorties, focus on critical performance drivers, motivate people. Yes, these are important but not the primary responsibility. A good Agile leader creates necessary change to make the product being produced or the service being offered easier, better (safer and higher-quality), faster, and cheaper in that order. The way to move forward and produce different (and better) results is to not mandate new actions but to attend to the required culture changes by altering management systems (leaders’ behaviors, beliefs, expectations, tools, common practices, etc.) and by evaluating existing rules, policies, norms, procedures, and structures for continued relevance.

So, if you are a leader, ask yourself two questions: “Do I know where we are and were we are going?” and “How much time am I spending in creating meaningful change versus managing the status quo?”

 
Leave a comment

Posted by on September 14, 2015 in Agile, Improvements

 

Tags: , ,