Wednesday, October 03, 2012
Advanced Kanban Masterclass - Charlotte NC - Nov 15-17
This 3-day masterclass is for advanced Kanban practitioners, consultants, coaches, change agents and managers. Spend 3-day of intense study with pioneer of Kanban, David J. Anderson. This workshop is limited to just 12 people. Achieve the educational requirements for the Kanban Coaching Professional designation from Lean-Kanban University.
This 3-day masterclass with the pioneer of Kanban is for anyone tasked with leading a change initiative in their organization or at a client organization in 2012 and beyond. It is suitable for managers, process engineers, change agents, experienced process or project management coaches and consultants. Existing Kanban practitioners with 1 year of experience, or those who have previously taken an accredited 2-day Kanban class and are actively using Kanban at work are welcome. Attendees are expected to be familiar with the content of the book, “Kanban - Successful Evolutionary Change for your Technology Business.
The Kanban Method takes a evolutionary, cultural approach to capability development, improvement and organizational performance. These intensive 3-day workshops are intended to transfer the knowledge and skills to enable you to lead Lean transformations using the Kanban Method. This is your opportunity to get your hard questions answered by the founder of the method and to develop deep ties in the community and network with fellow practitioners. All attendees will receive an automatic invitation to future Kanban Leadership Retreats - our series 2-day “consultants’ camp” format open space events for advanced practitioners and leaders in our community.
$3500 per person
A copy of the Kanban book in physical or electronic format will be supplied upon registration. Attendees will maximize the value if they are already familiar with the material. Attendees who already have a copy of the Kanban book can opt to receive a copy of Lessons in Agile Management in hard copy format only, as an alternative.
The intent of limiting the workshop to a maximum of 12 attendees (typical attendance is around 8 people) is to have an interactive collaborative session designed to facilitate knowledge sharing and learning. Attendees should come prepared to discuss their own experiences with Kanban and challenging situations they’ve faced with change initiatives at clients or employers
The workshop will open with a round table of introductions and shared Kanban experience. Each participant will be asked for a list of questions they’d like answered over the 3 day session and from this a topic backlog will be built. David will augment this backlog with essential topics and foundational material. The agenda for the remaining time will then be set to insure the fullest of coverage and the maximum value for all participants. The focus will be on shared experience and discussion of the hard questions that clients and team members ask coaches during the introduction of Lean ideas through the use of a kanban pull system. The workshop will include the use of the Kanban Sim by Focused Objective and the option of playing the GetKanban game simulation during one evening. The objective is to understand the use of games and simulation as tools for training and planning in the workplace.
The goal is to enable participants to go back into the field and successfully coach Agile/Lean transitions using the Kanban approach. Every workshop is different because of the unique experiences of each participant and their specific focus and desired outcomes. Each participant will have completed the educational requirements for the Kanban Coaching Professional (KCP) designation from Lean-Kanban University. Proceeding with, and achieving KCP status is optional and will require participants to submit an application to Lean-Kanban University and present to a review panel who will examine their experience and knowledge before granting KCP status.
Kanban offers process coaches and managers another tool in their transformation toolbox. It offers an evolutionary approach to change that focuses on the culture of the organization. Attendees will be introduced to the 3 Kanban Kata that are core to the approach. Kanban is proving to be a facilitator of evolutionary change with low resistance and an enabler of accelerated achievement of high levels of organizational maturity. Organizations embracing Kanban have been seen to improve predictability, risk management, governance and their capability to manage and embrace change.
Location: Charlotte, NC USA
Posted by david on 10/03 at 10:43 AM
Monday, October 01, 2012
New Class Aimed at Developing Change Management Capability
Over the summer I blogged my thoughts on why developing a change management capability was so vital to enable successful process transitions and improvement initiatives. My own approach is cultural and focused on developing an institutional evolutionary capability. However, I recognize that just being able to managed a defined transition is a challenge. So I’ve teamed up with Bob Lewis of IT Catalysts to offer a new 2-day class aimed squarely at teaching IT organizations how to develop a change management capability to successful lead and management improvement initiatives. The first of these classes is being offered in Washington, DC, later this month…
I’ve admired Bob Lewis’ work since the mid-1990s. I remember my boss, Jeff De Luca, program director of the now famous “Singapore project” where Feature-driven Development was born, was a big fan. Bob has been the face of plain speaking, no nonsense, pragmatic, actionable guidance for at least a couple of decades. As an experience CIO, his IS Survival Guide, remains one of the most useful books on management and most practical guides that a new manager in the IT can field can read. Bob’s pragmatic, realistic approach influenced our thinking back in Singapore and has guided me on my journey since then. I’m delighted that Bob has agreed to be a key note speaker at our Lean Kanban North America conference in Chicago next May. I’m sure that our growing community will enjoy his pragmatism and embrace his challenging skepticism about Lean in IT work.
Business Change Management Seminar
Meanwhile, who better to partner with to develop a class on organizational change management capability than the author of Bare Bones Change Management? I recognized that Kanban and institutionalizing evolutionary capability may be important but providing a framework for change management across a whole IT organization was probably a more pragmatic first step. Meanwhile, why reinvent the wheel. Bob Lewis has a tried and tested framework and an unquestionable credibility in this space. It was logical that we should team up to offer a 2-day seminar on business change management for your organization.
Our new 2-day seminar brings together Bob’s 7 point framework for managing change at scale and synthesizes my ideas on changing organizational culture and developing evolutionary capability with Kanban. Together it is a powerful combination. We’ll look at why individuals resist change and what you can do about it. How to mitigate the risk of resistance and how to build the capabilities in your organization to lead and management successful change initiatives.
Who Should Attend?
Are you a CIO, VP or director facing new business challenges beyond the current capabilities or your organization? Do you need to lead change in order to deliver on expectations? Then this seminar is for you!
Are you a corporate change agent, process engineer, internal coach or external consultant tasked with implementing change to deliver on urgent and critical business needs? Then this seminar is for you!
Most change initiatives fail. Most attempts to adopt new and improved methods, such as Agile or Lean, fail, not because these methods are poor but because the organization lacks the capability to manage change. Don’t waste your investment on Agile or Lean! Improve your chances of success by properly understanding how to manage change and what you must do to create an organizational change management capability. This seminar is packed with pragmatic actionable guidance that will enable you to return to your organization and put in place the skills and capabilities to deliver successful change and successfully meet your business challenges in 2013.
We’re offering two of these new classes in 2012. The first in Washington, DC at the end of October and the second in Los Angeles in December.
Register now for Business Change Management, Washington, D.C., Oct 29-30
Register now for Business Change Management, Los Angeles, Dec 3-4
Change Management versus Process Evolution
Develop Change Management Capability
Adaptability versus Evolutionary Change
IT Catalysts Inc
Posted by david on 10/01 at 10:52 AM
Monday, September 24, 2012
Lean Kanban Netherlands - Register Now!
The program for Lean Kanban Netherlands was announced over the weekend. The conference is only 1 month away. It is time to register for the best Kanban content in Benelux this year. Don’t miss your chance to network with some of the best international speakers and the leaders in Lean and Kanban in Benelux. Register now! Read my thoughts on the program…
This year’s Lean Kanban Netherlands conference in Utrecht picks up where previous Lean Kanban Benelux events in Antwerp left off.
I’m thrilled to see Enterprise Kanban, Personal Kanban, Kanban for Social Change and Kanban for IT Operations all represented on the program. David Joyce from Australia, Jim Benson, Janice Linden-Reed and Dominica Degrandis from Seattle in the United States get the first day off to a roaring start. For those who’d rather have some local content there are sessions by Patrick Steyaert, Nick Oostvogels and Laurens Bonnema. Perhaps the highlight of the day may be the combination of the key note from Steve Medland on Toyota Kata immediately followed by Hakan Forss presenting his Kanban Kata.
Moving into the second day the quality continues with key notes from Don Reinertsen and Stephen Parry and some great sessions. My particular favorites are Kurt Hausler, Jabe Bloom and Pawel Brodzinski.
So if your interest is in personal productivity, wider application of Lean to social concerns, scaling Lean in the knowledge worker enterprise, or applying Lean ideas to IT services and operations, there is plenty of high quality sessions to hold your attention. The Netherlands Lean Kanban conference offers you a fantastic chance to meet the speakers, the leaders in the Kanban commmunity and the coaches and consultants who are leading the evolution of knowledge work in Benelux. Don’t miss out on this chance to build your network and get a head start on some of the brightest ideas for improving productivity and customer satisfaction in IT work.
Register now! October 25-26 is just around the corner. Don’t miss out!
Posted by david on 09/24 at 11:34 AM
Sunday, September 09, 2012
A Taste of Lessons #11: Agile Practices
Today’s extract from Lessons in Agile Management republishes a classic from 2005. This post was inspired by the then emerging and now infamous XIT sustaining engineering implementation of a virtual kanban system at Microsoft. It’s at the root of the myth that you don’t estimate in Kanban. Such dogmatic, context free guidance has never been part of Kanban. The truth is that effective Kanban implementations will have people who make considered decisions about the economic and risk management value of estimating and decide whether or not it is appropriate for any given type of work or class of service.
Calling out estimation as waste was always going to be controversial in the Agile community. I was threatening one of the sacred cows. A defensive tribal reaction was inevitable. Seven years later, it still provides ammunition for those who would argue Kanban isn’t Agile!
Why Estimates are Muda
First published on September 27th, 2005
I’m getting a reputation as a bad boy of project management! My advice
to stop estimating doesn’t go down too well with the traditional PM community.
It doesn’t sit too well with some of my new friends in the traditional softwareengineering
community either—their Personal Software Process/Team Software
Process (PSP/TSP) method is based around estimating and then tracking
estimates against actuals. My dislike for earned value reporting isn’t too popular
either—particularly as the American government mandates it for certain types
of contracts. (I’m not overly fond of Scrum burndown charts either—when they
are based on time-on-task estimates rather than customer-valued work items
like user stories.) My agile estimating technique based on the velocity of clientvalued
work items seems natural to me. It seems like the Agile way. The simple,
easy-to-calculate way. The doesn’t-waste-any-time way. And this is what I want
to talk about today—doesn’t-waste-any-time! Traditional estimating is muda!
Agile estimating isn’t! Here is why:
Let’s assume that software development is the capacity-constrained resource
in our organization. Even if it isn’t, we wouldn’t want to waste slack capacity that
might otherwise be used to absorb variation elsewhere in our system. When
we spend time estimating something, and we use the capacity-constrained resources
to do the estimating, we effectively lower our capability. We lower our
capability on an activity that isn’t client valued. The customer doesn’t care how
long your estimate for a task was. Doing the estimate often takes a significant
chunk of time compared to the time it would take to do the work. Doing the
estimate even a few days (but more likely a few weeks or months, and, in some
cases, years) before the work is done means that anything you learned from the
estimating process is lost. It gets worse. Often we estimate work that gets cut or
doesn’t get done at all because the estimate is too large. Calculating a time-ontask
estimate doesn’t create customer-valued knowledge. Estimating is non-value
added. Estimating is muda!
On the other hand, I thoroughly embrace the idea that we analyze and partition
our problem space. In Feature-Driven Development, we analyze the work
into a domain model, and later we partition it into components. We further analyze
the work into Features and group them into Feature Sets and Subject Areas.
All of this analysis work gives us a work-breakdown structure that is entirely
value-added. All the work done analyzing for the Feature Plan is value-added.
It creates knowledge that is used to deliver the customer-valued functionality.
We then estimate based on feature velocity—an agile estimating technique that
takes almost no effort to calculate. Agile estimating based on analysis minimizes
waste of capacity in the capacity-constrained knowledge-worker resources.
So, to be clear—I am all for analysis that produces knowledge we can use in
the customer delivery. I am against estimation that produces information that
is not of deliverable value to the customer!
Analysis Rather than Estimation
First published December 18th, 2005
I’ve noticed some confusion over the difference between estimation
and analysis. When I’ve suggested that we stop estimating and focus on
analysis, some people have struggled to understand the difference. Again, when
I suggested that all estimates are muda, but continued to encourage the use of
analysis, some people struggled to understand the difference. So, I decided to
look up the dictionary meanings for clarification.
- to estimate: to calculate approximately (the amount, extent, magnitude,
position, or value of something)
to analyze: to examine methodically by separating into parts and
studying their interrelations
Now, for the nouns:
estimate: a tentative evaluation or rough calculation, as of worth,
quantity, or size; a statement of the approximate cost of work to be
done, such as a building project or car repairs
analysis: the separation of an intellectual or material whole into its
constituent parts for individual study; the study of such constituent
parts and their interrelationships in making up a whole.
It is clear that estimation is about quantification of cost, whereas analysis
is about the decomposition and integration of a set of parts. Analysis adds value
by creating knowledge about what components we need to create and how they
integrate together to synthesize a whole solution. Estimation merely quantifies
the cost. I believe that in our industry, people are lousy at estimating. And that
this may indeed be true of all knowledge work. Estimating knowledge work is
hard. It’s even harder without proper analysis. However, reliable and repeatable
analysis techniques—although they exhibit variation, and are seldom used perfectly—
significantly contribute to our understanding and planning of software
development and project delivery, do exist, and should be used. Analysis reduces
variation and makes plans more accurate. Estimation does neither of these
things. Agile estimating, on the other hand, uses historical productivity data,
and it uses the output of analysis to provide a reliable estimate with a buffer for
variation. The result is a plan that is more accurate, and the time spent on it was
value adding, knowledge creating, and decomposition and integration, rather
than inaccurate, non-value added cost quantification.
Posted by david on 09/09 at 06:19 AM
Adaptability vs Evolutionary Change
I found this recent Harvard Business Review blog, Agile Problem Solving at the London Olympics, by ROb Goffee and Gareth Jones thought provoking. It offers us a subtle understand of the difference between adaptability and evolutionary capability. Perhaps in turn offering us a way to understand Kanban in comparison to Agile methods…
Goffee and Jones’ observations of the British armed forces performing security duty during the London Olympics highlights the adaptability of these forces. At short notice, they were able to step into a role that isn’t a customary one for them and to perform well earning the praise of the public and critics. Goffee and Jones attribute this capability to a sense of professionalism and sufficient diversity in the backgrounds and experience of the personnel to guide them in how to behave in this domestic, non-combat environment. In doing so, the RAF and Parachute regiments showed their agility - their ability to adapt to circumstances and perform well.
Adaptability is core to concept of an Agile organization. However, it is also clear that adaptability doesn’t imply evolutionary change. Neither of the regiments mentioned have had to change in their organizational structure, training or culture in order to perform the security operation at the Olympic Games. Their behavior shows their flexibility, being able to adapt to circumstances and adopt rules of engagement very different from combat situations such as those in Afghanistan.
Military organizations do evolve though. Evolution tends to come with changes in technology that dictate how warfare is conducted. Both the RAF and the Parachute regiments are in themselves evolutionary mutations. Neither existed 100 years ago. The development of aircraft was the discontinuous innovation in technology that eventually provoked the emergence of both. Sometimes an evolution in the armed forces creates a whole new unit, at other times, technology or wider social issues change the organization - the cavalry replacing horses with motorized vehicles, for example, or the navy accepting women as sailors.
So adaptable organizations are like Swiss army knives - they can be configured in different ways and adjusted to a myriad of situations. Like Goffee and Jones, we’ve tended to use the term Agile to describe such organizations - an Agile software development team is one that is adaptable to changing circumstances - changes in requirements, a continuous flow of new project work, and changes in software technology, platforms, languages and tools.
Defining Second Generation Agile
However, a deeper interpretation of Agile is available. It could be used to describe an organization that is capable of re-inventing itself as circumstances change. It could be used to describe an organization that is capable of evolutionary adaptation - changing itself in order to remain competitive or relevant in a changing world. It is this evolutionary capability that reflects the higher form of agility - the higher form of Agile. Writing in the HBR blog, Goffee and Jones weren’t talking about this higher form of adaptation. They were referring to Swiss army knive configurability. We could equate this to first generation Agile software development methods - create the capability to embrace change and adjust to customer demands. In reflection, they help us to see what we mean by second generation Agile methods - methods such as Kanban. Second generation methods install organizational evolutionary capability - the ability for the organization to mutate, adjusting its structure, processes, roles and rules of engagement such that it can be fitter for its environment. Organizations with evolutionary capability have resilience - they remain relevant despite changing circumstances and maintain high levels of effectiveness as the environment around them changes.
Kanban is a means to install evolutionary capability and deliver on higher level agility. Evolutionary capability defines second generation Agile methods.
Posted by david on 09/09 at 05:29 AM