There Is Not a Goal to Agile, Plus Lean SSC Review

May 19, 2012 — Posted by Al Shalloway

I just came back from the Lean Systems Society’s (formerly Lean SSC) annual conference. It was awesome.  As someone who has gone to scores of conferences, including most of the Scrum gatherings, the Agile conferences and SQE’s main conferences, I can tell you that the 4 Lean Society’s conferences have been the best 4 conferences I’ve attended. One of the reasons is the diversity of the speakers and the attendees.  Topics have included, besides Lean and Kanban, of course:

  • Risk
  • Complexity frameworks
  • How to learn
  • How to develop software effectively
  • How to improve IT
  • TDD
  • ATDD
  • Learning models
  • OODA
  • Product development
  • Models of human behavior
  • and many, many more

I truly, strongly suggest you keep your calendars open for next year’s event in Chicago.

In any event, being around this conference this week high-lighted that there is no goal in Agile – there are many.  People often say “you can’t do Agile, you can only be Agile.”  But how do you go from not being agile to being Agile? That shift is not always (or usually) instantaneous.  Agile incorporates an attitude and a way of thinking, and a way of working with others amongst other things.  However, there is a doingness to Agile as well. This is what I meant by there is not a goal of Agile, there are many.  Here are a few (in no particular order):

  • deliver value quickly to the customer
  • add value to the business
  • improve the working environment for everyone
    • create an environment of trust
    • create great teams
    • improve relationships amongst the business doing Agile
  • improve the quality of the product
  • accelerate learning
  • develop people
  • minimizing risk
  • improve the quality of one’s product
    • improve the product’s code quality
    • improve the value delivered to the customer
    • enable the product to ben enhanced quickly

If I thought about this much longer I am sure I can come up with quite a few more.

The point is there are many, many  goals to being Agile.   Which implies there are many paths to get there.  Since organizations are different and have different challenges, opportunities, weaknesses and strengths, there will not be a single path to becoming Agile.  Some of the variations will be:

  • where in the organization do you start? (team, group, department, business stakeholders, PMO, product management, ops, …)
  • what method/framework should you use? (Scrum, Kanban, Lean, XP, …)
  • what can you hope to change in a reasonable amount of time?
  • what do you focus on? (communication, learning, development, what to work on, …)
  • what changes can you make now that will enable you to make changes better in the future?

You can imagine that there will be many different things you will work on during your transition to becoming Agile.  The order in which you work on these items should be somewhat based on the following:

  • What can you work on? (may not have authority to start anywhere)
  • What, after you improve it, will make it easier to do other things? For example, if you have to do two things and they are initially of equal difficulty, but doing one of them will help do the other later, then you should do that one first.
  • What will provide evidence of your success? This is often important to be able to sustain your efforts.

I hope my point is made.  The fact that many people believe one should always use one framework to start does not make it the right framework for you to use.  Your situation, not a consultant’s livelihood, should determine where and how you start.

While considering all of these options may be daunting – there being so many things to consider - it’s not as bad, or as complex, as it first looks.  There are several principles that can guide you. One needs to know a relatively few things in order to start:

  1. Where to start (find the root cause of your challenges)
  2. How to measure if you are improving your methods (so once you get started you can see if you are improving)
  3. How people learn (so you can help them sustain their learning)
  4. How people can best create teams (so you can continue to improve your teams)

I intend to go over each of these in detail in our upcoming webinar series- Lean-Agile at Scale and the Team: The Value Stream series.  However, until you’ve gone through that, you can get going (or improve your current going) by:

  1. Seeing if there a straightforward change you can make that will immediately move you forward (if not, start where you are with Kanban to create visibility on your current methods)
  2. Understand that people can only change so far so fast (remember, it’s always a people problem, not a technical problem)
  3. Understand that learning is accelerated when people talk to each other frequently (i.e., consistently, and ubiquitously talk about how you do your work)
  4. Don’t assume a pilot project, selected without attending to the bigger picture will benefit the organization – even if the pilot is successful
  5. Be aware that you may be limited as to where and who you can start your transition to agile methods but that you always want to create visibility to everyone involved

Scrum is often a great choice if you have a team that wants to use it and doing so won’t adversely affect the rest of the organization.  Even here I’d strongly encourage incorporating many Lean/Kanban principles into your Scrum teams (see Principles and Practices All Agile – including Scrum- teams Should Know and Follow).  If you are not sure what to do, I suggest starting with Kanban.  Why?  Because Agile endeavors should be done in an Agile manner.  Only Kanban tells you to start where you are and then make gradual improvement.

Alan Shalloway
CEO, Net Objectives


Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With 45 years of experience, Al is an industry thought leader in Lean, Kanban, product portfolio management, Scrum and agile design. He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in these areas.


Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban