Tag Archives: kanban

The beginner’s Agile and Lean library

Posted on by
Reply

There is a lot said online about Agile and Lean. The distinction between the 2 would be a post on its own, but I would like to present here a few books which are a very good introduction. A lot of them are specifically geared towards software development, but most of the practices and principles can be adapted to other areas as well. The best examples is that a lot of the lean principles actually come from the car manufacturing industry.

 Suggested reads

Kanban: Lean from the Trenches, Henrik Kniberg. This is not a textbook, but a real world use of kanban by the swedish police. This is a very easy read, with loads of pictures to help you visualise and understand what this book is about. Just by reading this book, you will learn a lot about many aspect, practices and artefacts of lean and agile. If you read only one, I would suggest this one, as it does not delve too much into theory but follows a project from start to finish, which helps understand what agile and lean are about. After reading it, you will probably want to dig some parts deeper, and other books will become interesting.

Lean: An Agile toolkit, Tom & Mary Poppendieck. A classic, this book will provide you with a set of tools and principles that constitute the core of lean: eliminate waste, decide as late as possible, empower the team… Even only keeping this principles in mind and forgetting the details will go a long way in making your team, product or company better. If you want to know more about lean after having read Lean from the Trenches, I wholeheartedly recommend that one.

Scrum: The Elements of Scrum, Chris Sims & Hillary Louise Johnson. This book is a very easy read as well, specialised in Scrum. You will learn about the roles (product owner, scrum master…), artefacts (backlogs, charts) and practices (stand up, demo…). I followed a Scrum Master training after having read this book, and although I still did learn things during the training and enjoyed the practical aspects, this book taught me the majority of the theory.

Further reads

Hardcore theory: The Principles of Product Development Flow: Second Generation Lean Product Development, Donald G. Reinertsen. This book is just amazing. If you read it, I would strongly suggest to buy a dead tree version, as I found myself going back and forth a lot between chapters to refresh my memory. This is the only book I own for which I bought a dead tree version after having bought the ebook version. Basically, the goal of this book it to put a financial value on everything, which then allows you to compare practices by having a common measurement. You can read this book at many levels. Again, the principles are great to remember (to name just one, the main one I believe: the cost of delay. For everything you do, ask yourself the question of how much the extra delay will cost the company), and only for that this book will teach you a lot. If you are not scared of sentences like ‘The arrival queue in Kendall’s notation can be modelled by a M/M/1/∞ where M is a Markov process’, this book will move from great to fantastic.

About delaying commitment: Commitment – the book, Olav Maassen, Chris Matts, Chris Geary. A nice graphical novel specifically about the value of keeping your options open up to the last responsible moment. You will follow a project from its impending doom to its shining success, thanks to good lean practices. On top of learning about keeping your options open, you will learn about a few lean practices as well.

The Mythical Man-Month: Essays on Software Engineering, Frederick P. Brooks Jr. : I have not read that one yet, but this is a classic referenced a lot which I will read at one point. According to wikipedia, this book is widely regarded as a classic on the human elements of software engineering.

Advertisement

Golden cards or how to do break out the flow for one day

Posted on by
Reply

I would love to do $something but my backlog is packed…

In my team, we are using kanban to manage our workflow. We are quite an operational team, so this fits us very well.

One point of frustration is that we do not get to chose our work. We do have our own long term projects, of course, but most of our work is operational depending on what our customers need. There is a lot to do, the pace is very high, so we never are out of tasks. Sometimes, though, something is nagging us. What if we were trying out this cool new tool? What if I could spend one day trying to answer a question based on our dataset? What if I have an idea with great potential but not immediate apparent business value?

This kind of things do not have a spot in our workflow, already packed.

We tried to setup hackathons, but this is quite tricky, at this mostly implies that the whole team must do it at the same time, whereas we do not have the same pressure or even time habits. By experience, it did not work out so well.

That’s why we introduced Golden Cards.

Golden Cards

Each team member gets 2 cards per month. When they play one of their card, for one day they are allowed to work on whatever they wish, diverting all non-emergency work to the other team members.

Effectively, this give us 10% of our time to do something we, as individual or as a team if many of us play a card together, want to do.

What is the expected outcome?

  • A direct effect was to make the team member happy, by giving them an interesting option.
  • Maybe one of us will build the Next Big Thing.
  • It already allowed some of us to block a day to learn new skills, which in the long run will be helpful, but the time was never quite right to do it.

Feedback

We are using golden cars since only one month.

So far, the team increased their knowledge and took time time to check out a new job scheduler. The feedback is very positive, if only because it makes the team members happy. Technically, our backend setup is a bit saner now, and will keep improving.

Having the opportunity to say ‘no’ to (almost) every request during one day is very liberating, and the day always feel like it was well used.

One thing to note is that it is worth blocking your calendar for the day, to make sure you do not end up in unwanted meetings.

So how does a golden card look like?

I am glad you asked.

A lot of us play Magic the Gathering, so here is what we ended up with, courtesy of Magic Card Maker.

Golden Card

Golden Card

Lean Kanban NL 2013: take aways of a techie

Posted on by
Reply

Those are the take aways of a techie after #LKNL13:

Main take aways

  • When a measure becomes a target, it ceases to be a good measure (variation on Goodhart’s law)
  • The best metric to prioritise is the cost of delay
  • Keep your options open as long as possible, push back commitment as late as possible to gather the most insight first
  • Success hinges on being wrong early
  • If human are involved, you have a complex environment
  • Bottlenecks:
    • They are not an actual issue, but their impact can be
    • Use them to keep resource available (not use the team all the time at 100%) and to do some non mission critical work
  • Moving a person (eg. go to another team standup) is a lot easier and more efficient than moving knowledge by eg. documentation.

Kanban in a nutshell

  • Principles of KB
    1. Start with what you do know
    2. Agree to pursue evolutionary changes 
    3. Initially, respect roles responsibilities and job titles
    4. Encourage acts of leadership at all levels
    5. (1-3 are to go around resistance to change, or more accurately, resistance to be changed)
  • Concepts of KB
    1. Service-orientation (DBA service, architecture service)
    2. Service delivery involves workflow
    3. Work flows through a series of information discovery activities
  • Practices of KB
    1. Visualise
    2. Limit wip
    3. Manage flow
    4. Make policies explicit
    5. Implement feedback loops
    6. Improve collaboratively, evolve experimentally

One book came again and again as recommended: The Principles of Product Development Flow, by Don Reinertsen.

The slides can be found on lknl13 page.

Talk by talk take aways

David J. Anderson, Modern Management Method

Modern management means that innovation changed the way of doing something – this is not just about a new tool.

Dave Snowden, Complexity: the new paradigm in decision making

  • Successful companies do not follow the recipes of other. What lead to success in one company does not mean it will lead to success for your company.
  • When a measure becomes a target, it ceases to be a good measure (variation on Goodhart’s law)
  • Intrinsic motivation is destroyed by extrinsic targets.
  • Look into cynefin framework. Systems divided in 5:
    • Complicated (known unknown, good practices)
    • Simple (known knowns, best practices)
    • Complex (knowable (by experimentation) unknowns, emergent)
    • Chaotic (unknowable unknowns, novel)
    • Disorder: transition phase or when a preference is imposed
    • Collapse from complacency: sudden and unanticipated collapse into chaos from apparent security
  • Complexity cannot be eliminated, only absorbed.
  • Complexity is about flow. Need to manage the system as a whole, not in part.
  • You can intervene on complexity (experimental action), while keeping in mind:
    • Needs to be coherent (not necessary right)
    • Safe to fail
    • Small and tangible
    • Managed as a portfolio (many experiments in parallel)
    • Sometimes oblique approach
    • Includes naive approach
    • A few high risk/high return

Steve Tendon, Unity of purpose and community of trust

  • Different incentives and metrics create internal conflicts => different units will have different agendas, because driven by different incentives.
  • There should be 1 system wide metric: throughput metric
  • Need a system view that avoids local optimisations

Gaetano Mazzanti, People as bottlenecks

  • The issue is not actually the bottlenecks, but their economical impact.
  • Trust != hero culture. Trust can scale, heroes cannot

Donald Reinertsen, Shooting crooked arrows at moving target in the fog

  • Close gaps on basis of economics, not ideology (is it cost effective to complete the last 5% of this feature?)
  • Seek and respond to disconfirming information (confirmation bias)
  • Think about the economics of creating exploitable options
  • Buy information in small batches,act upon any new information
  • Improve response time by decentralising the information, the authority and the resources necessary to quickly redirect programs
  • Encourage and reward initiative
  • Inform your decisions with economics and statistics

Troy Magennis, Cycle time analytics

  • Success hinges on being wrong early
  • Always compare model vs. actual

Joshua Bloom, What is the value of social capital?

  • Emergent slack, resilience with benefit: use bottleneck to create ‘free’ time of people to non mission critical work.
  • Moving a person (eg. go to another team standup) is a lot easier and more efficient than moving knowledge by eg. documentation.
  • Your software will only have qualities already present in the organisation. The organisation itself needs to have these qualities
  • Teaming (verb, a dynamic activity) is more important than teams.

Olav Maassen – Risks and decisions – the ‘When’ rather than the ‘How’

  • Option theory: postpone commitment to the latest possible. Keep all options open
    • Options have value
    • Options expire
    • Never commit early unless you know why
  • Always ask yourself: how does this create more options to me? How does this allow me to push decision to a later date to get more information?

David J. Anderson, Kanban and evolutionary management: Lessons we can learn from Bruce Lee’s journey in martial arts.

  • See principles, concepts and practices above.
  • Bruce Lee’s JKD is based on teh same principles: use what works, test in real life

Astrid Claessen, Gamestorming your retrospectives

  • Danger in retro: boredom/familiar feeling, hence gamestorming
  • Gamestorming is actual work

Ajay Reddy & Dimitar Bakaradzhiev, not everything that counts can be counted and not everything that can be counted counts

  • feasibility of measuring
    • Your problem is not as unique as you think
    • You have more data than you think
    • You do not need as much data as you think
    • It is easier than you think to get the data you need
  • Good measures
    • Lead time
    • Throughput
    • WIP
    • Cumulative flow diagram (representation of wip at each stage in the system)
    • Flow efficiency (work time against lead time, indication of waste)