Blog
: Kanban
Wednesday, August 29, 2012
A Taste of Lessons #10: Understanding Agile
Today’s taster from my new Lessons in Agile Management book comes from chapter 10 - Understanding Agile. The chapter threads together a series of articles from 2003 onwards that seek to put some underlying framework to Agile principles and values and to explain how Agile is differentiated from earlier 20th Century approaches to software development. As I explain in the chapter introduction, I’d argued at Agile 2008 that an underlying model for Agile was required - something more rigorous than the “Principles behind the Manifesto” - and that the Agile Alliance board had discussed it, decided it was important but no one was willing to commit to making it happen. As Dave Snowden has pointed out, an underlying model is required in order to scale concepts successfully. Chapter 10 brings together my own thoughts on an underlying model to help you understand Agile and hopefully from that understanding become more successful implementing it at scale. The extracted article is from February 2007 and includes from contemporary commentary…
Making Progress with Imperfect Information
Contemporary Commentary
My depth of understanding of Agile values, principles, and motivations continued
to grow through the middle part of the last decade. While I’d identified high levels
of social capital, or trust, as perhaps the true differentiator of the Agile era,
I came to realize that there were some other dimensions. The one that had been
hiding in plain sight, as a practice, became evident to me as a principle around the
winter of 2007.
I’ve been re-evaluating my view on refactoring!
It’s interesting how your vantage point can color your view of something.
My perspective on the Agile community and its practices has always been rooted
in my experience with Feature-Driven Development and the Coad Method.
When I spoke at USC back in 2004, I suggested that although Feature-Driven
Development might never be seen as the most agile of Agile methods, it was
probably the most Lean. I stand by this comment three years later. FDD is very
Lean. All the waste is trimmed out. The Coad Method techniques deliver a precise
definition of a domain that is loosely coupled and highly cohesive, while
the Feature definition technique delivers fine-grained customer-valued units
of work that exhibit very low degrees of variation in size and complexity. The
batching technique of Chief Programmer Work Packages is very efficient and
minimizes transaction costs associated with work-in-process. I could go on, but
you get the point—FDD is Lean. The modeling, planning, and batching for design
and build result in almost no need to refactor code on FDD projects. As a
result, my book, Agile Management for Software Engineering, classified refactoring
as rework, and labeled it as waste.
From my FDD vantage point, that might have been a fair assessment.
However, now that I’m running a software-engineering organization, with which
I inherited a waterfall process that runs through a series of narrow and specialized
departments such as Business Analysis, Systems Analysis, Development,
and Test, I’ve changed my opinion. From a new perspective, refactoring is clearly
a very valuable process.
I believe that Alistair Cockburn’s paper from the ICAM 2005 InternationalConference on Agility will come to be seen as a seminal paper in Lean Software
Engineering. In this paper, Cockburn explains that asking a non-bottleneck resource
to do extra work to rework something does not cost anything extra, and
it can create a desirable effect because it allows progress to be made and demonstrated
sooner. Ergo, rework is not waste when performed by a non-bottleneck
resource.
There have been many versions of the idea that perfect is the enemy of
good enough. Its origins are perhaps traced to Voltaire, who said, “The best is
the enemy of the good.” And it is this concept that refactoring (and Cockburn’s
paper) embrace. He argues that it is better to make progress with imperfect information,
and refactor later when better information is available, than to wait
for better information before progressing.
Specifically, I am thinking that it is better for developers to start coding
with imperfect analysis than to wait for a systems analyst to produce a “perfect”
specification.
Contemporary Commentary
I’ve come to realize that this notion is at the heart of eXtreme Programming,
and it was described in Kent Beck’s seminal book on the topic, Extreme Programming
Explained—Embrace Change (Addison-Wesley, 2e, 2004). Beck refuted, though
without any truly scientific study, Boehm’s finding from 1976 on cost of change.
Boehm’s work and subsequent corroborating evidence suggested that late-breaking
changes cost exponentially more. The Boehm evidence on the economics of
software development favored the pursuit of perfect information early in the
lifecycle. This ultimately led to the development of more and more analysis and
design techniques that pursued greater and greater levels of information discovery
earlier in the lifecycle. The core mistake is to assume that this is even possible.
The nature of software development is too complex for this to work. What
is required is to probe for more information with partial or approximate solutions,
and implement a feedback loop so as to iteratively pursue the answer. Boehm’s
later work on Spiral Model in the 1980s showed that he understood this. The rest
of the industry did not. Ultimately, the pressure from heavyweight processes,
laden with analysis and design techniques, was to provoke the Agile revolution in
the late 1990s. So, while a true differentiator of Agile methods is their embracing
of a high-trust culture—with all the benefits that delivers—the true essence of
Agile is the concept of moving forward with imperfect information and being prepared
to rework later. Rework wasn’t waste in the traditional twentieth-century
quality-assurance movement’s understanding; rather, it was further information
discovery based on feedback.
The developer can then refactor the code when the analyst makes
a final version of the specification available. My reasoning is simple. The developer
would otherwise be idle. (Not truly idle, as there is plenty of busy work
available—grooming environments, training on new languages and APIs, and so
forth, but idle in the sense that he or she is not adding value to the deliverable.)
By definition, a resource (or station) with idle time is a not a bottleneck resource.
It is, therefore, okay to ask a developer to perform refactoring. The refactoring
cannot be classified as waste in a case like this.
We can think about this decision using real-option analysis. The option
we are buying is to deliver the working code sooner. The cost of the option is
the cost of having the developer start work before a final specification is ready.
The risk (or uncertainty) attached to the option is the risk that the early, imperfect
specification will be significantly different from the final specification, and
that any rework will take longer than waiting to start coding on delivery of the
final specification. Note that the rework may absorb all of the slack in the non-bottleneck
resource, turning it into a bottleneck and delaying the whole project.
This gives us a framework to decide whether starting early and refactoring is
the correct decision, or whether waiting and coding for “right the first time” is
the correct decision.
Posted by david on 08/29 at 12:01 PM
Agile •
Kanban •
Lean •
Permalink
Tuesday, August 28, 2012
What Kanban Coaches Do, and Don’t Do
I’m realizing that predominantly Agile coaches/consultants have a lot of
misunderstanding about what it takes to be a Kanban coach. Consequently, they
believe that Kanban is just another method they can deploy using the same
coaching/consulting techniques they use for Agile methods. This assumption
would be wrong. Not just a little wrong - completely wrong! As a result of
this assumption some Agile coaches wishing to offer Kanban as part of their
services and as a tool in their toolbox, may be undervaluing the utility of
attending my 3-day Advanced Kanban Masterclass for coaches, consultants and
managers.
What’s more interesting is that I don’t observe the same bias in
consultants from a different background such as CMMI, Six Sigma, Lean
(manufacturing), Theory of Constraint, Program or Risk Management. They don’t
arrive with the mindset that “Kanban is just another Agile method. So all I
need to do is learn the mechanics and deploy it like Scrum or TDD.” This is good
because you cannot (or at least, should not) deploy Kanban like Scrum or TDD.
So what exactly do Kanban coaches do, and more importantly what don’t
they do?...
Stop Advocating! Stop Evangelizing! Observe Instead
Perhaps the biggest challenge teaching an Agile coach to be a Kanban
consultant is to get them to stop advocating a position and stop evangelizing
Agile methods and practices. At its worst Agile is a religion - a belief
system with zealots who are beyond logical reasoning or debate. They have
blind faith that Agile is better. Even worse is that they may believe that they have been sent to
convert the heathen and turn them into true believers. These more extreme
Agile coaches may never make the transition to coaching Kanban. They simply can’t
let go and take a more neutral stance, by observing current processes and current
challenges and recommending a appropriate course of action.
Kanban coaches don’t advocate or evangelize. They observe and
advise.
There Is No Judgment in Kanban
A Kanban coach must never judge. The current situation is what it is and it
got to be that way because of the current people, their circumstances and the
demands of their customers. Wishing it were different is not useful.
Criticizing because current practices are not aligned with a trendy modern
approach or with a belief system is disrespectful.
Kanban consultants respect the current situation and do not pass
judgment upon it.
Is Kanban Appropriate?
Good Kanban consultants make a situational assessment to establish whether
Kanban is appropriate or not. We spend perhaps half a day of training on this
topic. I’ve given key note speeches advising when Kanban might be appropriate.
The summary is that kanban systems offer deferred commitment, control of
variability in flow, elimination of over-burdening, reduction of multi-
tasking, and better alignment with high level risk management decisions
regarding allocation of supply against various competing demands. If any of
these things are problems in the current process, such as committing too early
and then failing to delilver against a promise, then a (virtual) kanban system
might help.
The full Kanban Method uses virtual kanban systems and several other
practices to create an evolutionary capability within an organization and
promotes evolutionary change. This is useful in complex domain situations that
are almost always present in knowledge work.
A good Kanban coach assesses whether Kanban is appropriate before
recommending it! You don’t ‘sell’ an evolutionary approach to a
revolutionary client. Situational awareness is a critical skill for Kanban
coaches.
Kanban Should Be Like Water
Water flows around the rock. The rock is emotional resistance to change -
change that will lead to better economic and social outcomes for all
stakeholders and lead to better satisfaction all round. Kanban coaches learn
how to anticipate emotional resistance - to identify the rocks before they
design and deploy a kanban system process solution.
Kanban coaches avoid rocks initially! Where a rock cannot be avoided
they design the kanban system to raise awareness and create emotional
motivation for change. Water smooths out rocks over time. Good Kanban coaches
know that it takes only one of them to change a lightbulb, but the lightbulb
must really want to change. Creating the circumstances for self-motivated
change is the work of great Kanban coaches.
(Virtual) Kanban Systems Design Is An Advanced Skill
Great Kanban coaches know they must not try to force change that will meet
with resistance. They must avoid designing a (virtual) kanban system that
fixes all the dynamic system problems they may have identified from initial
observation. Perhaps the solution to over-burdening - introducing WIP limits -
will meet with resistance? This resistance can be predicted by understanding
the emotions of those involved - how such a change affects their self-image,
self-esteem, ego, social status, or other psychological or sociological
elements.
The art and science of great (virtual) kanban system design for knowledge
work processes is knowing where to stop and knowing how to create a situation
that will raise awareness and create motivation so that the next step can be
taken.
Identifying Quality Kanban Consulting
It is for all these reasons that we teach an intensive 3-day Kanban
coaching class that assumes the attendees already know all the material from
the 2-day class and from the Kanban book. The 3-days are not a refresh on the
2-days plus an extra day, they are 3-days of learning new coaching skills.
Because Kanban coaching is such a special set of skills and so decidedly
different from Agile coaching, Lean-Kanban University has created a
professional designation, a trustmark, so that clients can identify those known to
be good, trustworthy, competent Kanban coaches and consultants. For this
reason the Kanban Coaching Professional (KCP) designation has been introduced
and my 3-day Advanced Kanban Masterclass is the prescribed educational
prerequisite for achieving KCP status.
P.S.
If you are interested in taking a 3-day Advanced Kanban Masterclass for
coaches, consultants and managers leading Lean change, we list them on our Events page. You will
be very welcome.
Posted by david on 08/28 at 04:55 PM
Agile •
Kanban •
Lean •
Permalink
Accredited Kanban for IT Ops and DevOps - Seattle - Nov 6-7
with Dominica DeGrandis (instructor)
Kanban for DevOps seeks to improve interactions and dependencies between teams and departments. From business requests to IT delivery, we discover how to improve work flow across different functional teams. Devops is about respect, cooperation and trust among individual practitioners and leadership. With Kanban, we look at how using a service-delivery approach can help unify teams and promote cross-functional collaboration.
This 2-day workshop introduces the Kanban Method and its associated principles and core practices. Exercizes are designed to bring visibility to the problems in need of improvements.
We begin by studying the demand on your team, department or organization and learn how to gather data to understand the capability of your system and how it operates.
Discussions and interactive exercises on the Kanban Method will address the following topics:
- Specialization and shared services
- Dependencies between teams
- Variable task size
- Interrupt driven work
Participants will analyze and design a Kanban system intended for implementation upon return to the organization.
We will also look at how to manage risks related to the increasing complexity around software delivery and support. Attendees play the “Kanban for DevOps” version of the GetKanban game.
Class Schedule
|
Day 1
Kanban Mechanics
- Demand Analysis
- Workflow Mapping
- Visualization
- Work Item Types
- Work-in-progress Limits
- Classes of Service
- Kanban Simulation Game
Day 2 Kanban Progression
- Kanban System design
- Operations Review
- Devops Case Studies
- Risk Management
- Metrics
- Variability and predictability
- How to Get Started with Kanban
|
Based on David J. Anderson’s book “Kanban - Successful Evolutionary Change for Your Technology Business”, attendees of the class will receive a copy of the book.
What others are saying about this training
“What a worthwhile use of my time! It is rare that I walk away from professional training feeling so inspired and fulfilled and wanting to tell everyone about it!!” - Jane Despas, Cloud Services, Cisco
“Dominica, Thank you for the great kanban for devops training. I learned how to use kanban to illustrate my work.” Alex Honor, Co-founder, DTO Solutions
“I was in your Kanban training earlier this week – thank you. I got a ton of useful information out of it and it has definitely prompted us to think about how we want to use one for our team.” - Kate Compton, IT Manager, R.E.I.
“The class was excellent. The minute our kanban board went up, everyone started asking questions and getting involved when they never had before. I am seeing managers take actions to investigate issues without having to escalate – a huge plus. The conversations alone are worth the effort!”
Betsy Hearnsberger, Release Manager, Cisco
Is this for you?
This training provides a useful perspective for improving work done on the periphery of software development. If ever-more frequent deliveries from software development are increasing pressure on your teams and creating bottlenecks in the delivery process, look at Kanban to extend agility and balance to IT services and operations teams. From Data Administrative Services to Deployment & Release Managers to Help Desk, this class covers beginning to intermediate level material.
Register today!
Only $1200 per person
Pre-requisites:
There are no formal pre-requisites, other than some suggested reading prior to attendance.
Group Discounts
A 4th person may attend for free with 3 registrations. Contact .(JavaScript must be enabled to view this email address) for questions on group rates or for payment options other than Google checkout.
Cancellation Policy – Please Note:
Substitutions are accepted at any time. Cancellations must be notified by email and refunds will be provided according to the following:
More than 10 days prior = 80% of course fee
5 to 10 days prior = 50% of course fee
Less than 5 days = no refund provided
DJAA reserves the right to postpone or cancel this event if there are insufficient registrations or if presenters are unable to attend due to illness. If necessary, you will be notified no later than 7 days prior to the event and all registration payments will be refunded promptly. If circumstances require, presenters may be substituted for alternative qualified presenters with equivalent experience.
About the presenter
Dominica DeGrandis specializes in Kanban for IT Services and Operations with teams interacting with software development. She spent her first 15 years in software engineering deeply embedded in development teams performing builds, deployments and environment maintenance. She has worked in organizations of all sizes, from the US Army, Boeing, and AT&T to small start-ups. Dominica first worked for David J. Anderson at Corbis in 2006 where she helped deliver the first implementation of Kanban for software engineering in the US. Adept at leading teams performing Configuration Management and Release Management, Dominica found a passion for improving the way development and operations teams work together. Dominica holds a BS in Information Computer Sciences from the University of Hawaii. She can be reached at .(JavaScript must be enabled to view this email address). Follow her on twitter at @dominicad.
Location:
Seattle, WA, USA
Venue:
University of Washington, Foster School of Business
Eastside Executive Center
10220 NE Points Dr, Suite 100
Kirkland, WA 98033
http://www.foster.washington.edu/academic/tmmba/Pages/ContactUs.aspx
Posted by david on 08/28 at 04:35 PM
Events •
Kanban •
Permalink
Monday, August 27, 2012
A Taste of Lessons #9: On Human Resources
Chapter 9 of Lessons in Agile Management collects a series of six longer articles I wrote expressing my managerial frustration with the policies imposed upon us managers by human resources departments, usually in the name of pay for performance. Some of the earlier ones reflect more of an “angry young man” stage in my career. Today, I’ve chosen to highlight the last of the articles, originally posted on March 14th, 2007. The contemporary commentary on this article had to be modified between printing the galley copies in May and final publication in August and I’ve added an additional post script exclusive to this blog…
Where Comparative Pay Scales Come Unstuck
How do pay scales come about? How do job descriptions get assigned
to a pay grade? How do compensation bands get assigned to those pay grades?
And how do HR departments decide how much is fair pay to offer a candidate
applying for a job? To be mildly unkind, they are thick as thieves with all the
other HR folks! They meet usually twice per year to compare pay scales and
compensation bands with other companies in the same metropolitan area or
industry, and they use salary surveys and other analyst research data to build a
map of what compensation levels are appropriate for particular positions. They
accumulate mean and median information, spreads of variation, and distribution
curves for different jobs. This data allows them to assess upper quartile, median,
and lower quartile pay, often accurate down to the percentile.
At a higher level, usually the executive committee of a business decides
which percentile or quartile they want to target for their employees. If for example,
an executive committee decides that their strategic positioning is as the
cost leader in a market, they might decide that as part of that policy they want
to pay only lower quartile salaries. Hence, low cost also means cheap or poor
quality staff, presumably leading to poor quality service and products—but at
a cheap price.
This would imply that an organization that wants to be merely mediocre
would instruct its HR department to enforce a policy of, say, median (or fiftieth
percentile) pay for its employees. Congruent, is it not?
STOP RIGHT THERE!
When did you ever meet a strategic planning department that would openly
state, “Our goal is to be mediocre!” How motivational do you think that would
be? Can you imagine the posters around the office—Master Mediocrity—Strive
for Median Performance—Competing is Better than Winning!
And you get my point!
Companies that state, “We want to be Number One in the [insert subject
here] market,” “We will dominate the market for [insert product] in [insert geographical
region],” and so on, are declaring that they want to be the best. So
how do you reconcile that with, for example, a recruiting policy of targeting the
sixtieth percentile in an industry?
I like to call the proper alignment of goals with recruitment policy the
“Kenny Dalglish School of Management.” Dalglish was the most successful football
player ever to come out of Scotland.* Arguably he has to cede the position
as best-ever manager to Alex Ferguson, but Dalglish’s managerial record is very
impressive, having won the English league trophy on several occasions with two
different clubs. He took the second team, Blackburn Rovers, from the Second
Division to the championship in under five years and thus proved that he hadn’t
been lucky the first time around with Liverpool. Dalglish had a simple approach
to management. He believed that you had to optimize each part in the system
to be the best. So, if you wanted to concede the fewest goals in the league, you
needed to have the best goalkeeper. If you wanted to score the most goals, you
needed the best striker. And so on. He consistently broke transfer records to sign
the best players to his team, thereby denying those players to the competition.
His actions were aligned with the goals of his employer. Consider this snippet
from his Wikipedia page:
1994–95 saw Dalglish again break the transfer record, paying Norwich
City £5 million for Chris Sutton who along with Shearer formed a formidable
striking partnership. He had now spent £27¾ million putting
together a squad that could make a serious challenge for the ultimate
prize, the Premier League Championship. The challenge came and by the
last game of the season both Blackburn and Man United were pushing
for the title, Blackburn had to go to Dalglish’s former home Anfield with
United having to go to East London to face West Ham United at Upton
Park. Dalglish smiled as Rovers went 2–1 down to a late Redknapp winner
and the news that United had failed to get the result they needed
filtered through to him via the radios in the crowd.
At Blackburn Rovers, club owner Jack Walker wanted to win the
championship. He hired Dalglish to make it happen. Walker wanted to be
number one. Dalglish hired the best by paying the most and delivered the
prize.
Now ask yourself this, “Are your employer’s strategic positioning and stated
goals aligned with the recruitment and compensation policies?”
Further, consider whether one blanket policy—a one-size-fits-all approach—
to define the targeted pay band is appropriate? For example, if your employer
has a goal to be number one in service, but a goal of lower costs in widget manufacture
because the widget market is coming under price pressure and has been
commoditized by competitors, would you have a single policy on recruitment
and compensation, or would you tailor those policies according to your strategic
plan? Mightn’t it be better to have an upper-quartile policy for people who can
deliver on the goal of being “number one in service,” while other areas of the
business might rightly have a third quartile policy?
Contemporary Commentary
As this book goes to print, Kenny Dalglish has just been fired from his second
stint as manager of Liverpool Football Club in England. He took the position initially
on a temporary basis during the 2010–2011 season. In the beginning, he appeared
to rely on his stature and reputation to inspire the team to improved performances.
In the summer of 2011, he was rewarded with a three-year contract.
Once again Dalglish entered the transfer market and paid high prices for three
of England’s top international players. During the 2011–2012 season, his team had
mixed results. They performed well in cup competitions, winning the trophy traditionally
known as League Cup and reaching the final of the Football Association
(F.A.) Cup. Performances in the Premiership league competition were lackluster,
resulting in a mid-table finish.
P.S.
This article was written at a time when I suffered the frustration of working with an HR
department that had a stated 3rd quartile compensation strategy for all employees across
the firm regardless of function or relevance to the company’s ambitions. However, the incoming
CEO had wanted to position the future of the firm as a world class innovator and leader
in the field of digital intellectual property rights management. To build the kind of IT systems
that would meet his expectations and impress the company’s owner
was going to require some of the staff to be better than the mediocre level implied by 3rd quartile compensation.
Also put yourself in my position as a middle manager and junior executive being
told by the HR associate that the policy is 3rd quartile compensation. The implication is
either “that’s right we think you are mediocre too” or “hey, you’re only here because you
were cheap.” Are you feeling inspired? I’d like to think it was the latter reason in my personal case 
Posted by david on 08/27 at 01:58 PM
Agile •
Kanban •
Lean •
Permalink
Sunday, August 26, 2012
Develop Change Management Capability
This is the second post in my series related to change management and
evolutionary capability, following Change Management vs Process Evolution on Friday.
It seems our world is full of lots of advice on how to do things better, or
properly, and suggestions on what we should improve and to what we might
change. However, the advice on how to introduce, lead and manage change is to
found elsewhere. The Capability Maturity Model Integration (CMMI) - a model
for process improvement - does not contain a process area for Change
Management. The Project Management Institute (PMI) does not have a Community
of Practice (CoP) for Change Management or even Process Improvement. It seems
to me these are massive omissions.
I believe that managers need to be pro-active about building a Change
Management capability and looking beyond traditional 20th Century managed
change, they should be architecting their organizations with an evolutionary
change capability - pro-actively developing and nurturing such capability.
CMMI
As regular readers know, I’m very familiar with the Capability Maturity
Model Integration (CMMI), both understanding its history and roots in the work
of Deming and Crosby, and in my observation that we don’t need an Agile
Maturity Model because Agile transitions and organizations maturing while
adopting Agile methods, appear, by-and-large to follow the existing CMMI
model.
Proponents of CMMI advocate that it is a model for process improvement and
many CMMI based change initiatives are based on “filling in the gaps” between
what the model suggests and the current appraisal of the organization. In
order to “fill in the gaps” a change initiative is planned and managed -
perhaps over several years. Strange then that the CMMI omits Change Management
as a required capability. It appears that appraising the change management
capability of the organization and accurately assessing the organizations
ability to successfully implement the changes a CMMI appraisal might suggest,
is left as an exercise outwith the scope of the CMMI, or the
process improvement initiative.
It seems to me that it is either assumed immature organizations have the
capability to manage complex elaborate change programs despite the fact they
can’t manage complex and elaborate projects and programs, or, it is assumed
that somehow the CMMI Lead Appraiser’s consulting firm will do it for them.
This assumes that the client company has a strong capability at vendor management which
it almost certainly doesn’t - this would have been revealed in the appraisal
one way or the other, but it is generally not a strong capability of most high
tech firms and software development organizations.
PMI
Meanwhile, the other strong source of traditional advice and guidance, the
PMI, seems to have a narrow and myopic focus on projects and portfolios and is
blind to the greater organizational requirements needed to run a successful technology business.
Why is there no Community of Practice for process improvement or change management within the PMI? It seems
to me that these capabilities must not be valued in the project management
tribe. Hence, they have no traction. And yet, if PMI guidance is to be implemented successfully, organizations must manage change. Another one for the consultants perhaps?
Success Lies in Managing Change
From the comments to my first post in this series, it seems the message
that change initiatives fail more often than projects, resonates with many.
Any yet, senior managers are seduced by big ambitious change initiatives over
and over. The utopian nirvana of the promised end-state is like a shiny new
object that romances them and they fall blindly in love with its promise. This
blindness extends to the failure to recognize that they do not oversee an
organization capable of managing such a change nor selecting and managing a
vendor capable of assisting them with it.
So what to do?
Like every other required capability, you need to learn and practice change
management. Start small. Practice it often. Gain confidence from small
successes. Learn from small mistakes. Implement fast feedback loops on small
changes to enable learning.
This begins to sound a lot like Kaizen - small changes, implemented often -
continuous improvement! Like continuous deployment - you get good at it by
deploying and by gradually learning how to do it more often - and you learn
that it is more successful when you do it often and in small steps - like
automated unit and regression testing - small check-ins often lead to more
successful results and develop capability. And so it goes with change
management - start small, implement small changes often, learn from the
experiences and improve, gradually larger changes will be possible as your
capability grows.
As we already know, Kanban is a means to implement a kaizen culture and
develop small, continuous improvement capability. Hence, implementing the Kanban
Method is a means to develop change management capability.
Conclusions
Change Management is a heavily overlooked and under-rated organizational
capability. Change Management is missing from the models, advice, guidance and
communities of organizations we’ve traditionally looked to for guidance and
authoritative advice on managing technology development businesses. Successful
change initiatives require a strong organizational capability in change
management. Organizational capability is build by starting small and
practicing often. Kaizen is a means to build such capability and Kanban is a
means to implement Kaizen. Implementing the Kanban Method in your organization
can lead to greater success delivering significant change initiatives.
Posted by david on 08/26 at 06:05 PM
Agile •
CMMI •
Kanban •
Lean •
Permalink