Intrapreneur Canvas

An internally focused exploration of an idea is different from an externally focused one. In my experience, noticeable differences have been related to market, revenue, customer etc. F.ex, relatively small potential improvements in work within main value streams could clearly dwarf size of investments, or have been considered already.

Anyway, here’s a kind of intranpreneur canvas that’s been useful for me a few times lately when thinking about building new software.

Daily Meeting Checklist

Are work boards updated?

– at least regarding your own work
– “No“? let’s take a look

Are there any issues, problems?

– “Yes“? let’s talk about it…

Can you answer “what’s next”?

– (for you)
– at least until next daily meeting
– “No“? let’s take a look…

  • Can you join existing planned, started work?
  • No? Can you help with any bottleneck, problem?
  • No?
    • A bit much work in progress?
      => Do some improvement work
    • Lastly: consider starting new planned work

Remember:

Lean Decision Filter

“What should I work on next?”

Yuval Yeret quotes David Anderson:

  • Value trumps Flow – Expedite at the expense of flow to maximize value
  • Flow trumps Waste Elimination – Increase WIP (work in progress) if required to maintain flow even though it will add waste
  • Eliminate waste to improve efficiency – Do not pursue economy of scale

See also Al Shalloway on Lean thinking about waste in software development – it’s not about optimizing and reducing the use of “resources” (to quote a tweet by @drunkcod).

 

Slack is Unplanned Improvement Work

Full utilization cause delays - http://agileconsulting.blogspot.no/2011/07/explaining-why-limiting-wip-is-so.html
Full utilization is not effective, not efficient, and causes delays

Being busy all the time is bad for you, your team, and your organization.  It is far better to allow for slack, which is not a bad thing, but creates opportunities for improvement without needing to schedule them.

“Recipe” for what to work on next, incorporating slack:

  1. Can you help progress existing planned, started work?
    Work on that.
  2. Can’t do that?
    Find bottleneck and help work to release it.
  3. Can’t do that either?
    Do some (improvement) work which

    • won’t create any work downstream,
    • will improve future throughput, and
    • can be paused as soon as existing kanban related work is available.

A bit more reading related to slack.

#techsafety

At LKNA13 in Chicago this year I listened to @JoshuaKerievsky talk about #techsafety.

He made me think about quite a few aspects of safety and injuries for a programmer. Here’s a few quotes and elements:

  • safety on team (ref own dev competence)
  • «working with CVS is hurting my soul.»
  • safe from uncertain work situation
  • safe to deploy – bugs, crash
  • safe from pressure – politics, policies
  • Emotional Injuries: Schedule Stress, Lost Respect, Fear of Failure, Torn Trust, etc

What’s interesting is his claim that having #techsafety as a primary value would be profitable and produce outstanding results. I think I buy into that, even if he hasn’t had time to prove it yet with his own company, @IndustrialLogic.

A few twitter notes from the session.

Edit: Joshua have written on #techsafety himself:

Lean Coffee: Democratic, Responsive Meetings

Lean Coffee is a meeting format where you don’t finalize the agenda before the meeting starts.

It can take place in a café, but also in a meeting room, living room, or almost anywhere.

The topic is often Lean, Kanban, agility in business and product development (like software development), but the format lends itself to any topic.

An example of established groups meeting for lean coffee is Lean Coffee Oslo.

These groups are people meeting on their own time to learn, but this format has big potential benefits in business context as well.

Lean Coffee at a café

A few quotes from LWS on Lean Coffee:

Essentially, a Lean Coffee is a group of people working together to learn … in an informal setting.  It’s like a mini-unconference where the participants decide on the schedule.
….

Step 1: Everybody writes down topics they’d like to discuss on stickies ….
Step 2: Each topic is briefly described …
Step 3: … votes …
Step 4: … stickies with the most votes at the top
Step 5: Each of these stickies are discussed
Step 6: If enough time … do another stickie

A few quotes from @ourfounder and @sprezzatura on why democratize meetings:

Agendas are so 20th Century.
….

When you set an agenda, you control the conversation. …. When you control the agenda, you control the lessons learned. Since we enter a meeting with only our assumptions to guide us, agendas follow our assumptions. Our assumptions are based on what we already know. But what about the things we don’t know? Quite often, it’s the conversations we don’t plan on that give us the most insight. Why not instead run our meetings to learn or to discover?
….

Conventional wisdom suggests that businesses hold far too many meetings attendees deem a waste of their time. ….  To combat this, some call for meetings with rigid agendas.
….

the discussion of a stated topic is a conversation. In fact, the entire reason we are calling the meeting is to have a conversation.
….

If we want to learn from our meetings, we need to allow the conversation to be set by the very professionals we invited to the meeting in the first place.  …. Allowing the group to have a say in setting the agenda gives them buy-in for the importance of the topics.
….

as the person who called the meeting, you can now direct the overall topic and even seed a few of the initial sticky notes. You can even set a few “must discuss” stickies at the top of the board and prioritize them the highest.

Notes:

  • Takeaways
    • either privately or f.ex a right-most column on the board
    • per topic or sharing takeaways in general at the end of the lean coffee

Read more:

 

Case Study on Lean-Kanban in BBC

David Joyce and Dr Peter Middleton have studied the application of (what I call) Lean-Kanban in BBC.

From the abstract:

The evidence shows that over the 12-month period, lead time to deliver software improved by 37%, consistency of delivery rose by 47%, and defects reported by customers fell 24%.

The significance of this work is showing that the use of lean methods including visual management, team-based problem solving, smaller batch sizes, and statistical process control can improve software development.
….

The faster delivery with a focus on creating the highest value to the customer also reduced both technical and market risks.

There’s more info on David’s blog, and you can also read the case study itself prior to publication from there.

Update: The case study was published in 2012.

Lean: Development is not Manufacturing

The conclusions of lean manufacturing theories are not necessarily valid in the domain of (software) product development.

There’s good reasons why it’s so difficult to fix time, budget, and feature scope all at once in a software development project.

I’ve been listening to a talk by Don Reinertsen, and one of his points, although not the main point, is about variability:  if you could reduce variability in the workflow by 10%, or you could reduce capacity utilization by 10%, by far you would prefer to reduce capacity utilization.  That’s where the economic payoff is.

The reason is that increased capacity utilization increases queue size and lead time exponentially.  In other words, if you try to keep all your resources busy all the time, everything takes forever to finish.  This goes for both manufacturing and development.  Variability in workflow, however, is bad in manufacturing, but can’t be avoided in product development, and might even be exploited.

So what else is different about development compared to manufacturing?

Manufacturing Development
Tasks are…. repetitive non-repetitive
Tasks are… predictable unpredictable
Requirements are… a constraint a degree of freedom
Requirements are… fixed evolving
Cost of delay is… homogeneous non-homogeneous
Task durations are… homogeneous non-homogeneous
Variability is… always waste not always waste
Inventory is… physical objects information
Inventory is… visible invisible

Source:
A talk by Don Reinertsen,
Second Generation Lean Product Development: From Cargo Cult to Science