Introducing Kanban through a 3-layered value system - a familiar core that drives change, a middle layer that is about direction and alignment, and a protective outer layer of discipline and working agreements.
This model aligns Kanban with the concept of the Learning Organisation and suggests ways to seek resonances with other methods. It has some practical advantages too: it can help us engage more effectively with the organisation as it currently is; it encourages us to self-reflect on our effectiveness as agents of change; it provides a convenient framework for the capture of stories.
The Vanguard Method is a systems thinking approach for service organizations developed by John Seddon & co. Vanguard encourages us to understand and get knowledge of the system's purpose, demand, capability and flow and thus move an organization to a systems design. There are many aspects where Vanguard has wisdom that is not yet fully utilized in the Kanban community.
For the last 6 months, I have been coaching and training clients in Kanban while applying principles from Vanguard. In this session I will share my experiences and what I've learned.
Cynefin is a framework for making sense of the world and its problems; for understanding where outcomes are predictable, where they might emerge in time, and where urgent action is required.
Over the last few years, I've been teaching Cynefin and basic complexity thinking to different enterprise clients. I've used them to help plan and release meaningful MVPs, discover and pivot early, and appreciate and embrace uncertainty and innovation.
With Real Options and Deliberate Discovery, Feature Injection, stamping butterflies, human dyads, and more!
This session will demonstrate how games can be a powerful tool to encourage intuitive learning. We will introduce Henrik Kniberg's Name Game, and show how playing the game inspires learning in ways that teaching and lecturing alone cannot. Attendees will also gain the key learning points from the game itself, which are of great benefit to Lean & Agile teams and Organisations alike.
Description
Teaching and Learning are 2 separate activities which are often misunderstood. Teaching is often mistakenly believed to be the best way to cause learning in a group. From our experience training adults and working with children, we have seen that playing games is a much more effective way to generate learning that resonates with the learner, and is more likely to be understood at a much deeper level. We want to use this session to demonstrate the effectiveness of using games to support learning.
This session is intended to work on two levels, firstly, by showing how playing games supports learning, and secondly, by conveying the intended learning points from the game (which I am keeping secret), which will in itself be very useful for the attendees and is at the heart of Kanban.
We will run through a tried and tested game written by Henrik Kniberg which results in players generating their own empirical data to reinforce the learning. Once we have run through the game with a group of volunteers and taken the direct learning points from it, we will start to explore how the playing of the game promoted learning in the group, and explain why it is one of the most effective learning tools.
Torchbox is a web agency working on multiple concurrent projects for different clients. We started using Kanban in 2009 and are continually adapting our implementation based on collaborative feedback.
In this session I'll describe how we've met the challenges of managing multiple clients with Kanban along with the improved quality and financials we've achieved as a result.
More than half of my team has been working together for more than 10 years . Whilst you might think this is a recipe for stagnation, through continuous improvement and Kanban the team is more alive and effective today than it's ever been. The talk charts the progress we've made from command and control to a collaborative, self organising team using kanban to search for the next improvement.
We moved from features that grinded on for months to lead times for stories of less than 10 days and bugs less than 2 days. We moved from the business planing releases months ahead to daily changes of priorities. We've gone from rarely talking to continuously sharing and learning from each other. In 10 years we've built a happy and effective team.
The talk discusses some of the big decisions we took over the years and some of the behaviours that emerged naturally. I'll discuss my thoughts on how to build teams that stay together and refuse to stand still.
"We cannot manage what we do not measure" - Bill Hewlett
Metrics, measures and targets are playing an increasingly important role for decision making.
But is common practice effective?
Let's examine our infatuation with measurement, take a hard look at some common metrics and figure out if there's any merit at all to targets as commonly used.
This session aims to reexamine the role of measurement in decision making, establish a new, decision focused, frame for their use and to dispel prevalent myths and misconceptions.
Feathers will be ruffled, stories will be shared.
In this talk, I'd like to discuss and debunk several commonly held myths about The Kanban Method.
This talk, which is targeted at beginners, people new to the Kanban Method and people who want do debunk these myths, discusses why it is important that we don't let myths and misconceptions limit our use of the Kanban Method. Unfortunately, we (our industry) often create these myths and misconceptions due to the competitive nature of our business and because of our natural inclination to fear the unknown.
Continuing the work of the Kanban Community (KLRUS, LKNA talks), this talk will explore and debunk 5 specific myths about the Kanban Method that I've seen in my consulting experience. The myths I'll discuss specifically are that The Kanban method...:
1) ... competes with or tries to replace Scrum
2) ... doesn't have iterations
3) ... only works for Dev Ops or Maintenance projects
4) ... is a mini-waterfall methodology
5) ... requires all work items to be the same size and doesn't estimate
At Deloitte Digital, we pride ourselves on being Lean and doing Agile. It is the only way we know to build software. However, our clients - some of the largest companies in the UK, across all industries - often impose waterfall governance and expectations on our teams.
In this short (25-minute) session, Martin Aspeli, a senior manager responsible for multi-million-pound software development projects, will share the tips that not only let us get away with Agile, but make our clients want to emulate our approach.
Topics include:
- Why Scrum and other agile methods fall short in a professional services context
- Delivering fixed-price project in small batches without stumbling into waterfall
- What our clients might say to "no estimates"
- Being an Agile island in a programme of waterfall deliveries
- Managing dependencies and change effectively without souring the client relationship
One of areas of constant struggle for many organizations is managing portfolio. Too many concurrent endeavors, commitments made without available capabilities, lack of discussion about expected value and cost of delay, disconnection between portfolio management and work organization on team level, constant expediting, highly insufficient or inaccurate information... If any of these sounds familiar it indicates common issues on portfolio level.
Interestingly enough, in these areas improvements are rare and traditional models surprisingly prevalent even in organizations that adopt agility across development teams. At the same time very frequently low-hanging fruits can be harvested at PMO level after introducing fairly simple improvements.
In this session I will describe how Portfolio Kanban can be used to steer evolution not only at PMO level but across an organization and show how it can be orchestrated with introduction of Lean and Agile on team level.
When we talk about Kanban we often focus on how the increased attention to flow can benefit our organisations and customers economically. We talk about the improvements it can bring by helping us reduce lead times, manage risk, discuss cost of delay etc.
Creating a culture of continuous improvement is also at the heart of the Kanban method but again we often target the economic benefits when we strive to identify and remove waste, increase predictability and produce higher quality software.
But what does Kanban mean for the individuals who work inside the system?
In this session we'll explore how the Kanban principles and practices can foster understanding, belonging and purpose in the workplace.
The title refers to a quote attributed to E.Deming.
Today there's general consensus - and a lot of noise - about the need for change.
Still, organizations are having a hard time with change. Most change initiatives fail.
Sometimes it's just a matter of lack of will to change.
Sometimes organizations just don't even understand why or what they have to change.
Change is often believed to be magically reachable designing new processes on paper, possibly paying huge amounts of money to consultants.
The talk will introduce the Kanban Method (not to be confused with the Kanban Tool) as an evolutionary approach to managing change and as a way to build a learning and adapting organization
---
Topics:
- Why change initiatives fail
- The Kanban Method and its key principles & practices:
° making work visible and understanding where change is needed
° limiting the amount of work and balancing demand and capacity
° managing and balancing flow, making value flow
- Quantifying economics and risks in decision making
- Getting buy-in from all the people involved
We will take in Kanban Boards, Domain Models, Value Chains, Impact Maps, Comparative Cycle Time Graphs, Chopped up Cumulative Flow Charts and The Worlds Simplest Control Chart.
We shall talk about where they have added value and where we have tripped ourselves up. We shall also delve into Behavioural models such as Habit Loops and take a sideways glance at what we can learn from the organisation of source code repositories.
These charts, diagrams and tables are not an end in themselves. Their operational validity needs to be continuously assessed as both our understanding of the work, and the nature of the work itself changes and evolves.
Nor do these artefacts tell the whole story. They are a selective abstraction which whilst useful and beguiling should not cause you to forget the dark matter that lies behind them.
This dark matter is a mystery which needs to be probed and tested and from which emerge new models, new maps, new measures and a continuous evolution of the organisation.
Is the Scrum vs Kanban discussion helping you to address your business challenges? Does it help you in better running your existing business, or changing towards future business, and most importantly, doing both at the same time? Does it help you in your quest of increasing efficiency and improving quality in delivering value to customers while at the same time being more effective in discovering uncovered needs and future value? Does it help you solve your problems when you know which words are on the Scrum box, the Kanban box and how they compare?
This webinar tells the story from the perspective of 2 archetypical cases: Big-Utilities.inc’s and Digitatl-Innovations ltd. Big-Utilities’ internal ICT department is under extreme pressure. Due to economic circumstances, they need to cut cost and be very cost aware in their day-to-day operations. At the same time, to support the transformation that the business is undergoing, they need to execute increasingly large and challenging worldwide IT implementation programs. Digital-Innovations ltd, is a start-up technology company. Development is driven by a small, co-located team of experienced developers that work in short iterations. As Digital-Innovations is moving towards a more feature rich product, the development team needs to be extended with a test team, functional analysis skills and extra development capacity. Because of cost and availability of skilled engineers they are thinking about near- or offshoring.
The question we will answer is how both companies can organize the work in a seemingly contradictory environment. We will look inside the Scrum box and inside the Kanban box, and analyse the underlying models of organizing work: swarming and pulling; work cells and workflow; incremental and radical change. We will think outside the box, and look at the value of switching, cycling and mixing these different models of organizing work and how this helps to address the contradictions of running and changing the business at the same time. In doing so we rediscover some of the learnings of Taiichi Ohno, the father of the Toyota Production System, which became Lean Manufacturing in the U.S.
Project Planning using Little's Law
Here is the content of the talk
http://dimiterbak.blogspot.com/2013/04/project-planning-using-littles-law.html
How often does you team revisit the first principle of Kanban: Start with what you do now? Over time the original reason for the way you are working will have changed. The initial problem you had might be solved, or the context might have changed sufficiently for current policies or solutions to become less effective.
This presentation will go into closing the feedback loop on your initial design decisions and policies and get the focus back on why Kanban was adopted in the first place. It revisits the first Kanban principle "Start with what you do now".
In this talk will be the some experiences from the field on how to keep the focus on why certain policies where implemented in the first place and validate if they are still an effective way of solving problems. Both from my own experience as well as from other people.
Time is valuable, and when it is gone, it is gone. Are you focusing on flow or just keeping yourself busy? How much has the red brick cancer spread in your processes?
In this session we will talk about time. We will explore the differences between systems with high resource efficiency and systems focused on flow efficiency. We take a look at how to remove the red brick cancer in your processes. You will learn how to understand and improve the end to end flow in your system.
Session lenght:25 or 55 min
The attendees will get a greater understanding how to continuously improve the end to end flow by focusing on flow efficiency first.
A short version of this session was presented at the ACE! Conference in Krakow in April 2013. Video and slides are available here http://hakanforss.wordpress.com/2013/04/17/the-red-brick-cancer-ace-conf-2013-04-16/
Hi, my name is Zsolt, I broke the WIP limit several times, I'm still on the team and I'm happy about it. Most probably you've had a similar experience (except maybe you weren't happy at all) when you first started to work in a team that got hit by the Kanban method introduced by one of your fellow teammates. At first, it is hard to follow and understand all the principles and practices, especially when they "hit" us, and therefore we make mistakes. This is good and natural because this is how we live our lives: we fail, we recover and start over.
Starting over requires us to do at least two things: re-learn the principles and practices, and look for examples on how others recovered. I believe that understanding the pull system, the WIP limits, and the difference between manufacturing and software development will give us enough to recover faster from failures and accelerate the learning process. Moreover, I assume that I did more wrong than right during my journey in Kanban land, and it cost me a lot. I believe that if I share these stories with you, it will save you a great deal of trouble for yourself, and if not, at least you'll have some ideas on how to recover.
Clearly, this talk is not for advanced practicioners, but I think they are as rare as unicorns anyway. So, if you have doubts, or want to know why we do things in the Kanban method as we do now, and you are also interested in some practical ideas, this talk is the right place for you.
Management as a social technology can be improved, it can be hacked, the same way white hat hackers created and improved computers, softwares and the web.
This session will explore what is management hacking coming back to the roots: the hacker ethic. It will also provide 8 ways to hack management and show how Kanban is a very good step.
Management 1.0 won't help your organization to survive in the next century, you'd better update your management system to avoid blue screen of death and make your organization thrive!
In this session we will present two experience reports demonstrating how application of Kanban has helped the respective organisations improve and achieve significant results.
Leading energy commodities platform provider.
Does the Kanban principle of flow succeed in practice?
“This experience report shows how using Kanban principles can deliver large process improvements in a real-world scenario. As a first step in transforming an organisation, identifying the mechanics of flow, and prioritising/visualising the business impact of small change improvements, quickly demonstrates high value and increases momentum. This example study shows the timeline of change for maximum effect.”
Market leading healthcare provider.
We would like to share our experiences of delivering business agility at a market leading healthcare provider by implementing Agile practices and later introducing a Kanban approach.
What we have achieved:
Improved customer satisfaction
Higher quality products released more often
Wider choice of products
Moving towards our goal of making quality healthcare affordable
Within our organisation
Escaped defects to live reduced from 130 to below 5 per release
Increased the frequency of releases from twice a year to one every two months
Built quality in our development by including Test as we go approach not at the end
Moved from weekly to twice weekly to multiple times a day deployments with our integration environment creating shorter feedback loops and shortened work item completion time
Reduced lead times by using visual management to prompt teams to look at how their processes can be improved to minimise delay
Delivered a capability that can do more without increasing team size
We have supported the above achievements through Training, Coaching and embedding of specialists within the teams.
If you are struggling to forecast project delivery dates and cost, or you want to eliminate the story estimation process because you feel it is waste, or you need to build the business case for hiring more staff, then this session is relevant to you. All estimates have uncertainty, and understanding how multiple uncertain factors compound is the first step to improving project and team predictability.
A major benefit of Lean is the low weight capture of cycle time metrics. This session looks at how to use historical cycle time data to answer questions of forecasting and staff skill balancing. This session compares the benefits of using cycle time for analysis over current planning techniques such as velocity, burn-down charts, and cumulative flow diagrams. This session takes you on a journey of what to do after capturing cycle time data or what to do if you have no history to rely upon.
Key session takeaways include:
- Why story point estimation and forecasts fail to deliver.
- Why cycle time data follows a known distribution pattern and how to leverage this.
- How much data is needed for reliable forecasting, and what to do if you have less (or none).
- Forecasting project date and cost from cycle time data.
- Finding the right balance of staff skills (for example the number of developers and QA staff).
