I have found that very few organizations are starting out
with Kanban as their first choice for their Agile implementation. Almost every
organization that I have been exposed to through training and coaching began
their Agile implementation with Scrum. Unfortunately, many companies have
significant organizational impediments to being a true Scrum shop.
Before I go
any further, I want to say that I am a Scrum believer. If there is a way to
implement “pure” Scrum, I believe you will have the most productive and happy
development teams. That being said, I have found that many organizations trying
to implement Scrum have significant “Scrum-buts”
and their implementations would be better served by stepping back and
considering a simple Kanban approach.
There are many different approaches to Kanban for software
development, and some are even proprietary. Since everyone else is attempting
to trademark their own Agile approach, from this day forward, I am
trademarking, “Simple Kanban™.” Just kidding… Anyway, the benefit of Simple
Kanban is that it assumes you already understand Scrum and User Stories and can
apply what you have learned in Scrum to Kanban. When I train on Kanban, I train
one day of Scrum and User Stories and one day of how to apply those practices
to a Kanban approach.
I can’t say that I am an expert in Kanban for software
development, but early in my career, I
did have some great exposure to Kanban
in manufacturing. In college, I majored in Industrial Engineering, and my first
“real” job was working as a sales engineer for an environmental controls
manufacturer. They used the Kanban pull system for inventory control, and as
part of my onboarding training, I spent three weeks on the shop floor. It was
an experience that left a deep impression on me.
While I worked there, they won the Shingo Prize for
world-class manufacturing and excellence in productivity and process
improvement; quality enhancement; and customer satisfaction. This award is
considered one of the “Triple Crown” industrial excellence awards, along with
the Baldrige National Quality Award and the Deming Prize.
Kanban was originally a lean manufacturing approach, and it
was developed in alignment with these 5 lean principles:
- Specify what creates value from the customers perspective
- Identify all the steps along the process chain
- Make those processes flow
- Make only what is pulled by the customer
- Strive for perfection by continually removing wastes
These lean principles I saw applied to manufacturing always
stayed with me as my career shifted to software development project management.
I was never a thought leader advancing my ideas beyond the needs of my
immediate project, but I was able to be “agile” before I even heard the term. I
was applying both lean principles and common sense to keep the development
teams productive and my customers happy.
Now that I am an Agile
Coach, I have formalized my common sense approach so the process is
repeatable and so I can train Agile teams. Here is how I implement Simple
Kanban:
1
Keep
existing functional teams: Most organizations are struggling with
eliminating roles, especially QA. One major reason that this won’t change is
because separation of duties is required for many IT shops with annual security
auditing requirements.
·
Business Analysts perform role of Product Owner
and write User Stories. They prioritize these Stories in the Product Backlog for
the development team which becomes the work queue for the team to pull from. Ultimately,
given the lightweight nature of User Stories, there will be fewer Analysts
needed.
·
Software engineers perform high-level design,
and identify the development tasks. For complex systems, it may require that an
architect or senior software engineer is on the team for this activity.
·
Software engineers continue to develop, write
unit tests, and advance Agile engineering practices such as continuous
integration. This is the same role they have been playing, but in a “pull”
environment they will be much more empowered.
·
Lastly, retain quality assurance team members to
perform functional testing. I still suggest that the Business Analysts and/or a
true Product Owner role exist to perform ongoing acceptance testing.
2
Utilize
User Stories: Kanban typically uses cycle time to size requirements. It may
be heretical for me to propose this, but User Stories can accomplish the same
thing, especially if the team members have already been trained on User
Stories.
3
To manage
WIP use functional velocity: Each functional team estimates the story
points for their work on a story. As with Scrum, over time, each team will know
their velocity and can commit to their work in progress (WIP) limits. They can
then work towards a stable time-based velocity which can provide the same
transparency as cycle time.
4
Team Size
is managed by Story Points: The number of business analysts, software
engineers and quality assurance team members is determined by the number of
story points in the functional queue and ultimately the release schedule. As
with Scrum, multiple small Kanban teams work better than one big one.
5
Self-Organizing
is the same as a Kanban pull system: When a team member is done with a
story, they go get more work from the queue.
6
Keep open
spaces: This is just a good idea. Regardless of your Agile approach, one of
the keys to success is having everyone in the same room.
It may sound complicated, but as with Scrum, after a few
cycles the team begins to work out the kinks. I agree that over time, cycle
time is a better approach for Kanban, but if you are moving from a Scrum model,
it may be an easier transition to retain the use of Story Points, and I have
seen teams be successful with this approach long-term.
Bottom line – keep it simple
.
About the author, Dan Tousignant, PMP, PMI-ACP, PSM I, CSP
Dan is a lifelong project manager and trainer with extensive experience in managing software development projects. Based upon his experience, he has adopted both Agile as the primary method for developing and implementing software. He is passionate about the leadership emerging from self-organizing teams.
Dan has over 20 years of experience providing world class project management for strategic projects, direct P& L experience managing up to 50 million dollar software development project budgets, experience managing multi-million dollar outsourced software development efforts and strong, demonstrated, results-driven leadership skills including ability to communicate a clear vision, build strong teams, and drive necessary change within organizations.
Dan holds a Bachelor of Science majoring in Industrial Engineering from the University of Massachusetts, Amherst and is a Certified Project Management Professional, Professional Scrum Master, PMI Agile Certified Practitioner and Certified Scrum Professional and is the owner of Cape Project Management, Inc.
Cape Project Management, Inc.
Boston, MA 02129, USA
Contact: Dan@CapeProjectManagement.com
