I may be stating the obvious—you can’t be Agile without being Lean.

I may be stating the obvious—you can’t be Agile without being Lean.

by | Aug 21, 2018 | Agile, Lean

In the Agile Practice Guide published by PMI® and the Agile Alliance®, there is the Venn diagram shown above. It is a simple yet useful visual that most of us long-toothed Agile practitioners clearly understand.  Unfortunately, I am finding through my training practice that “coaches” and late-adopter organizations have  missed this step.  Let me restate this in a more compelling way:

If you don’t embrace Lean as an organization, you will constantly face challenges with your Agile implementation.

What does it mean to be “Lean”?

I am not referring to the book, “Lean Software Development,” which is valuable but is still a subset of organizational Lean. I am referring to the Lean as defined in the Toyota Production System (TPS) created by Taiichi Ohno and Eiji Toyoda.

While in school for Industrial Engineering I learned all about TPS. After graduation, when I started managing large software development projects, my education in Lean proved useful for software development. Based upon this education and training, adoption of the Lean principles became my fundamental basis for project management. This realization occurred prior to Agile Manifesto’s creation; to become more “Agile” I followed the models set by authors who were already adopting software development best practices that aligned with Lean principles.

Jeffrey Liker summarizes these Lean principles in his 2001 book The Toyota Way:

  1. Base your management decisions on a long-term philosophy, even at the expense of short-term financial goals.
  2. Create a continuous process flow to bring problems to the surface.
  3. Use “pull” systems to avoid overproduction.
  4. Level out the workload (work like the tortoise, not the hare).
  5. Build a culture of stopping to fix problems, to get quality right the first time.
  6. Standardized tasks and processes are the foundation for continuous improvement and employee engagement.
  7. Use visual controls so no problems are hidden.
  8. Use only reliable, thoroughly tested technology that serves your people and process.
  9. Grow leaders who thoroughly understand the work, live the philosophy, and teach it to others.
  10. Develop exceptional people and teams who follow your company’s philosophy.
  11. Respect your extended network of partners and suppliers by challenging them and helping them improve.
  12. Go and see for yourself to thoroughly understand the situation.
  13. Make decisions slowly by consensus, thoroughly considering all options; implement decisions rapidly.
  14. Become a learning organization through relentless reflection and continuous improvement.

These principles are framework agnostic and can be applied to any project and any organization looking to excel. Organizations that adopt Lean have more success than those that only adopt Agile. Scott Ambler, the author of Disciplined Agile Delivery (DaD), published the following study in 2013:

While not an overwhelming difference between Agile and Lean (65% vs 70% successful) I’ve found that more recently that the gap is widening.

While not a comprehensive description, this article highlights the potential of Lean. If you are focused on an Agile framework, process, procedure or tool, and are facing challenges with your Agile implementation, there may be another option. Step back from your project and work with leadership to decide if any of the above principles are missing or lacking. Ask yourselves the following questions:

  • Is there a direct relationship between the lack of a Lean principle and your Agile implementation challenges?
  • Is the organization committed to doing what it takes to be Lean and fundamentally Agile?

Ultimately, you can self-assess by reading and reflecting on those principles. The path forward is simple if you adopt a Lean approach to your implementation: Try it! If you fail or succeed, if you focus on continuous improvement you will propel your company forward.

References:

About the Author: Dan Tousignant

Dan has been leading software development projects for 20 years. He was first formally introduced to Agile via a Scrum Implementation in 2000 and has since adopted the Agile Manifesto values and principles when leading software development projects.

Dan holds a BS in Industrial Engineering from UMASS, Amherst and is a Professional Scrum Master, Certified Product Owner, PMI Agile Certified Practitioner and Certified Scrum Professional.

Dan Tousignant, PMP, CSP, PMI-ACP, SPC

President Cape Project Management, Inc.

Are you implementing Scrum but realize you are better suited for Kanban?

Are you implementing Scrum but realize you are better suited for Kanban?

by | Aug 19, 2014 | Agile, Kanban, Lean, Scrum

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 customer's 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 which 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:

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.

  • 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 Analyst and/or a true Product Owner role exist to perform ongoing acceptance testing.

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.

Manage WIP using 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.

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.

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.

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

Do you want to learn more about our approach to Kanban? We have 2 options:

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.

error

Enjoy this blog? Please spread the word :)