Category: Uncategorized

#developer. When you are given a requirement, always ask, “how will I know I’ve done that?” no matter how simple the requirement is. You’ll be surprised at how often you are surprised at the answer.

#productOwner.  When you give a requirement, always add how they will know when they’ve done it. State it as an actual result or example that illustrates the rule. 

I tag each insight with one or more roles that it will relate to. I will provide a link when more information is available.

You can see the accumulated insights here.

The best way to get these as I add to the list is to subscribe (see upper right of this page).

#everyone. Consider the cost of people being too busy. There is a toll of multi-tasking on them, but it also means they are not available to other people. This means one person being overly busy impacts everyone else they interact with. This slows down the work to be done. Our goal is not to have busy people but to get things done quickly. Large delays don’t happen at once. Rather they are the result of a cascading series of small delays.

Continue reading “What’s Obvious or Quickly Learned As It’s Pointed Out #2”

The Agile Manifesto was written in 2001, when the focus of Agile was on the team. The intentions of the Manifesto are timeless. With FLEX’s focus is on business agility, however, it is worth looking at the Manifesto within this new context. This article clarifies how to interpret the Manifesto in the context of the full value. There is no implication that the Manifesto is less than it should have been.  However, since many people are still using it as a guide, discussing it in business agility is useful.

Continue reading “The Agile Manifesto Explained from FLEX’s Perspective”

Creates a customized roadmap that attends to the needs and culture of the organization adopting it. This includes a customized starting point. Together these avoid a “one-size fits-all” mentality

Provides a support system used by practitioners to help them solve their challenges

Is geared towards practitioners becoming self-sufficient.

Is based around the value stream, making it easier to see how well the organization is doing and what they have to do to improve.

Provides a measure of improvement not based on how well the framework is being followed.

Doesn’t require a change in values in order to start. While the framework should help improve the culture of the organization, values change slowly. Remember, it’s easier to work your way into a new way of thinking than think your way into a new way of working.

Makes explicit how its practices manifest Flow and Lean principles

Has meaningful certification. Merely taking a class and passing a test just means they learned some information. Courses should include how to train and enroll people in new ideas. 0->60 in 3.5 days is meaningless.

Does not get more complicated as it evolves. It must be organized in a way that both scope and depth can be added without adding complexity.

Ref: Understanding Fake Agile by Steve Denning

There has been a lot of buzz around Mr. Denning’s comments in this article as SAFe being “the epitome of fake Agile”

But the real message is earlier, when he postulates the “3 laws of Agile”

1. Law of the Customer—an obsession with delivering value to customers as the be-all and end-all of the organization
2. Law of the Small Team—all work is carried out by small self -organizing teams, working in short cycles and focused on delivering value to customers
3. Law of the Network—the firm operates as an interacting network of teams, all focused on working together to deliver increasing value to customers

In summary, focus on the customer with small teams working as a network

What does this require?

Clear vision of who your customer is and what value you are going for. Work on delivering value in small increments so small teams can do the job. Create the alignment and proper communication channels networks require. These don’t just don’t happen on their own

I suggest that these three ‘laws’ can be used by those selecting an approach to take by considering how the approaches manifest them (or not). Designers of frameworks need to consider them as well.

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.

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.

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

 

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.