Wednesday, March 21, 2018

What does Lean offer IT?


Lean is inherently agile. But more importantly, the Lean leadership model is desperately needed by IT organizations. Lean is by definition a thinking system that applies to all levels of management and work, and goes beyond simple team-level agility. Software is, of course, fundamentally all about thinking. Most importantly, Lean emphasizes value over ceremony, and cuts the waste out of one-size-fits-all frameworks and scaling mechanisms.


Lean focuses on value over ceremony

The Lean motto is “Perfect value from a perfect process with zero waste”. Lean expects you to constantly think about why you are doing whatever you are doing. With every activity we ask, “what is the value to the customer in this?” With every activity we ask, “is this the best way to do this? The easiest?” With every activity we ask “are we learning something from this?”

Regularly cadenced activities occur because they are useful for the team in their pursuit of value, to improve their work, or to learn.

Lean is based on the scientific method

400 years ago, Francis Bacon wrote Novum Organum and the Scientific Age began. The idea that we could observe nature, collect data, form hypotheses, conduct experiments, examine the results of those experiments, and then repeat based on what we found out, changed the world. Lean builds on that legacy of discovery and improvement.

The first thing a team or organization does when they begin to adopt Lean is create a Visual Management System (VMS). (I always recommend starting with a physical system if at all possible) In other words, observe nature - the system of work as it is. We then conduct experiments (e.g., Plan, Do, Check, Act) to try to improve. Based on the results of those experiments, we modify how we work, conduct additional experiments, etc.

For IT, getting the work “out in the open” is critical to measuring the work process, identifying bottlenecks, revealing waste, determining priorities, instilling a sense of urgency, and eliminating magical thinking.

Andon Cord and Jidoka

Bugs. Defects. The perennial plague of IT and software. Lean inverts the traditional attitude towards mistakes and problems. A Lean Leader wants to hear about problems (Jidoka). We want to “stop the line” (pull the Andon cord) and address the underlying problem whenever anyone has a question or is unsure of anything about the work process or environment.

Jidoka encourages team members to raise any issue, any time, and considers “no problem” to be a serious problem. “No problem” means people aren’t asking questions, or are making too many assumptions, or are simply guessing. 

We would much rather stop now and address the issue – even a false alarm – than deal with a failure in production.

One-Piece Flow, Best Practices, Cross-Functional Teams

The Lean concept of “one-piece flow” is extremely helpful for IT teams, especially early on in team formation. “One-Piece Flow” means the whole team works together on one work item from beginning to end. This provides a number of benefits:
  • ·         Everyone learns the standard way of work, and expected best practices
  • ·         Everyone learns how to work with each other
  • ·         Everyone learns what everyone else contributes to the work
  • ·         Everyone learns something about how to do each other’s’ work (implicit cross-training)
  • ·         Everyone learns pairing and swarming behaviors
  • ·         The team can collectively look for waste and how to improve the work process
  • ·         “Work in Progress” limits are never a concern
  • ·         Any delay is immediately visible (“pain is a signal that a fix is needed”)

Gemba Kaizen and the Only Job Management Has

The team’s Visual Management System is their Gemba, their place of work. Lean teaches management to “go and see”: go to the place of the work, don’t make the team write up “status” or the unholy “Red, Yellow, Green” reports.

An effective VMS shows the entirety of the work, warts and all. The Lean Manager can see where blocks and problems are for the team, and can immediately address them. There are usually issues beyond the team’s control, that only management can solve. 

In addition, there are often “over the horizon” things the manager knows (based on their experience, organizational knowledge, overall strategic intent, etc) that can be brought to bear to help the team.

This attitude is the Lean model of management known as “Gemba Kaizen”: the only job of management is to make it easier for the worker to deliver value.

Most important thing for the team to finish today

Finally, perhaps the most valuable thing Lean offers IT is the ability to establish a Sense of Urgency. For a Lean IT team there is only one question to be addressed at their daily synchronization meeting (“stand up”): What is the most important thing for the team to finish today? The team does not need to discuss status, or whether they had ice cream for breakfast. All that information is seen on the VMS. This mantra focuses on the team dynamic, not individual contribution. And most importantly, finishing. Immediately. Right now.

This is the practice of “walking the board”. Looking at the VMS, what work item is at the finish line (that we can now finish)? What can be moved to the finish line? Etc.

Lean is Harder

Lean is harder than other “agile” methods because management can not wash their hands and tell teams, “Go and be Lean”. The House of Lean is fractal and recursive, applying to management and leadership more than delivery teams themselves. It is not something that “those people” do by following some “off the shelf” or “one size fits all” framework. But the very reason it is hard – that everyone must think – is what drives its benefits.

Thursday, February 8, 2018

Physical and Electronic Visual Management Systems

The most powerful tool in the Lean arsenal is visibility. The more that the elements of work are visible, and the greater degree of visibility, the more opportunities the team and your organization will have to improve. If you can see it, then you can fix it.

Physical or Electronic?

Should you seek a physical or an electronic visual management system? 
IT people usually start by seeking a technological solution. Visual management then means using an electronic tool, or sometimes a spreadsheet, that gives a glimpse of the work through a small screen. Consideration of the work means scrolling up and down, back and forth, clicking, expanding and collapsing.
There are often very good reasons for this. Perhaps the team is geographically distributed. People often work from home. Corporate governance mandates use of a tool. etc.
So why would you want a physical system?

Advantages of a Physical System

  1. Makes tangible the “extent” (“distance”) of the work from beginning to end ("walking the board" literally means walking the board)
  2. Articulates the types and categories of work - and challenges your understanding of them
  3. It is trivial to update, expand, change, rework or add to
  4. Articulates priorities of work - e.g., physically higher/lower, colors
  5. You can use anything to augment your physical display. Tape, stickies, stickers, yarn, . . . anything from the craft store
  6. Externalizes interactions about the work
  7. Externalizes assumptions about the work
  8. You can include diagrams, charts, graphs, checklists, etc and place them anywhere 
  9. Exposes any “off the books” work
  10. Exposes any "assumed" work
  11. Facilitates shared understanding of the work and how it creates value
  12. Facilitates congruence on what the work is
  13. Anyone can annotate anything
  14. Articulates current best practices - and makes them changeable
  15. Provides bandwidth for communication about the work 
  16. Provides a “process focus”
  17. Progress is tangible - you touch and move items on the display
  18. Provides a forensic Value/Waste evaluation tool
  19. Externalizes any “blame” – the process is  “at fault” 
  20. Supports data collection for fact-based estimates
  21. Makes work-in-progress visible
  22. Makes delays visible - "at a glance" what has changed from yesterday? What has not?
  23. Easy identification of what is “almost done” - near the end
  24. Identifies process steps where slowdowns occur
  25. Fosters a sense of urgency as “winning” becomes obvious
  26. Provides visibility to the work for management and stakeholders - they can "go and see"
  27. Shows the impact of “injects” (what happens when the firetruck enters traffic?)
  28. Makes policies visible (e.g., "emergency", “done”, “escalation”, etc)
  29. Makes work state transition criteria (“stepwise definition of done”) visible
  30. Eliminates the need for "status reports"

But the most important is its use as a vehicle for change and improvement, via experimentation.

The biggest difference between a physical display and an electronic one is the sense of “finality” that comes from the electronic. The electronic "solves" the problem of what your work is. You are "done" with thinking about your work, how it drives value, and what might be something better.

Remember with Lean to never assume you've "solved" the problem. You've just implemented a counter-measure.

With an electronic display it is hard (impossible) to make wholesale changes or even incremental additions. The tool won't allow it. Current artifacts in the tool won't fit or transition to the new model. You’ll need to retrain everyone. You need “admin” privileges. Or the dreaded “that violates corporate governance guidelines”. 
But the worst is the loss of the sense of “play” you have with the physical board. An electronic system is solemn. It must be obeyed and can not be challenged.

If you are currently using an electronic system


  • When is the last time you completely reworked your visual management system? Split out different types or categories? Changed the sequence of activities? Split up activities?
  • When was the last time you identified a best practice? Challenged a best practice?
  • Is your visual management system only "kanban"? Is your kanban "To do", "Doing", "Done"? (I.e., is it a grocery list?)
  • Does your system give the team a way to think about the work while the work is underway? 
  • Does it give a way to think about the effectiveness of the work in relation to the value you are trying to achieve?
  • Does it provide a way to review in detail the work done?

Thinking about the work is hard

How is the Value created? How does the team work together? What happens first? At the end? What must happen? Cannot happen? Until? While? Before? Unless?
Are you getting what you actually expected? Is each cognitive step worth it? Is there a better way?
Not only are these questions difficult, but too many teams (and managers) feel answering them takes time away from actually doing the work.

Having a physical display lowers the effort needed to change the visual management system. Given how easy it is to change, experimentation becomes the norm.

This in turn makes it easier to think about the work, and change (experiment on) the work.

If at all possible, even for geographically distributed teams, gather on a regular basis and thrash out the work in a physical, tangible way. Challenge a distributed team to identify, invent and use multiple channels of communication to leverage the benefits of a visual management system - physical if possible.

Wednesday, August 2, 2017

Procrustes the Scrum Master

Procrustes of Greek myth was an innkeeper with a curious proposition: he would give you a free night at his inn, but there was a special bed you had to be fitted into in order to sleep. As you lay in the bed, if you were too short, your legs were pulled out of their sockets to make you long enough to fill the bed exactly, and if you were too tall your legs were chopped off. Rumor has it Procrustes went on to a successful career as a Scrum Master, where his skill was put to use during sprint planning.

Scrum is a good start

Scrum is a great start for teams that have been mired in Waterfall. It helps get them to start thinking of smaller batch sizes – weeks instead of years. Ceremonies such as Sprint Retrospective help establish the idea of continuous improvement.

Scrum was also useful back when introducing Agile into an anti-agile organization. It provided a set of well-defined events, schedules, activities and roles that appealed to line supervisors coming from a project management background. It also fostered an “us versus them” mentality (“Scrum Master leads and coaches organization in its Scrum adoption”) that is not really necessary now that most (all) agile adoption initiatives are top down.

Teams that depend on Ceremonial Scrum often run into issues. Having regularly scheduled ceremonies implicitly tells the team to wait until the next occurrence before doing anything. An example is the sprint retrospective. An issue or need for improvement from the first days of the sprint lingers until the retrospective occurs.

How do you deal with “leftovers” (stories started but not finished) at the end of a sprint? Do you take velocity “credit” for them? Do you stop work? Do you need to resize them? Put them back on the backlog? How much velocity credit do you take? What if a team takes on a “stretch” story and fails to finish it? How does that “count” on velocity? What about infrastructure work that takes longer than a single sprint?

When a team makes a “commitment” to a certain number of story points, what does it mean if they come in above or below? What is the difference between that “commitment” and a numerical quota? How does management “hold teams accountable” to their quota? Is there any likelihood that teams will game story sizing to make their numbers? What does management do to a team that “commits” to just one point?

Where’s the value?

More importantly, what is the value to the customer of the team spending time trying to figure this out?

Imagine you are part of a team racing Formula One, and every ten minutes you are told to stop (wherever you are on the track) and estimate how many laps, what kind of lap and against which other drivers, you will complete in the next 10 minutes. It must be exact! You are going to “commit” to it!

You have to estimate based on the risk of dealing with which other drivers in which laps where on the track. Uncertainty about weather. Doubt about how well your pit crew works.

You’ll then estimate using a Fibonacci number, derived by the team using a consensus mechanism like Planning Poker. “I voted 13 because Mario Andretti in the hairpin with new tires”. The team then “commits” to completing that many “story points” of laps based on what lap stories of previous sizes were completed in previous 10-minute chunks.

Then during the next 10-minute span of time (or, let’s call it, “sprint”) the driver knows to slow down if they would exceed the quota, or drive recklessly if they are behind. Because after all, meeting numerical quotas are more important than quality. Procrustes would be proud. Deming would not. (See his rule #11).

Maybe just try to win the race

What if, instead of spending all those brain cycles on getting the estimate right, and making commitments, your team just tried to win the race? You remember, just deliver value? The team would have no need to “game” the estimates.

What to do instead?

You could use an emergent metric, such as how many laps you actually you completed in the last ten minutes. Don’t worry about partial laps, only count those that actually completed. You could focus on finishing. If you are part-way thru a lap, finish it then start the next one. You could pay attention to improving your process, and stop managing to quotas.

Friday, July 7, 2017

Lean Standup and Kaizen

“Kanban is not clever workflow management. It is a tool for Kaizen – a device to reveal problems and lead people to think more deeply about their work”                                                                                                                                 --- Taiichi Ohno

Learning effective use of the Kanban board for Kaizen during standup is a key part of a team’s successful transition to Lean.

Often the biggest (and most valuable) cultural changes with the move to Lean is creating a Sense of Urgency. The focus is today: What can we finish today? What is the most important thing to work on today?

The team should “get annoyed” at any work item that is not moving. What’s on the goal line? Why can’t we get it into the end zone? Why do we have so many items in the Red Zone?

Per Ohno-san, use the board daily for improvement questions such as:
  • How do we work now? Does the board reflect that? Do we agree? Could we say we have a “standard” process?
  • What is the work for the team to do? Does the board show our status? (e.g., someone returning from holiday knows exactly what to do next) Do we all agree? Is there a better way to show/communicate the work?
  • What improvement experiments are underway? Are there quality issues? Who has a better way to do this? What is bugging me about this?
  • What “non-value-add” activities are distracting the team? (Visible to management during their Gemba Walk)
  • Can we “walk the board”?

Explicitly schedule daily kaizen, or make it the focus of the standup until it becomes a habit.

Improvement Needed


If your board consist of “To Do”, “Doing” and “Done”, then you do not have a Kanban board, you have a grocery list. This is usually a sign of a team that doesn’t work together or hasn’t worked together previously. Getting to a more rigorous specification of your work should be your team’s first order of business.

Thursday, April 13, 2017

Beyond Cargo Cult Agile

Many organizations trying to become “agile” never get beyond the imitation and ceremony stage. They go through the motions hoping that following the forms will give them the results they want. 

They don’t go beyond the forms to think about why certain practices are recommended, and how to apply them to this team, or how to improve on those standard practices. 

It is a rare organization that looks at the leadership behaviors and management systems that drive unhelpful team attitudes. 

And most large IT companies often have a “playbook” or an “Agile SDLC” document. Rather than being a map to help teams explore, corporate culture makes it a straitjacket that must be followed exactly.


For Example, the Stand Up meeting


One example is the Daily Stand Up, or Daily Scrum. Each team member answers the three questions: Oh sorry, wrong three questions. Those might actually be useful. 

Rather, teams are supposed to answer, what did you do yesterday? What are you going to do today? What impediments do you have? 

This often devolves into the “ice cream for breakfast” meeting. Everyone just thinks of the most recent thing they did (that they can remember) and talks about that.

Why?


Some of it is the Memento Effect

A major culprit is the insidious Timesheet Culture: Accounting has invaded development and wants to know “utilization” – people have to “estimate hours” for a task, then “track hours” and then “re-estimate hours” if there is still work left to do. 

The Timesheet Culture demands individual silos of work and prevents any kind of pairing or swarming

The standup becomes a "gotcha" to invent a rationalization for “why did you charge 8 hours to this project” (Accounting has not allowed the Scrum Master to make an effective transition from being a Project Manager). 

And then there is the dreaded “assigning work”, where team members have little or no choice in what to work on.

But the underlying reason is that the stand up as it is has no value, it just another “ceremony” the team has to endure. 

Is there anything more boring than a status report?


How to fix it


The first question I ask teams is, what is the purpose of your Information Radiators? 

Shouldn’t an Information Radiator radiate maybe, I don’t know, information? 

How about if that information reflected the changes in status due to the work you did? 
What if the radiator was structured so that “at a glance” it was obvious what is different today from yesterday? 
What if everyone updated the Information Radiator as the work progressed? 
And what if part of the team working agreement was to look at the Information Radiator before the stand up? 

In other words, what if before the meeting everyone already knew what the status of work was?

Then let’s change the stand up to make it meaningful to the team:
  1. What did you learn about the work yesterday? 
  2. What did you learn about how to do the work? 
  3. What did you learn about ways the team can improve?

(“Learn” includes raising questions about standards, processes, as well as the work)

Or better yet, use the time to consider the work as a team:
  1. What is the most important thing for the team to work on today? 
  2. What is the key improvement the team should work on today? 
  3. What does the team need to learn today?

Or perhaps:
  1. What process needs to be improved? 
  2. Where is quality at risk? 
  3. What experiments should the team conduct to explore improvements or mitigate quality risks?

You may recognize these ideas from Lean: Focus on the process and getting value to the customer as a team – eliminating waste and improving flow.

Saturday, September 12, 2015

Capacity, Tasks and Hours

Stop thinking of capacity in terms of hours. Stop estimating task duration in hours. Stop planning sprints to achieve “full personnel utilization” (again in hours). Such thinking is a holdover from the steam-engine era project management mindset, when people needed to be told what to do and when to do it. It is not how Agile teams work.

What is Capacity for Agile Teams?

“Capacity” for Agile teams is their velocity (in relatively-sized story points) for Scrum teams, or their throughput (from cycle time) for Kanban teams. Both are measures of accomplished work output. That is, they indicate how quickly the team can deliver value. More importantly, each is an emergent measurement.

Emergent Measures

An Emergent Measure is one that is derived from facts. It is not based on plans, wishes, “percentage completes”, mandatory overtime, assigned work, or pounding shoes on tables. It comes from historical data. It comes from an honest acknowledgement of reality as it is.

An emergent measure emerges from accumulated data. It has statistical variation based on history. A scrum master’s concern is first to provide space and time for the team to get variance under control, and then to improve.

Capacity is derived from Working Software

The agile principle of “working software” is seen every day during the team’s standup, when each team member describes the work they completed. This is most easily done in terms of the tasks they have done. No customer cares how many hours were spent on a task. They only care if something was done or not. Do not waste time updating “hours spent” and “hours remaining”. That is no better than waterfall’s “percentage complete”. The only thing that matters is what is actually complete.

The Yoda Rule
This leads to the "Yoda Rule". By planning and communicating in terms of tasks to do and tasks done, the team thinks at a level above “how long” something will take and instead focuses on why it might take that long – because of the tasks that need to be accomplished.

If a story is blocked – tasks are not completing in a day – “hours left” means nothing. It does not communicate anything to team members who might swarm to help. The first question they will ask is “what needs to be done”?

Use Tasks in Sprint Planning

During Sprint Planning, stories should be broken down into less-than-a-day-long tasks. New teams will have to learn what this means. Experienced teams know the cultural norm: A task is what your peers won’t laugh at when you report completing it at the next stand up. (A legitimate accomplishment to describe at standup is the discovery of additional tasks that must be completed).

This will give a task count. Throw away your hours-based burndown chart and use a task-based burndown instead. This has the added advantage of making conversations with the Product Owner more meaningful. Instead of saying “we have 100 hours left”, you say “we have to do X, we have to do Y, etc”, giving the Product Owner a chance to say whether they really intended you to do X or Y.

Use of Hours is a Cognitive Fallacy

Humans are linguistic creatures. Humans are semantic creatures. Humans do not communicate well, if at all, in numbers. Humans do not think in numbers. That is why we use stories to describe the work to do. Humans do ok with relative comparisons (hotter/colder, bigger/smaller). Humans do ok with relative time (longer/shorter, before/after).

Using the semantics of task description to communicate work leverages humanity’s 50,000 years of storytelling experience. The tasks of the stories in a sprint form a narrative for the sprint. This narrative should make sense to the team.

Planning in hours is “magical thinking”

If you are an executive, a manager or a scrum master who thinks you need to see hours you are engaging in magical thinking. You have an Illusion of Control – that if a task is estimated to take X hours it will actually be done in X hours. The reality is, until it is finished it is not done. That’s it. Simplistic, but easy to understand. Don’t waste the team’s time overthinking this.

This illusion is hard to give up. 

But it up you must give, as Yoda might say. 

Thursday, November 14, 2013

For Your Convenience (or, why your hatred of Microsoft burns with the fire of a thousand exploding stars)

You notice it first when you open any of the Microsoft Office 2013 products. A flat, white, featureless expanse greets you. A harbinger of experience to come.

As you attempt to use familiar products, you find things missing. Maybe my feature is no longer the default, and I have to explicitly enable it, you naively think. After a few hours of scouring support sites and hapless google searches you find a post from a support person who explains that your feature is no longer available at all. Not even as an option. 

Why, you ask? For your convenience, is the answer.

In Word, there used to be an excellent right-menu feature applicable to misspelled words: Add to Autocorrect. If there was a word you consistently fumble-fingered, you could right-click on it and, with Add to Autocorrect, never have to worry about misspelling it ever again.

But with Word 2013, this handy feature was removed. It is not available as an option. It is not available as an extension. It is not available as an "app" from the "Office App Store". It is an ex-feature.

What is Microsoft's reason for doing this? "It was too confusing to have so many choices available on the right-menu". Really?? "Too confusing" to be able to do what you want to do??

If you ask them why this feature was removed, they will respond:

We recommend you submit feedback about the requirement to our product team. Many features of current programs were designed and upgraded based on customers’ feedback.

Today I ran into a similar dead feature in Office 365 Outlook Web App (OWA). I always use OWA if I need to have an in-house client email address. It keeps things clean and separate. OWA gradually improved over the years, reaching a pinnacle in 2011 with an interface effectively indistinguishable from the installed Outlook client.

But Office 365 Outlook has changed that. Email message display no longer has a toolbar where you can click an arrow for "next message". No longer can you move a message to a subfolder.

And no longer can you add a specific date/time reminder to the email. Think of it. A feature of email that has been around since the dawn of time has been removed, "for your convenience".

You can set a reminder on an email to be reminded "today" or "tomorrow" or "next week" whatever that means. But if the email is pertinent to something that needs to happen 8am Monday? Nope. Can't do that anymore.

What is Microsoft's recommendation if you want to set a specific date/time reminder? Do they have a work-around, perhaps? Maybe an app from the "Office App Store"?

Jason Jiang of Microsoft Support helpfully suggests:

We recommend you submit feedback about the requirement to our product team. Many features of current programs were designed and upgraded based on customers’ feedback.

Thanks, Jason. Really appreciate that helpful response.