A3 reports are known as a way to capture problem-solving activities following the PDCA (Plan-Do-Check-Act) cycle and also to focus problem-solvers’ thinking, helping them understand the problem
deeply and uncover hidden root causes leading to effective countermeasures. This session demonstrates the potential of A3 Thinking as an evolutionary improvement method in organizations that can
complement existing process and improvement methodologies, such as Agile, Kanban or ITIL.
The session contains a story of a “data centre crisis” in a software company, when multiple departments, each using different processes and improvement methods, came to work together to learn deeply about their common problem, address its root causes, drastically reduce the downtime and lock in lasting improvements. The story is used to reinforce several key aspects of A3 Thinking, to demonstrate its evolutionary nature, and to explore its relations to organizational complexity. The story also has a number of stopping points, highlighting several key coaching behaviours important to Lean/Kanban change agents, including: the non-judgmental attitude, avoiding resistance to change, working with the existing culture, validated learning, and the ability to lead improvements with safe-to-fail experimentation.
In lean approaches problems are well known as opportunities for learning and improving. Do traditional approaches like project management, new IT solutions and lean tools actually encourage this learning and improving? Based on Vanguard’s 30 years experience in private and public sectors we have learnt that traditional approaches can lead organisations down a dangerous path. The inherent assumption about the problem and the answer can result in doing the wrong things righter. We will show through examples the dangers in some of the traditional approaches to problem solving and the impact on performance. We will explore a practical approach to solving the right problems and how to involve IT at the right time. It all starts with get knowledge!
IT managers who want to improve their software development activities are quickly faced with the “Lean or Agile?” question. Are lean and agile the same thing? Should we deploy agile before implementing lean? Having been on both sides of the table, Régis shares what he has learned so far about both approaches, and how best to use them to create high performance software development organizations.
Using Kanban to help organizations evolve means we frequently use it in situations where predictability is important BUT good flow is not immediately attainable, where flow is not yet liquid/frequent enough to satisfy hunger for visibility/control. I learned (the hard way - I will tell you how the term GanttBan came to be...) to help organizations establish visibility to schedule risks and work health very early in their evolutionary journey. In this talk I will share the stories and practices so you can mitigate those risks better.
Kanban is phantastic in the support the flow of product development and self improvement of teams in that area. However, at each time the process defined through Kanban poses an impediment to work in the creative field. While Kanban may very well fit to work in the domains of product maintenance and iterative, feature by feature innovation, it does not support evolutionary or disruptive innovation. These types of innovation dip slightly or even more into chaos and are completely non linear processes which simply do not fit the Kanban board and process. The talk will show how to protect innovation from delivery and otoh how to create the necessary level of communication between these areas w/o creating silos.
It seems to be common sense that we need more than Kanban mechanics in order to create a sustainable culture of continuous improvement. State-of-the-art change and leadership practices are inevitable if we want to realize the full potential of Kaizen. But what about the general question of how to lead change within a specific organizational environment? How do we align evolutionary change with other approaches such as Six Sigma, CMMI or Scrum? How do we coordinate our various change initiatives on the strategic level to make sure that they complement rather than undermine each other? Building on my ideas presented at the LKNA13 and posted on our Platform for Agile Management (http://p-a-m.org/2013/05/change-management-with-kanban/) I would like to show how to answer these questions by making change as visible as possible, limiting change in progress to foster flow, aligning different initiatives on the strategic level, creating a powerful change coalition building on fast feedback loops, leading change with a consistent focus on stakeholder value. Referring to my experience with some Swiss, German and Austrian companies I will explore how these practices work and how they help to improve change leadership at all levels.
We all seem to love the term 'continuous improvement' - which is an honourable intention. But in reality 'continuous improvement' can be hell on earth - e.g. to always be 'not good enough'. In fact, some corporations, managers and teams have been known to use this phrase as an excuse for behaving badly. So, how can an honourable intention like continuous improvement create a negative impact, ie. apathy? If so - how do we avoid it? What are other ways of handling this need to consistently overcome challenges in an ever-changing industry? And does 'continuous improvement' have a limit or is it an endless source of success? Using case study examples this talk reflects on what continuous improvement really feels like on the ground and explores how we might want to approach 'getting better' by looking at and drawing from other industries, research, ideas and real-life experiences.
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. Reducing reliance on developer estimation (popularized by the twitter hashtag of #NoEstimates movement) is good general advice, having the tools to plan and manage teams and projects is still important to maintain support at the executive level. This session details the approaches to getting the numbers you need to have whilst minimizing un-necesary overhead and estimating ONLY this factors that matter most.
If you had picked up a book fifty years ago about the job of running an organisation, it would almost certainly have had the word ‘management’ in the title. During the 1980’s, it was suggested
that whilst management is fine in a stable environment, change requires leadership. As the rate of change continued to increase, so did the emphasis on leadership. Today, running a business is
understood to be a matter of leadership. Management is regarded
as old fashioned or worse. That is a problem. In this talk you will learn that Management still matters, and it always will. So does leadership. So does something else which nobody in the business schools seems to have noticed. In the military it is called ‘command’. In business we might call it ‘directing’. Being part of the group running a business organisation requires mastering three sets of skills: the executive’s trinity.
-> Read interview with Stephen Bungay
One ofthe areas of constant struggle for many organizations is managing their 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 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.
How we made the journey from flow in our complex products to flow thinking for our processes. Ericsson is number 1 in mobile infrastructure thanks to our ability to innovate around state-of-the art algorithms for optimizing packet data flow. We made a mental leap when we realized that all this is also applicable for flow through our processes. We will share our experiences:
(1) create buy-in and commitment for flow thinking using this mental model/metaphor
(2) practical examples of how we improved our product development flow.
Where can Kanban be embedded in the organizational context? Sounds like an easy question, however, it is not always easy to answer - especially in bigger organizations. In this session I will introduce the Kanban Flight Levels model which provides an overview of the different fields of application of Kanban and helps to understand the implications for the organizational context. Furthermore, the model helps to clarify where to start with your Kanban change initiative: on team level, on the value stream, or on portfolio level - every level has it's own challenges, pros and cons.
In a few years Spotify has grown from a small startup in Sweden to a pretty big company with more than 30 engineering teams in four different development offices on two different continents. And we have no intention of slowing down. Such rapid growth carries big challenges. How can we continue to improve our product at great speed, while growing the number of users, employees and supported platforms and devices? How do we stay lean and agile when we grow from a small startup to a big corporation? In this talk we will present how Spotify is addressing these challenges. We will talk about autonomous squads, tribes, guilds, hack weeks, road managers, and a lot of other ideas we’re experimenting with.
Making products fly involves more than just the development team. So how do we involve, intract and improve with the non software parts of the value chain? Let me walk through lean techniques and thinking that helps drive improvements across organizational borders. I’ll share experiences and examples from real case studies where they have been put to use.
We have to stop adopting defined processes (or methodologies as they known in the IT business). Instead we need to look to adopt a new style of management that encourages an adaptive capability to emerge in our organizations. This talk will look at Bruce Lee‘s rejection of patterned styles of Chinese Martial Arts and emergence of his Jeet Kune Do approach and compare it to the emergence of the Kanban Method. The talk will illustrate how to use fitness criteria metrics aligned to customer desires to manage an organization that is continually evolving its workflows to improve service delivery and customer satisfaction.
This presentation will describe the approach taken for one of the world’s largest Kanban implementations at Siemens Health Services. It will describe how Kanban augmented existing agile practices there, and it will examine the achieved benefits of “flow” as demonstrated by real project data. Through a careful consideration of successes, challenges, and ongoing opportunities, this case study should be very meaningful to software product/development management organizations of any size whose funding, business operations, and profitability are dependent upon achieving a high degree of operational efficiency, transparency, and predictability.
IT Operations people have several distinct challenges than software developers. Ops teams must balance large workloads and emergency tasks with assuring a stable infrastructure. Their workflow is continuous, and many times doesn't work well with timeboxes. Kanban is widely used to address the needs of IT Operations.
Introducing Kanban through a 3-layered value system - a familiar core that's about driving 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 benefits too: it can help us engage more effectively with the organisation as it currently is; it encourages us to reflect on our effectiveness as agents of change; it provides a convenient framework for the capture of stories.
The first team at Jimdo to use Kanban began in October of 2010. Shortly thereafter, whiteboards and sticky notes spread quickly throughout the whole company. The Kanban Implementations took on different forms, and ranged from pure visualisation of tasks to different types of WIP-limits and the systematic use of models for continuous improvement (Kaizen). It soon became apparent using Kanban at the team level was very useful, but from the business perspective, it was in no way enough. Two things needed to happen: Company-wide Alignment of all teams and Leadership. This is especially true for a company like Jimdo which constantly doubled its head count every two years, and now has employees on 3 different continents. In this presentation, you will learn how Jimdo established itself in order to coordinate the whole company and pull everything together. What tools and practices proved useful? What lessons were learned? What hurdles were overcome? What role did the Management play? And just what exactly is a Teamverløtung?
-> Read booklet Management, Leadership and Alignment with Jimdo
Many problems we are trying to solve in software and product development are complex, with no obvious solution. As a result it is not possible or appropriate to simply define and follow best or good practice. Instead me must think in terms of heuristics to discover contextual solutions. I will describe how we can use Kanban as a set of heuristics to learn what those solutions are.
Way too often is Kanban portrayed as an agile, flow based development process close to the classical waterfall competing with Scrum. Kanban is supposed to unite all the advantages that waterfall processes offer (like clearly defined responsibilities, working in specialization, and all of that really efficiently!) with the agility of Scrum. You’re successful, however, without planning, estimation, nobody hast o leave their comfort zone. Awesome, isn’t it!? But that isn’t really Kanban. It’s just FAKE – False, accumulated Kanban expectations. Kanban is, contrary to a lot of expectations, a evolutionary change management method. A central aspect of this method is the establishment of a work-in-progress limited pull system. Through this system, demand is approached to the real system capacity. Limiting the work-in-progress and the other five core practises create a pressure for change. The four principles support changing the system evolutionary and collaboratively. The basics of Kanban – principles and practises – will be presented and discussed during this talk. It is directly especially at an audience with no or little knowledge of Kanban as a change management method. Kanban can be implemented deeply or, the majority of implementations I see, in a shallow way. Therefore, members of the audience who are already using visualization as a first practice should be able to take away fresh impulses.
We have canned processes, tools to create processes, and a planet filled with agile and kanban coaches. Is anyone really talking about how real process is made? What goes into real process? How do the people in the process impact their own process? What leads to companies and teams having the awareness to create process themselves? What rules, both social and procedural, apply? Jim Benson will use case studies and client experiences to give an outline for how change can really happen.
A3, PDCA and the Build Measure Learn loop (to name a few loops) are all informed by experimentation. Kanban embraces the scientific method explicitly; "Improve Collaboratively (using models & the scientific method)" and Lean implementations can be more effectively supported by a sound understanding of the philosophy of science and proper experimental design. This presentation will briefly explore the basics of the scientific method, including deductive, inductive and abductive logic, probability, parsimony, and hypothesis testing. Through a series of group exercises, the audience will grapple with the concepts and return home ready to create an execute their first scientific experiment.
In this experience report, we present the lessons we have learned during a three years-long journey coaching more than 50 teams in using the Kanban method at Sandvik IT. We share our experience gathered when introducing, supporting and scaling Kanban systems with the purpose to improve the organization as a whole. Based on validated experiments and facts, we present:
This talk is a direct continuation of our LKCE11 talk “Igniting Change in 20 teams within 6 months”.
Gaetano Mazzanti: The colors of Kanban
Organizations are often like black boxes, from outside and from within. Kanban helps us to break open the black box and see the full color spectrum. some colors are good some colors are bad… it's just a matter of understanding and learning How many colors has Kanban? See through your org's darkness and let them show…
Mattias Skarin: What‘s got my brain to do with it?
Visualization is a key lean technique and a necessity, when you, as a part of a complex system are tackling a fast moving environment. But why is it such a necessity? Let’s walk through some of the limitation imposed on us by our brain, and how visualization helps us cope.
Nicole Küblböck: Kanban in the Film Industry: an experience report
After working at it-agile for seven months, I've absorbed a lot of information about agile methods - as well as adopted Kanban in my daily life (both at work and personally). Returning again to my actual career path, as a scenic painter in the film industry, I have put these methods into practice. In my talk, I will share about my experiment with Kanban in the film industry. How, armed with Post-its and paintbrushes, we used Kanban to manage the flow of props and set pieces traveling through our paint shop. Despite typically being a “push” system with pressing deadlines, we sought to keep the stress levels down, and deliver on-time by visualizing and prioritizing. We dealt with last-minute design changes, and props which were expedited. Come listen in, for a glimpse behind-the-scenes and hear how it all worked out!
Brindusa Axon: Personal continuous improvement - myth?
In a world where agile and lean's expansion grow, are we really all continuously improving? With studies showing that more than half of the world population is hating their jobs, are the current lean and agile tools enough to encourage and support personal continuous improvement? In this talk I plan to explore where our current practice fail to support personal transformation and how can we enhance them to become more effective.
Markus Wittwer: Lean meetings - 5 practical tipps to avoid waste and to achieve flow in meetings
How can we avoid waste and the build-up of inventory in a meeting? How can I as a participant of a meeting contribute to its flow even if I'm not the designated facilitator or if there isn't a designated facilitator at all? This talk is NOT about traditional facilitation techniques like "Checking of agenda points" or "dot voting" (although these are useful). Rather it helps you to notice the only-a-few-second-long moments when inventory builds up and waste is introduced in a meeting.
Pawel Brodzinski: Building Teams - We got it all wrong!
Let’s talk for a short while about how we build our teams. Best technical talent that we can find. Good engineering practices. Craftsmanship. Aren’t we full of that stuff? Oh yes, we are. And that’s exactly the problem. Building software is a team sport. So the question is: what does make a team effective? Once the question is answered we may want to rethink the way we build our teams.
Ralf Zarsteck: Cultural change: external software developers, inertial organisations and Lean Kanban
We, as teams external to our clients, usually don't have any organisational power. Although simply doing our work, we are nonetheless implicitly changing the culture of the client company. We don't take effect by position and managerial authority but by doing, through our roles and by being who we are. We value the meaning of instruments and procedures and we are looking at cultural change not only as a result by accident but as a desirable goal. Let's have a look on three role-models in the context of cultural change stimulated by external staff.
Arne Roock: Learning from Fake Charts
Charts can be extremely powerful. And fake charts can be even more powerful! So let‘s have a look at some charts that are completely independent from real data and see what we can learn from them!
Jabe Bloom: Pay attention to this!
The pure volume of information available to individuals is overwhelming. We have to decide what is important to pay attention to, and what is meaningless noise. When we get together as groups, we explain what to pay attention to, in order to share context and therefor meaning. Cultural change, is the process of changing what we pay attention to.
Most companies don't have empowered product owners. Instead they work with some kind of distributed product ownership. The talk analyzes why distributed product ownership is so common, what problems it produces and how to make it work. The key message of the session is that one size doesn't fit all. For mission critical projects product ownership may be assumed by a top manager, for startup-like projects an empowered product owner in some kind of "sandbox" may be more appropriate and distributed product ownership is totally valid for more maintenance oriented projects.
While HOW to make decisions is important, the WHEN to make decisions is critical to your chances of success. Olav and Chris present Real Options, an approach they have been working on since 2006 that focuses on the “When” rather than the “How” of decision making. Timing is everything, however deferring commitments causes stress to many people. Real options helps you manage that stress by creating bounded uncertainty in an context of total uncertainty. This is not a simple process that you copy and learn to adopt through practice. This is a new way at looking at the world around you that starts by learning to differentiate between options and commitments. Olav and Chris help do this through an interactive exercise. It turns out that the way you manage your options is to focus on commitments and attempt to avoid or defer them. After identifying commitments, Olav and Chris discuss creating options to turn the commitments into reversible commitments. Olav and Chris have recently creating “Commitment”, the first graphic business novel about managing project risk. Because they eat their own dog food Real Options plays a big part in the creation part of the book as well. They present the creation process as a case study about applying Real Options and how that leads to different behavior. Finally they present a number of mini case studies where other people have applied Real Option thinking in “out of the box” situations. Once you get it, it will change your life.
Newspaper business is a field in which requirements change rapidly. A sudden death of a celebrity, a political scandal or the outbreak of a war or revolution prompt the question how to best exploit these events in a way that is quicker and better than the rivals'. As a means to become more capable of reaching those goals, the existing Scrum processes were transformed towards the Kanban method. In this experience report I'll describe the introduction of Kanban in a publishing company based in Munich that is responsible for the online activities for over thirty German regional newspapers. After a quick overview of the different stakeholders, in the first half of the report I'll explain how prioritization and selection of new value items was done, how the visualization of the work flow made structural problems in the publishing company visible and how the data assembled from applying the Kanban method led to changes in not only the development team but also management. The second half details how the change processes hit the glass ceiling and got slowed down and eventually halted by management resistance. The report is directed mainly at an audience with little or no experience who are thinking about introducing Kanban but are not fully aware of the consequences that come with a deep implementation.
Many people have an impoverished and in some cases a dangerously distorted view of what Lean is. For instance one of the most damaging myths that Lean needs to overcome is that it’s about cutting costs and doing things faster with less people, although cost reductions and service improvements will result from a Lean transformation. Lean focuses on the people: customers, employees and managers. It then designs the whole organisation to release and realise human potential. This talk will look at some key myths and help you bust them at work. Here are just some myths waiting to be exposed.
In this session you will learn how TUI has strengthened its corporate culture and values by strategically working with "The 7 habits of Highly Effective People" by Stephen R. Covey.
You want to learn how to get from bad to best in just half a year with Kanban? Then this report is not for you. If, on the other hand, you are interested in how Kanban increases the chances in a team to focus on completing things, adapting practices constantly in accordance with the teams work context and within the few constraints defined by Kanban: then this talk might be for you. It is based on the experiences from a team looking back to more than two years of applying Kanban. The team is in charge of supporting a big development department (~2000 people) of Europe’s largest software company, with implementing lean/agile processes. In this session, we want to start with the reasons why our team switched from strict Scrum to Kanban. We will share with you how we tried to continuously improve the way we work (and how we sometimes failed) and what we changed in our Kanban system after improvement meetings (aka retrospectives): workflow, process policies, WIP limits, our metrics and more. We will show real artifacts (cumulative flow charts, run charts, our Kanban board), how they evolved over time, discuss how we used them and how they show effects of our improvement activities. We will also touch upon some drawbacks we experienced. Since we are also supporting implementation of Kanban in other teams with training and coaching, we’ll round up the session with some practical advices on Kanban introduction, based on what we have learned in the last 2–3 years.
There are a multitude of Kanban tools available today that work well for teams, but do they limit our thinking? The application of Kanban need not be constrained to the team. Ideally workflows would traverse the enterprise from concept to cash. But the reality is that enterprise-level flows are not easily managed or visualised with the current generation of tools. This talk will introduce a next-generation Kanban tool that scales from individual contributor to the team, and up to the enterprise. It's unlike anything you've seen before, and will get you thinking anew about enterprise-level Kanban.