An Agile Fairy Tale

Once upon a time 2 really smart guys came up with a simple framework for teams who knew what they were doing to build products. It worked well. Other people who knew what they were doing started doing it. Then those that didn’t know what they were doing started doing it figuring they’d now know what they were doing as well.

It became popular because for the cost of a 2 day course you could get certified in that you knew what you were doing.

The framework was promoted as being the same as Agile, when it wasn’t. Companies that wanted to go Agile wanted folks who knew what they were doing so started hiring these master. This had the framework start to be used everywhere, even where it was not designed for. And, with its success, it became closed to new ideas by allowing new things to be put into the framework, but never allowing a challenge to the foundations of the framework

Then another group decided that they could take this framework and wrap it with their own. Now they had a big framework for all companies. And they put Agile in its name because no one knows what Agile is anyway

So now we have all of these people doing something called Agile that isn’t.

The moral of the story? A framework won’t help you become Agile. Focusing on your work may.

What if we treated our developers like we treat our customers?

This is to people buying Agile training and/or coaching

A key aspect of Agile is respecting people. Yet, this is often lost when we get to Agile transitions, particularly Scrum. This is not a knock on Scrum, but rather how it is commonly trained & adopted. We often hear devs say:

  • daily stand ups are a waste of time
  • we’re not getting any value out of our retrospectives
  • why do we have to <fill in the blank>?

A common reaction to this is that devs are not motivated or don’t see the value. But think about for a minute-hat if your customers said something like the following about your services?

  • <something customers have to do to use your service> are a waste of time
  • we’re not getting any value out of <this aspect of your service>
  • why do we have to <fill in the blank>?

Would you pay attention? Would you ask why they have that problem? Would you force training down their throats and make them pay for a coach to help them use your product?

So why don’y you do that with your staff? You are the Agile consultancy’s client. You don’t have to buy in to a service that your users (devs, …) are having troubles with. There are many ways to adopt Agile. Use one your people will find effective.

Introduction to FLEX webinar tomorrow 9am pacific.

FLEX leaps beyond the normal frameworks of today that are somewhat preset in how they work.

There are three mindshifts in FLEX:
1) our goal is business agility – the quick realization of value predictably, sustainably and with high quality
2) people do need a set place to start but it can be based on their needs, not a preset approach that makes selling courses easier
3) we must focus on the work by attending to flow using Flow and Lean thinking

FLEX’s approach is simple:
1) see where you want to go
2) see what’s in your way
3) create a roadmap to help alleviate these challenges
4) start working
5) improve your explicit workflow, policies, practices as you go

It’s a myth that you need a one-size fits all approach that preset frameworks provide for consistency. FLEX is as well documented as SAFe but is documented as a live document which is literally updated by the consultant using it to guide you.

Check it out at www.netobjectives.com/events

 

Step 3: Incorporate Flow into your way of thinking and focus on the work itself

Quick recap (see earlier posts):

  1. How did Agile get to be so unagile
  2. take a systems thinking point of view. Use Lean to create a great environment
  3. Focus on business agility – the quick realization of value predictably, sustainably and with high quality.

Flow thinking is looking to see how to take an idea to realized value as quickly as possible by working on what will achieve the greatest value, educing delays in workflow, by getting quick feedback, and not creating rework. Lean’s mantra of “just in time” guides us in how to make decisions on when to start work. Its “build quality in” has us stop creating unplanned work due to errors.

But Flow thinking also means we have to attend to the work – not a framework. All too many times people adopt Agile by spending most (all?) of their budget on the framework or relegate how to do the real work to 2nd tier training. Einstein would say this is insane given the patterns of challenge this causes.

Ask yourself when you’re considering an adoption – which is more important to know – the framework or how to do the work? A framework sets the stage for the work, but won’t teach you how to do it directly.


if you find this blog interesting you might want to check our upcoming webinars. See NetObjectives.com/events.

Useful quotes when reflecting on current events

It is difficult to get a man to understand something, when his salary depends upon his not understanding it. Sinclair
Schopenhauer

The task is, not so much to see what no one has seen yet; but to think what nobody has thought yet, about what everybody sees.
All truth passes through three stages. First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident. Schopenhauer

Those who do not learn history are doomed to repeat it. George Santayana

I am enthusiastic over humanity’s extraordinary and sometimes very timely ingenuity. If you are in a shipwreck and all the boats are gone, a piano top buoyant enough to keep you afloat that comes along makes a fortuitous life preserver. But this is not to say that the best way to design a life preserver is in the form of a piano top. I think that we are clinging to a great many piano tops in accepting yesterday’s fortuitous contrivings as constituting the only means for solving a given problem. Buckminster Fuller

Asking a favor of 15 minutes from any internal consultant of a large organization considering or using SAFe materials for training.

First, I promise I am not trying to get a surreptitious sales call. I am wanting to do marketing research. Here is the situation. I am looking to disrupting the big 8 as I’ll start calling them (Scrum.A/I/O, SAFe, DAD, LKU, LeSS, Spotify). There is more goodness outside of them than inside of them (& i’m excluding what i have to offer when i say that).

I don’t want to go into details yet, but i’m hoping to get a better understanding of the attraction of the certifying bodies as well as well what might be more attractive.

Anyway, if you’re willing to give me 15 minutes of your time I’d greatly appreciate it. Just email me at alshall netobjectives com thanks.

Clarifying my comments about the certifying bodies

While I do believe certification itself is directly hurting Agile, that was not my real point. My point is the following companies occupy most of the mindshare of those new to Agile: SAFe, Scruminc, Scrum.org, Scrum Alliance, LKU, LeSS, Spotify model, DAD. 8 for profit companies (I know SA is a 501C, but de jure only) controlled by a dozen or so people.

Because HR is so crazy about certifications most of the focus is on what these folks are certifying folks in. But the real things to be studied are Flow, Lean, quality code, organizational development, proper management techniques. Not the 8 frameworks mentioned above.

Companies are taking a very non-scientific approach to what is probably the most important body of knowledge there is – adding value in knowledge work with software involved. Focusing on certification (which means a focus on coursework) is the real problem.

What the certifying bodies can do to improve Agile

To avoid being accused of just being negative I thought I’d put out what I think the certifying bodies can do. After all, each has a well organized marketing and training team.

It would not be hard and they could add value to Agile.  It would take the following steps:

  1. acknowledge that certifying people is misleading. A 2-4 day course has only a minor impact on people. Just give accreditation that they’ve taken the course.
  2. admit that their approach is a good approach for certain situations, and specify what those situations are
  3. acknowledge that there is more to learn and that everything can be improved. That no one (including the person running the organization) has all the answers.
  4. encourage their trainers to learn news methods instead of forbidding them to do so
  5. understand that in the long wrong, the customers’ best interest is more important than selling a particular approach
  6. adopt modern training methods
  7. don’t preclude things that everyone needs but give no competitive advantage

Bottom line, put truth before marketing.

Evaluating your intake process on how effective it is to get leadership and management involved

I often hear complaints in the Agile space about how leadership and management don’t get Agile. I think much of that is because of how they are talked to. But I also believe it is the set of practices used makes it hard to see their role without doing a deep study of Agile – something they are neither interested in or going to do (and not something they need to do).

It recently occurred to me that one way to evaluate the quality of an approach is how it affects the conversation with leaders and managers.

I just updated my chapter on Using the Intake Process to Educate Leadership.

SAFe is not Agile if you are planning 3 months ahead

SAFe is not Agile if you are planning 3 months ahead

For companies that couldn’t get anything done in a year and are now getting things done in 3 months, SAFe is great. But don’t consider it Agile.

Quarterly planning presumes more certainty than we have. It’s waterfall thinking. Going from 12 to 3 months is an improvement. But don’t stop there.

If you are a development group of less than 300 people you probably could be doing 2 week plannings or even flow. Every now & then you can do a big room planning for the social benefits that provides, but it’s not needed for planning.

Long planning periods:

  • require reworking requirements in last couple of sprints
  • loses focus on realizing value
  • makes it more likely that features will be bigger than needed
  • loses focus by teams on releasable value
  • results in more work being injected into already planned work
  • has the refinement of any stories pushed out of the PI due to new work be waste
  • makes it harder to pivot
  • causes a loss in a sense of urgency
  • requires more refinement up front without advantage of feedback
  • establishes a baseline of “not good but good enough” so improvement stops

It’s fine to do high level quarterly planning but then work in a flow model to implement it.