Using Lean to Focus on Your Work

The reason I am not a fan of frameworks is that they mostly have us focus on activities that are proxies to what we need to do to achieve what we really want to do – realize value quickly, predictably, sustainably and with high quality. Lean provides us insights on what to directly work on. Consider these 5 aspects of product development:

Focus on what’s of value to the company. Much of this will be providing better value to the customer some will be on how the organization builds them. This must be quantified for it to be relevant since everyone in the organization must see these driving factors. Use OKRs (objectives and key results) as a basis with strategies and initiatives being spawned by them.

Understand your value stream network details the steps and who does them that it takes to actually create the value.

Focus on lowering the cost of delay which is the time lost to delays in value realization. Organizational structure, development method, size of the work to be done and how people collaborate are significant factors.

Manage the flow of work and the ecosystem through which all of this flows. This includes when work is started and how decisions are made for how people work together.

Continuously improve the above.

How Frameworks Are Being Used Now Is Impeding Agile and What We Can Do About It

Part 1: Frameworks are taking our eye off the ball

We cannot solve our problems with the same thinking we used when we created them. – Albert Einstein

How Frameworks Are Now Impeding Agile: Part 1

We cannot solve our problems with the same thinking we used when we created them.

There is no question that Scrum & SAFe have transformed how we work. Both have created a new mindset around work- Scrum focusing on the importance of team & SAFe focusing on the necessity to coordinate teams.

And both have now created new challenges in somewhat the same manner. Each has taken our eye off the real task- working in an Agile manner. This is finding what’s of greatest value, allocating our capacity to work on it, properly decomposing it so it can be built in increments and being able to deploy frequently/continuously. Scrum’s focus on ceremonies has takes peoples’ eyes off of how they do their work – leaving it to the team with the unquestioned assumption that they’ll figure it out (& then blaming them for not doing Scrum if they can’t or change anything in their attempt).

SAFe has gotten management involved but mostly to demand that SAFe be done. SAFe is often led internally by agents who demand that SAFe be followed. Again, the focus is on the framework.

Frameworks were an excellent way to go when we didn’t understand the mechanics of Agile. We do now. We should attend to them or at least drive our frameworks with them.

How Frameworks Are Now Impeding Agile. Part 2 – Scrum

Take a look at the common challenges teams have when adopting Scrum:

  • not being able to write small stories
  • essentially doing waterfall in 2 week cycles-Scrumerfall
  • having many open stories at the end of the sprint
  • difficulties poised by being interrupted in a sprint
  • not being able to coordinate well with other teams

The similarities across widely variant dev groups is striking. Not a surprise since systems-thinking would predict this. While Scrum proponents claim “if you did Scrum these things wouldn’t happen” is likely true, what does that matter? People are doing their best.

We need to attend more to what insights & skills would help us avoid these challenges directly.

The above challenges are due to not attending to:

  • flow
  • managing work in process inside the sprint
  • the team’s part in the bigger picture

Yes, I know Scrum doesn’t say not to do these, but that’s not the same as saying to do them.

In the early days just getting teams co-located, cross-functional & working in small chunks was a major improvement. To go to the next level we need to shift our focus to the work & how to do it.

How Frameworks Are Now Impeding Agile. Part 3 – SAFe

Many people complain that SAFe is too complicated and doesn’t truly get management involvement. I would agree. But why is that?

Take a look at the common challenges organizations have with adopting SAFe:

  • little improvement beyond the program
  • little improvement in the area of portfolio management
  • difficulty resolving conflicting requirements given to platforms and shared services
  • a continuation of top-down management
  • too much work in play overall
  • not being able to get deliveries within a program increment

The similarities across widely variant organizations is striking. This validates systems-thinking’s assertion that the system people are in causes behavior. SAFe proponents claim it addresses the main issues & people just need to fill things in. I would suggest that the way SAFe addresses these issues prevents people from filling things in.

Pre-defining roles & artifacts takes our eyes off of the value stream and the work that is taking place in it. This is exacerbated by SAFe overloading and redefining terms.

In the early days getting a plan for a program & having teams work together towards that a major improvement. To go to the next level we need to shift our focus to the work itself.

How Frameworks Are Now Impeding Agile. Part 4 – The Solution

Actually, if you’ve been following my train of thought here, you’d know there is no solution. But there is an approach that will lead to a solution. It’s using Lean as an overall context for your work because Lean focuses directly on the work. Lean can help achieve business agility – the quick realization of value predictably, sustainably and with high quality.

Lean provides insights to shorten the time from beginning work until value is realized. It does this by starting with the question of what’s value to the customer? Then attending to the value stream so that we can improve it to eliminate delays in workflow and feedback. By attending to queues of work we can see where our bottlenecks are and improve them. Instead of overloading teams we have them manage their work by implementing pull systems. And, because we’re looking at improving our work directly we can continuously improve.

Fortunately, this doesn’t mean we have to re-invent the wheel. All we need to do is look at the outcomes we need at each step of the way and select the best method for us to get there. This is true agility – figuring out how to solve our problems instead of taking canned solutions.

Want some free advice on solving adoption challenges in SAFe? Help me with my book

I am close to finishing “Adopting SAFe® for Your Organization: Achieving Business Agility from Small to Mid-Scale.” We take our own FLEX approach (FLow for Enterprise Transformation) and apply it to SAFe to help solve virtually all of the challenges we’ve seen small to mid-scale organizations have when trying to adopt SAFe. The result is using the core of SAFe while fleshing it out with Lean-Agile principles and patterns of adoption to create a simpler framework, albeit perhaps no longer SAFe, to use.

The list of these challenges is at https://goo.gl/Zcx7cu
Please take a look at let me know about any others.

Lowering the cost of your framework training by making it better

Framework proponents suggest starting with framework training & later adding what else is needed (e.g., prod management, test-first). We believe this leads to a significantly higher cost of training

Companies with more than a few teams need a blend of Scrum & Kanban. Few companies need all of SAFe. The most important aspect of a workshop should be how to work together with your associates

Training should be oriented around

  1. the context of the people being trained
  2. increasing collaboration
  3. learning by doing actual work
  4. needed essential skills

Training in frameworks is important. But when people are given the skills they need from the start, less knowledge of the framework is needed to move forward. This is especially true when these essential skills are learned together. Not having these essential skills leaves them unprepared & often causes resistance to the framework, which, by itself, is not helping.

Unfortunately, this type of training cannot be done with certification, since certification requires a focus on the framework. Less framework, more how to do is required. Fortunately, there are many qualified, non-certified trainers out there who are more concerned with you getting what you need

Attending to What Management Wants in an Agile Adoption

Proponents of Scrum often put the responsibility for failed adoptions of Scrum at the feet of management who don’t want to change. While I believe this is true some of the time, I believe the challenge is that Agile adoptions based on Scrum often don’t attend to management’s needs.

I believe management concerns regarding Agile adoptions are focused on reducing risk, making sure it fits their needs, and to be able to adapt when needed. It’s tempting to say “let’s just adopt Scrum.” But this ignores that we live in a complex world where you reduce uncertainty not by having a preset list of things you must do, but rather by learning to adjust to the situation at hand. These are things beyond our control.

What is in our control is our actions. 15 years ago we didn’t have a solid understanding of the “task work” so to speak of Agile. Why working on small batches were good, why visibility was essential, why managing queues is critical, … Now we do. This enables us to go beyond Scrum effectively.

Adopting Scrum is very often the best place to start. It provides structure & discipline. But get training from someone who knows how to go beyond it when that’s the right thing to do.

—–

Addressing the issue of how to adjust Scrum while not worrying about if it is still Scrum is based on  20 years experience with Scrum and is described here:  How to improve or change your Scrum practicesThis is part of our larger Scrum Support system.   I believe having a framework where being effective sometimes requires you to go beyond it is insidious. I contend there are place in any tech org of more than 50 people that no one set of practices work, particularly in shared services, DevOps, maintenance. We have put this together because we’re not limited to Scrum. 

Frameworks, proxies and Lean-Agile Principles

From the moment Scrum became more popular than XP, the software dev community has been focusing on frameworks more than Lean-Agile principles. It’s not surprising this has happened. It’s a lot easier to understand a framework than the principles underneath them.

The challenge that occurs is when the framework becomes the goal. Continue reading “Frameworks, proxies and Lean-Agile Principles”

Lean Thinking on frameworks vs. the work in them

One of the central tenets of Lean is that the system people are in impacts them significantly. This does not mean, however, that one can just create a new system and put people in it – this would be a perversion of Lean-Thinking.  Lean suggests systems support our people. But this presumes they are capable of getting their work done. Putting people into a potentially Agile system does not teach someone actual Agile skills.

Continue reading “Lean Thinking on frameworks vs. the work in them”

Scrum FLEXed

Scrum’s roles, events, artifacts and rules are immutable. Ironically, immutability is as non-Agile as one can be – so why is this? When difficulties arise in how work is being done a question must be asked – “are we doing the right thing poorly or just doing the wrong thing? Scrum pre-defines the “right” thing & says keep working on until you do it correctly. But what if these are not ideal for your situation? What do you do then? Continue reading “Scrum FLEXed”