What I Am Trying to Destroy

On a twitter thread there was an implication that perhaps the reason some people don’t engage with me is because they perceive my purpose is to destroy. I have told myself that as a good person that is not my intent. But I now realize it is.

Over the last 20 yrs I have observed many patterns of challenge & success in the adoption of Agile. I am convinced that Agile adoptions do not have to be as hard as they usually are. Most of the time they are difficult I see unexamined assumptions as contributing to this. This includes both beliefs underlying the approach used & how to teach it as well as if/when to introduce certain practices.

You destroy unexamined assumptions by examining them (they become examined beliefs). That’s what I am doing.

But many people make their livelihood on frameworks & methods that I believe are based on these unexamined beliefs. And this causes a cycle of poor Agile adoption w/o serious reflection. Unfortunately, as Upton Sinclair has observed, “Its hard to get a man to understand something when his salary depends on his not understanding it.”

My mission is serve the practitioners and consultants who have an aligned mission – making organizations and their people more effective regardless of approach.

Let’s stop trying to get leadership/management to ‘be’ Agile

I’m often hearing how Agile is failing because leadership and management won’t adopt Agile values & principles. I would much rather they just keep some basic agreements:

Let’s stop for a minute and ask ourselves, do we want them to ‘be’ Agile or to do the following:
1-create clarity on what the most important work to do is
2-define these as a sequence of small increments for which we can realize value. Have each of these increments include technology &any other groups needed to realize value
3-provide technology clear acceptance criteria on these items
4-provide guidance across business units as to which are most important based on cost of delay
5-allow technology to self-organize & pull the work to be done in the sequence of greatest importance when technology has capacity
6-have an agreement with technology on how to handle emergencies
7-provide feedback when needed

We have come up with the following agreements we call the guardrails:
* Focus on realizing value
* Collaborate with each other in order to maximize the realization of value
* Make all work visible
* Sustain or increase predictability.
* Keep the work within capacitythroughout the value stream
* Encourage everyone to strive for continuous improvement.


For more information on the guardrails, go here.

To see guardrails tailored for leadership and management, go here.

This blog is an excerpt from my upcoming book –Achieving Business Agility at All Scales

 

When It Is Visualization and Not Reorganization – Verticals feeding horizontals

In my earlier post I discussed the relationship between visualization and reorganization & discussed how orgs should not limit themselves to visualization but should reorganize after visualization as appropriate. But in some situations reorganizatio

In my earlier post I discussed the relationship between visualization and reorganization & discussed how orgs should not limit themselves to visualization but should reorganize after visualization as appropriate. But in some situations reorganization is often not a real possibility.

Consider when vertical applications drive horizontal support systems & at scale. In a financial company one might have verticals for – banking, credit cards, signature programs, loans. These feed horizontals such as – payment processing, transactions across accounts, client account setup and maintenance …

In a situation like this, splitting up the horizontals into trains to work with the verticals won’t necessarily work well – either when you run them as separate trains or as part of the vertical train. Running the horizontals as separate programs doesn’t solve the problem either as they are each pulled in multiple directions.

In these cases, it is often best to create visibility on the work to be done by using Minimum Business Increments as the guide for what to work on across the organization.

n is often not a real possibility. Consider when vertical applications drive horizontal support systems & at scale. In a financial company one might have verticals for – banking, credit cards, signature programs, loans. These feed horizontals such as – payment processing, transactions across accounts, client account setup and maintenance … In a situation like this, splitting up the horizontals into trains to work with the verticals won’t necessarily work well – either when you run them as separate trains or as part of the vertical train. Running the horizontals as separate programs doesn’t solve the problem either as they are each pulled in multiple directions. In these cases, it is often best to create visibility on the work to be done by using Minimum Business Increments as the guide for what to work on across the organization.


This blog is an excerpt from my upcoming book –Achieving Business Agility at All Scales

Rethinking ScrumBut &ScrumAnd

This is an excerpt from a chapter my new book Achieving Business Agility at Small to Mid-Scale.

Scrum.Org defines “ScrumBut” as meaning “that Scrum has exposed a dysfunction that is contributing to the problem, but is too hard to fix. A ScrumBut retains the problem while modifying Scrum to make it invisible so that the dysfunction is no longer a thorn in the side of the team.”

But ironically, Scrum limits the options of how to fix this dysfunction by requiring its immutable roles, rules, artifacts and events be followed. If one fixes the dysfunction by dropping a Scrum practice while adding a non-Scrum practices the team is still doing “Scrumbut” even though they’ve eliminated the dysfunction. But now, by not doing Scrum they are in unfamiliar territory since Scrum does not provide insights on the intention of each of its practices. This tends to have new teams in particular, that don’t understand the intentions of the Scrum practices, have to stick to Scrum or go outside of the range of Scrum.

If people just abandon practices without adopting a new one to fulfill its intent ScrumBut is likely a bad thing. Substituting practices requires understanding the intention of the practice being substituted &a set of alternatives to choose from.

This is an excerpt from Lean-Agile at the Team: A Lean Approach to Scrum &Kanban. See 1st comment for url

The Relationship Between Visualization and Reorganization

This is an excerpt from a chapter of my new book Achieving Business Agility at Small to Medium Scale.

An advantage of using Lean-Thinking behind both Scrum and Kanban is that both tend to ignore one or the other in their own manner. Scrum prescribes reorganization into cross-functional teams while LKU Kanban says reorganization is “orthogonal to Kanban” most likely because LKU Kanban is based more on theory of constraints which does not focus on reorganization.

Lean-thinking suggests using cross-functional teams in product development. But you should only do this you can see what is happening. This delay may be measured in hours or months.

You don’t need to reorganize when you use Kanban, but that doesn’t mean you shouldn’t when it’s appropriate. Don Reinertsen tells us “flow when you can, pull when you must.” Reorganization to achieve flow instead of needing kanbans is a tenet of Lean.

Lean suggests the use of ‘workcell’s (teams in product development). This enhances flow while enabling more innovation. Reorganization when guided by visualization & the theory of flow can be a very effective tool. It should not be ignored.

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.