If you know Scrum or Kanban your next course should be in a course that covers what you don’t know

I’ve written recent posts about stoping the binary thinking & a Manifesto for Agile Learning. The key point of both is that breadth is more important than depth. If you’re an SM you may have the concepts of Scrum & Agile down, but may not have what you need regarding Kanban. If all you’ve done is Kanban, there are concepts in Scrum that are quite useful as well.

I co-founded Lean Kanban University w/David Anderson (I’m no longer affiliated). One reason I left the organization was what I perceived to be a tunnel-vision view. “Visualize, don’t reorganize” is limiting in my mind. Cross-functional teams have shown to increase innovation and reduce handoffs. I’ve always like Don Reinertsen’s statement “flow when you can pull when you must.” Flow is not just about using kanban &visibility.

This is why we’ve created Team Agility, a blend of the 2 and The Net Objectives Coaching Academy for Scrum Masters and Agile Team Coaches. It’s more about effectiveness using all of the methods available instead of mere certification.

Let me know if you’d like to learn more.

NOTE: i know many Scrum & Kanban trainers who teach both, I am referring to the orgs that promote only one.

Manifesto for Helping Others Learn Agile

Note: This is not intended to be an alternate version of the Agile Manifesto, but it was inspired by it. Values and principles are a powerful approach. The fact that this manifesto can parallel the Agile Manifesto is a testament to its endurance.

We are uncovering better ways of helping others learn how to create value for their business and customers. Through this work we have come to value:

Learning Agile over learning frameworks

People learning how to learn over learning a set body of knowledge

Focusing on how people can get their job done over giving them certification

Teaching different Agile approaches over going deeply in one method

That is, while there is value in the items on the right, we value the items on the left more.

Principles behind the Learning Agile Manifesto

We follow these principles:

Our highest priority is to help people learn how to learn. This requires achieving an understanding of any underlying principles of what we teach, while recognizing that best practices are only best in certain contexts.

Welcome the needs of the learners, especially the way they learn, even when we discover these after we’ve started our engagement.

Recognize that most trainings are best delivered in small chunks over time. When a multiple day workshop is advisable for focus,discussions should be interspersed with actual work being done under the guidance of the instructor.

All roles must learn together. We must provide them with agreements which focus them or providing true value

Create environments within which people can both work and learn so that they can continuously improve by taking advantage of what is already known to work while being able to invent new methods when needed.

The most effective way to learn is doing actual, meaningful work with one’s peers and having guidance provided as needed.

Demonstrated success in the learners’ own environment is the primary measure of progress.

Effective learning promotes sustainable learning. It must provide a support system after any workshops so that the learners can continue working on their own in an ongoing manner.

People learn best when taught in a way conducive to their method of learning. Instructors/coaches must pay attention to this.

Conveying just what is needed and when it is needed is the most effective way to help people learn.

People learn best when working with their peers.

At regular intervals, trainers and coaches must reflect on their methods to see how to improve them – never blaming poor results on their learners, but always taking responsibility for the results achieve.

Some Thoughts That Pertain To This

“We cannot solve our problems with the methods we used to create them.” – Albert Einstein

“Insanity: Doing the same thing over and over and expecting a different result.” – Albert Einstein.

“For every complex human problem, there is a solution that is neat, simple and wrong.” – HL Mencken

“It is difficult to get a man to understand something, when his salary depends upon his not understanding it!” – Upton Sinclair

“Thus, the task is not so much to see what no one yet has seen, but to think what nobody yet has thought about that which everybody sees.” – Arthur Schopenhauer

“Truth Passes Through Three Stages: First, It Is Ridiculed. Second, It Is Violently Opposed. Third, It Is Accepted As Self-Evident.” – Arthur Schopenhauer

“We must set aside our egos and embrace what others have learned so that we may assist our charges by using what is needed instead of insisting we use our own methods. We must acknowledge much of what we know is not correct.” – Al Shalloway

Creating understanding is more essential than offering solutions. Many, but thanks to Michael Kuesters for the suggestion.

It’s easier to act your way into a new way of thinking, than think your way into a new way of acting. ― Jerry Sternin, The Power of Positive Deviance: How Unlikely Innovators Solve the World’s Toughest Problems

When all you have is a hammer, everything looks like a nail. – Maslow

Note from Al Shalloway

This is obviously a first cut. I believe I am speaking for a large number of people. I request feedback on how to improve this. I promise to listen and improve.

If you agree with the intent of this article please write a post about it and/or retweet it.

Stop the binary thinking

At a conference years ago Don Reinertsen & I were watching from the back of the room together & sometimes making comments between us about the presentations. At one point it was clear that there was a pattern of “this or that.” Don made a funny observation “these folks have been around 1s & 0s too long.” I had had the same feeling so laughed at his eloquence.

We’re still doing that. We look at Scrum as a thing & Kanban as a thing. Scrum has the cross-functional team be sacrosanct & David Anderson says “visualization not reorganization.” There is power to both. Both are proxies to what we need to do.

Conway’s law tells us “”organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.” My corollary is that “When development groups change how their development staff are organized, their current application architecture will work against them.”

We have to recognize we’re in a very complex situation. Ultimately we need to have some simple guidance to help with decisions. The root of these are:

  1. make sure what you’re building has value
  2. look at time it takes from start to end (cycle time)
  3. shorten the time any part takes from start to completion
  4. attend to quality at each step


Comment added:

btw, if this looks like Lean to you that’s because it is. Lean, boileld down to its essence is:

  1. systems thinking
  2. just in time
  3. build quality in

The True Intention of Scrum

Scrum was inspired by the article “The New New Product Development Game” (’86). It introduced a new way to develop new products. The question essentially was “how do we get innovation from product development teams?” The emphasis was on speed & flexibility. Several characteristics of successful development included:

  • Teams work best when they work autonomously
  • Checkpoints are needed to prevent instability, ambiguity, & tension from turning into chaos.
  • Continuous learning is essential
  • Mistakes are both tolerated & anticipated
  • Management must adopt a management style that can promote the new process

The bottom line is to have teams working autonomously but with a set direction / challenge and oversight (but not micro-management). Management has a significant role to coordinate all aspects of the organization that is required for the product. The team must coordinate with other parts of the organization to achieve value.

Scrum is essentially a framework for doing & learning. The approach requires more of a management shift to create such an environment than it is a how a team is to work. The implications of this when adopting Scrum in most organizations is significant.

Why Learning How to Decompose Stories with Acceptance Test-Driven Development (ATDD) Is not Just Decomposition

I’ve been having a very interesting twittervation about how to start teams off with Scrum. I believe you best learn by doing. And that it’s more important to get teams actually starting Agile in the workshop than merely learning Scrum which will hopefully lead you to Agile.

So we “teach” Scrum with a 1-day emulation and discussion of it followed by 3 days of ATDD. This first day teaches the essence of Scrum but it illustrates how teams work – mostly their foibles. 🙂

The other three days are on ATDD. Each day isi split by 1/2 day discussing it & then an hour with each team doing it. What we’re really teaching is – collaboration, test-first, feature slicing, and how to use minimum business increments. These directly address the issues we’ve seen most teams have- unclear requirements, stories too large, POs not appreciating the impact of interruptions and a lack of focus on finishing.

The test-first is mostly about discovery & specification but it also informs design (the 1st mantra of design patterns is designing from behavior).

The result is that once a team gets moving they can keep moving. But a course that prepares you for movement may not ever get you started.

Why We Need to Inspect and Adapt How We Do Scrum Training

Inspect (Where we are)

Years ago Ken Schwaber observed that only about 25% of organizations got what they wanted from their teams adopting Scrum. I would guess that number hasn’t changed much since then.

Back then we didn’t have the understanding of Lean principles or Kanban. We didin’t know about ATDD or GWT. Our tools were horrible. So why hasn’t improvement happened? I would suggest it’s because “Inspect & Adapt”, a key tenet of Scrum, has not been applied to how it is taught.

The symptoms of bad Scrum now are essentially what they were back then:

  • running Scrum as mini-waterfalls
  • developers & testers not working well together
  • unclear requirements
  • too many interruptions & too much work

I know certified Scrum trainers are concerned about this as much as myself. But when I ask them what’s the cause I get virtually the same list of answers:

  • management hasn’t bought in
  • people aren’t doing Scrum right
  • people aren’t being Agile

While this may be true, the question is why? A clue to that may be seen by asking yourself “where is the responsibility being placed in those answers?”

Taking Responsibility

I have heard “Scrum is like chess. You either play it as its rules state, or you don’t. Scrum & chess does not fail or succeed. They are either played, or not.” The Scrum Guide tells us that – “When the values of commitment, courage, focus, openness & respect are embodied & lived by the Scrum Team, the Scrum pillars of transparency, inspection, &adaptation come to life & build trust for everyone. The Scrum Team members learn &explore those values as they work with the Scrum roles, events, & artifacts.” Unfortunately, most teams I know new to Agile do not work in an environment where those values are encouraged, let alone manifested.

The opening line of the Agile Manifesto states–“We are uncovering better ways of developing software by doing it &helping others do it.” The “helping others do it” means you have to come from their needs & their way of learning. This is your responsibility. It doesn’t mean just giving them a chess board, pieces & a quick overview of the rules & say “learn.”

While new Scrum teams have the responsibility in what they do, trainers have the responsibility to prepare the teams. This means trainers must adapt their methods.


Virtually all initial Scrum workshops focus on the roles of Scrum. The lack of whole team training is a core problem. The presumption that teams will figure out how to work together is not based on evidence. Instead, the focus needs to be on the actual work the team needs to do. Ironically, because Scrum is so simple, it can be taught in a day with the extra time available focusing on the work itself.

After initial Scrum training, most teams are facing even more pressure since they’ve just been trained. The challenges mentioned in pt 1 of this post should actually be expected. This often leads to them modifying the rules of Scrum without understanding how this can be done effectively. This, of course, leads to Scrumbut. Many people continue the shift of responsibility by calling them “Scrumbuts.”

The truth in Jerry Sternin’s observation “It’s easier to act your way into a new way of thinking, than think your way into a new way of acting” must be recognized. Scrum should be taught by teaching the entire team to work together in the process of creating features & breaking them down into stories while establishing how the entire team works together.

A New Approach

A new approach must recognize the following:

  • not all teams have the same challenges
  • many teams want to be told what to do

as well as provide the following:

  • a curriculum adjusted for the team(s) involved
  • teams must actually do some Agile in their initial workshop
  • Scrum Masters and Product Owners must be trained with the teams so all roles can learn how to collaborate with each other
  • SMs should be provided a flipped classroom style learning over time so they can learn “on-the-job” & stay ahead of their team so as to be able to guide/mentor them
  • a scorecard that provides clarity on the team’s effectiveness & how they can improve should be provided
  • some Lean-thinking, principles and practices (e.g., a little Kanban) since they can help teams adjust Scrum as needed

This can be delivered for about the same cost as sending teams to a CSM class if we focus more on the work & less on the framework. Using a combination of the latest training techniques (back of the room training, flipped classroom) also makes it more effective.

Doing this in initial training also avoids the resistance may teams have to adopting Scrum because they mostly see new meetings instead of actually helping them.


How to decide on what to start with when starting Agile at the team

 I’m guessing most people are expecting me to talk about making a decision on whether to use Scrum or Kanban. But I don’t believe that’s the biggest decision to make. The first thing when starting Agile at the team is to ask “what’s in my way of creating and delivering value?”

Although Scrum proponents hail Scrum as a good way to figure this out there are other, faster methods available (mostly just look at your current situation and see where your blockages and large queues are – see Value Stream Impedance Scorecard for more).

Common challenges are:

  • developers & testers don’t collaborate well together on stories
  •  people aren’t interacting well with each other
  • the lack of cross-functional teams is causing delays
  • work is not done in short cycles so feedback is hard to get
  • teams are being overloaded with work
  • teams don’t know how to write small stories

Clearly Scrum & Kanban both attempt to address this in their own way and it should be clear how each one addresses these. Your choice though is to learn a framework or method that helps you with these challenges or in your initial training work on them directly – and then adopt a Scrum/Kanban approach that best fits your situation.

Why You Must “Do” Agile Before “Being” Agile

Why You Must “Do” Agile Before “Being” Agile

I often hear that you can get people to do Scrum but it won’t last unless they learn to “be” Agile. I suggest Scrum often fails because teams never learned how to do Agile. Scrum is a framework, a potential path to Agile. Conflating these two has many companies adopt Agile by getting certified in Scrum and hiring a coach to help them fill it in with practices

The challenge with this is that teams were already busy with their work before their training and now they have even more to do because Scrum appears to be a set of practices & meetings. They haven’t learned the Agile “doing” yet.

You obviously can’t teach the doing of Agile in 2-3 days. Agile is a method of collaborating with the customer, defining small pieces of work to do, creating them & getting feedback to ensure you’re on the right course. Yes, a new way of being is needed, but it is easier to act your way into a new way of thinking than think your way into a new way of acting.

Getting started with Agile means to take a sustainable step of doing with just enough of a framework to keep it going and to encourage improvement. The focus should be on the doing. Working together effectively may create the being. But the doing alone will be an immediate improvement.

Simplifying SAFe w/MBIs

SAFe has many concepts across its levels-strategic themes, epics, solutions, value stream, MVPs, MMFs, capabilities, stories & several backlogs.

While SAFe nobly attempts to present all needed concepts it does not explicitly call out the most important one–the smallest chunk of work that will provide the most value for the time it takes to build it. We call this the Minimum Business Increment (MBI). It is very similar to Denne& Cleland-Huang’s Minimum Marketable Feature (MMF), which, unfortunately, SAFe changed original meaning of to represent “the minmimum functionality that the teams can build to learn whether the benefit hypothesis is valid or not.” This concept is already part of Agile which always suggest to build in vertical slices to test our hypothesis.

SAFe definitely intends to have the concept of the MBI, but its use of overloaded &redefined terms make it hard to see. MBIs encapsulate the intention of solutions, MVPs, capabilities & SAFe’s re-defined MMFs. Realizing this can simplify SAFe by starting with initiatives that are consistent with our strategic themes & defining a sequence of business increments for them. These business initiatives can then be refined into MBIs which create the context for everything needed to manifest value.

The Most Important Part of an Agile Framework Is How it Is Adopted – Day 4 of #SAFeSummit countdown

There are many lessons we can learn from the challenges incurred in adopting Scrum. I suggest the significant amount of bad Scrum in the world is due to the approach in teaching it.

The most popular method focuses on the framework itself. It usually consists of a CSM taught to a team. Some guidance is provided on how to write stories, but the attendees spend virtually no time writing their own stories past the ubiquitous “as a user…” method which is insufficient in the real world.

Another method focuses on Agile analysis by having teams create a backlog of their own stories using some aspects of ATDD. Only minimum training on Scrum is needed since it is now in support of what the team’s work & they already have an understanding of the why for feedback.

We have found the 2nd approach to be significantly more effective because people leave the workshops actually doing Scrum & don’t have to figure out parts later.

I see the same thing happening with SAFe with different ramifications. The SAFe framework alone often improves orgs’ agility because of the quarterly planning event. But working with product managers prior to the event & teaching teams more ATDD & less SAFe is critical.