Even though traditional models and assumptions represent thinking that originated in the 1890s with Taylor (fixation on efficiency and utilisation) and Gantt (of Gantt chart fame) they seem remarkably impervious to change.
Our problem is that we need to change otherwise we can never achieve true business agility.
In this talk I will contrast the differences between a traditional PMO and a Lean/Agile PMO, outline the value a Lean/Agile PMO can bring, and explain how Kanban can be used as a vehicle to move portfolio management into the 21st Century!
Learning is the new currency. Practices and processes will come and go; only the
wise survive. If you don’t know why you’re doing what you’re doing, Kanban nor
Lean, nor any other cool new thing will deliver the maximum benefit. And if you’re
not learning, you’ll never know what you’re missing.
When I talk to teams struggling with Kanban and Lean implementations, I find many
similarities. Some typical responses I hear:
Hear any common themes? These teams don’t have a clear outcome or purpose for
adopting Kanban. It looked cool, something previous wasn’t working, or someone
told them to do it – all extremely effective ways to NOT get the maximum value out
of Kanban.
In each of these cases, when I refocused the team on learning, perspectives changed.
Asking the following question changed their focus.
How are you using Kanban to learn about: The product you’re building? The project?
The technology? The domain? The users? The market? The delivery? Your team?
And Improvement?
During this talk we will explore (or re-explore) why you are using the tools and
processes you are using. Did you make a wise choice or just pick the latest flavor
of the month? Brace yourself for a high-impact, interactive, and introspective
rediscovering of your first love: No, not Kanban… your brain.
There is a deep cultural belief in Australian business that 'there just has to be a better way'.
In 2009 the small team of legal affairs professionals at Lonely Planet headquarters in Melbourne had witnessed first-hand the transition of an IT and digital product organisation to agile and kanban methods, and they suspected many of the principles could work for them too.
Focusing on customer value, flow of work, and waste elimination as their key tenets, they transformed their team from an order-taking shared service model (with an invisible workload) to running a sustainable pull system with a sophisticated wip-limited kanban board, where work is not 'done' until the first value flows from a contract.
This case study shows how a profession built on adherence to long-standing command and control culture can through application of lean, agile and kanban principles become an influential innovator among their knowledge worker peers in a global organisation.
"Kanban rocks" is the motto of more and more people in the IT industry. That is for good reasons: Kanban follows simple rules, is based on easy accessible mechanics, easy to implement, and leads to significant improvements within a short period of time. However, a lot of Kanban initiatives vanish as quickly as they were introduced. That is also for good reasons: People are trying to break emotions with a crowbar instead of using them as drivers of change. Introducing Kanban means doing a change initiative - it is about people and not pure mechanics, it is targeting the working culture, and it is team sport in terms of shared leadership and accountability. In my presentation I will point out a way that addresses these essential aspects of a Kanban change initiative so that an emerging culture of continuous improvement has a chance to survive.
Early adopters of Kanban in the IT services realm are designing systems which consider high levels of interrupt driven work and big differences in task size. This work doesn't typically drive revenue and thus creates unique challenges. Add to that, the conundrum of handling dependencies, distributed teams, and shared resources, a kanban design for IT Ops may look very different than a Kanban design for development. This talk covers real world examples from IT teams working to optimize the whole of their organization.
Visualising work is a key part of the Kanban Method. In many situations it can lead to people realising there are problems or opportunities for improvement, which can be successfully accomplished by simply changing behaviour (single loop learning). However, in some situations, these change may require challenging existing mindsets (referred to as double loop learning). Using practical examples drawn from directly helping teams, this talk will present a model for understanding how we can proactively engage in conversations that increase the chances of capitalising on the value that visualising the work provides.
I first learned about a Kanban approach to development from an apologetic agile practitioner concerned that they’d broken “the rules.” Although it’s common practice, fixed time-boxes aren’t a required strategy for agile development. Since Kanban’s broad adoption, I’ve continued to encounter a number of myths and misconceptions both for and against Kanban. In this short talk I’ll review my top 10 myths and misconceptions, along with a few neglected and important principles of Lean thinking that many in software development, including Kanban practitioners, neglect.
There is a war going on, tragically consumed behind corporate walls. It’s a war of worlds, a war of cultures, where the few who command & control systematically crush people’s hearts and minds. Frontal attack is futile. We like to call ourselves change agents, right shifters, sensei, coaches. We prescribe our medicines and leave. But what change does really happen? How long does it last? Imagine, however, what it would be like if someone offered you a practical way to dig into deeper forms of thinking, turn fire fighters into problem solvers, share and celebrate every victory – however small, and make improvements an everyday part of an entire organization. What would you do? How far would you go? In this award-winning session, Claudio will unleash the power of story to throw you into a world where specific Lean problem solving techniques, Kanban and quick Kaizen systems are leading managers and teams of a large organization to a path of continuous improvement.
Are Classes of Service always applicable in Kanban system design? Why or why not would a team choose to use a Class of Service scheme? Is it possible to know whether the introduction of Classes of Service has been a benefit or detriment to a system’s performance? This interactive session will be an in-depth discussion around the pros and cons of a Class of Service approach in Kanban.
Many teams, individuals and organisations are delivering projects - or at least they think they do! In reality most of them are developing products, i.e. web services or inhouse applications. The whole concept of project development was useful some years ago - as our industries were unable to lower transaction costs and release frequently. Nowadays not only do we have the technical possibilities for continuous delivery; In addition Kanban provides us with the right framework to spot and manage buffers and to make good decisions regarding the correct batch size.
This talk will show the differences between thinking in projects vs. thinking in products and the benefits that arise from switching to the latter.
This session is a hands-on Kanban System Design simulation. Teams will design their own Kanban systems, taking into account work item types, skills available, capacity, etc, execute them for a period of time, then compare and discuss the outcomes.
The scenario is an Operations team which has three types of incoming work: Incidents, Change Requests, and Project Tasks. Points are won or lost based on timely completion of work items. Different specialized skills are required, such as networking, database administration, desktop support, etc.
Game instructions are provided in the attached PDF. Given the short session duration, please read the instructions prior to the session to reduce our startup time.
Click here for game instructions.
Patterns describe a problem for a given context and offer a solution based on experience that has been consistently successful. A pattern language of flow, if it existed, would attempt to identify problems with the flow of work in software development from request to release. The existence of problems could be confirmed with the use of empirical data and visualisations. Solutions could also use empirical data to inform better economic decisions and create the catalyst for change.
This talk will outline successful flow based strategies used in the software industry to build the right thing, improve quality, increase throughput or reduce the time it takes from the request of a feature until its delivery. The strategies are based on the experience of the author along side development communities in New Zealand and the UK, making them candidates to form the basis of a Pattern Language of Flow in collaboration with the wider community.
Note: Twitter will be used to interact with attendees throughout the session @gareth__evans (double underscore)
Are you tired of the myth that Scrum, XP and Kanban do not scale to the needs of the larger software enterprise? Are you tired of the ideologies that prevent your enterprise from even trying to apply them? If the answer to either of the above is yes, this presentation is for you.
In this presentation, Dean Leffingwell will finally dispel these myths and ideologies by describing the Scaled Agile Framework(TM), a public-facing set of practices which have been used to successfully scale Lean|Agile development to hundreds--and even thousands--of practitioners at companies like BMC Corporation, John Deere and others.
He'll describe five key scaling mechanisms:
However, since simply making Agile things bigger does not necessarily keep a system lean, Leffingwell will describe how the framework a) keeps work in process visible and limited, b) keeps backlogs and queues short, c) uses cadence and synchronization to manage variability and align teams to a common mission, and d) applies system-level continuous integration to facilitate fast customer feedback.
Lean/Agile is not just about delivering early and often, it is even more importantly about continuously adapting the way we work towards an improved capability of delivery. Yet how many of us have worked in a continuously improving organization? How many of us have seen one in real life?
It’s hard to keep management interested in Improvement for very long, making Continuous Improvement a holy grail of sorts. As Lean/Kanban practitioners we believe the only sustainable way to improve is via evolutionary emerging change. But if we the organization is not interested in pursuing it, we have a big problem.
Through some challenging situations from real client work we will see a few patterns that fail and a few patterns that show more promise for energizing improvement. We will also look at improvement pace and how to apply kanban approaches to make the improvement more sustainable.
We will also explore some local cultural aspects that might affect the drive (or lack of) towards improvement, and how to deal with them, with some interesting insights about the Israeli culture…
As Lean and Agile transitions from small teams to large organizations, and from progressive organizations to more pragmatic organizations that demand evidence for decision making, a new set of challenges emerge. While many have rightfully encouraged the use of qualitative insight by those closer to the work we can no longer avoid embracing metrics to demonstrate the value of adopting certain practices. Kanban is about visualizing the work but it's also about providing quantitative feedback in the form of lead-time and other metrics.
This talk introduces a disruptive new form of quantitative feedback, the Time In State InSITe visualization for visualizing any time in state data, and walks through in detail the use of a particular instantiation, the Time in Process (TIP) Chart for visualizing lead-time data. It is intended to be used in situations where misapplications of control limits often occur. The talk also provides guidance about the problems with control limit calculations used in this domain to motivate the reduction in misapplication.
Lastly, it introduces the ODIM framework intended to guide metrics choices and avoid misapplications like that which has happened with the use of control limit calculations. The ODIM framework is built upon the thought that better [M]easurement/Visualization leads to better [I]nsight leads to better [D]ecisions leads to better [O]utcomes. It's ODIM rather than MIDO because, like reading a kanban board, it's best to start from the right (Outcomes) and work your way left when making measurement choices.
