Category: Agile at Scale

Four steps to move you to Business Agility

I work with many organizations that are fairly chaotic and far from Agile. While I’ve led fairly involved transformations, there are four actions a development group that’s 50-300 in size can take, mostly on their own, that can have a great impact. These are:

  1. Use Minimum Business Increments (MBIs) to identify enhancements to make to the system
  2. Have an intake product backlog (even better to add service classes) where all work in the system can be seen
  3. Organize around product teams. These are teams that can develop the MBIs defined. You can then create Scrum-Kanban teams (8-12 people) if the product teams are too big.
  4. Do DevOps phase 1- create visibility between dev and ops so ops knows what coming and dev understands what ops needs. Work together even if you don’t take steps towards continuous integration and continuous deployment.

These straightforward steps can be done quickly. Even if you are planning on using an Agile at scale approach, taking these steps early will help prepare for that.

Creating cross-functional teams is more effective than coordinating teams with dependencies

Many companies find themselves organized around projects that come to their development group from all directions. There often isn’t even a backlog to see what’s to be worked on. This results in teams working on multiple projects at a time, multitasking, waiting for others, and general chaos. Short projects take months.

One solution is to get all of the groups of interrelated teams together every 3 months to do a big room planning event. This is putting all of the work that needs to be done over the next 3 months in a backlog and having the teams spend a couple of days ina big room planning together how they will manage it.

While not truly Agile, it is definitely an improvement in many ways:
1) all work is now visible
2) dependencies have been mapped
3) teams are now collaborating with each other

But this is really an accommodation to the challenge of value streams (workflows) that cut back and forth across teams. A better approach is to create teams that can get the work done on their own. This may be larger than a standard Agile team (8-12 people). But it can be subdivided into smaller teams with few dependencies between them. This is a much easier problem to solve.

We shouldn’t be surprised by Dark Agile. We should be surprised Agile works as well as it does

Our Agile at scale methods are often like driving on the wrong side of the road in reverse during a rainstorm. While the driver’s are well intended, and may even appreciate that at least they’re in a car, that are better ways. Here’s a list of things we must do that are usually not done when attempting Agile at scale.

Continue reading “We shouldn’t be surprised by Dark Agile. We should be surprised Agile works as well as it does”

Challenges I’ve learned how to solve by attending to Business Agility, Flow, and Lean

Business Agility sets the why and goal. Flow and Lean both provide insights on what to do and how you are doing.

Here are some challenges they help overcome:

Continue reading “Challenges I’ve learned how to solve by attending to Business Agility, Flow, and Lean”

Slower, Better, Cheaper- Why Scaled Learning Is Our Future and How to Get it Today

There are two types of classroom training – one where the instructor dumps information into the students minds. The second when labs are involved so that students are mostly interacting with the instructor or doing work.

This post refers to the first type.

Classroom training is centuries old. The recent fad of adding exercises and games helps, but doesn’t change the fact that the students forget 80-90% of what they’ve learned after just a week. Training is also focused on a canned solution instead of people’s problems.

Continue reading “Slower, Better, Cheaper- Why Scaled Learning Is Our Future and How to Get it Today”

The 3rd Decade of Agile – The Cathedral and the Bazaar

My #Agile2019 talk discussed what’s next for Agile to improve its offerings at scale. The most significant of these is the shift from the Cathedral to the Bazaar. I am referring to Raymond’s book “The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary” which discusses how the Bazaar (Open Source software) rose to challenge, and in many areas, surpass the Cathedral’s (Microsoft) dominance.

Continue reading “The 3rd Decade of Agile – The Cathedral and the Bazaar”

Creating a True Community of Service Providers for Agile

FLEX’s unique architecture enables it to incorporate any # of practices that are consistent with Flow and Lean. Based on this ability I have created the the FLEX Partnership program which allows FLEX Sr Consultants to provide their own services in FLEX. We’ve already started this with Nancy Van Schooenderwoert who is an expert in both FDA regulated product development and hardware/software projects.

Continue reading “Creating a True Community of Service Providers for Agile”

Refactoring SAFe to FLEX part 1 of 2

Frameworks should be architected in the same way that software systems are. Both need to be able to evolve without adding complexity, be robust and be clear in how their different components interact. Few frameworks, other than FLEX, however, have what could be called an architecture. Most are collections of value and practices loosely overlaying some principles (which, often enough the framework itself doesn’t follow well).

Continue reading “Refactoring SAFe to FLEX part 1 of 2”

The Foundations of FLEX

When I started writing up Net Objectives’ 14 years of experience in Agile at scale that has now become FLEX I came from a foundation of the following:

  1. FLEX itself is an hypothesis of the best way for an organization to have a customer realize value. As an hypothesis, it should be continuously tested, validated and improved.
  2. How people react to FLEX must be considered to be part of FLEX (this is a basic tenet of systems thinking, albeit often ignored by most frameworks)
  3. FLEX must both attend to how to provide a well-defined start and how to extend the start
  4. It must be based on the value stream so that it doesn’t inadvertently do sub-optimization
  5. Technical skills must be included in the system and should be considered when deciding on a starting point
  6. Although users will extend FLEX you never transcend it in the sense that what it’s based on is always valid. People will just come up with more innovative methods to use known principles

Continue reading “The Foundations of FLEX”

FLEX’s launch this week is a harbinger of the next wave of Agile

The Adopting FLEX online workshop gets into full gear next week. I believe this is the start of the next wave of Agile on many levels

Since ’05 I’ve been working on overcoming several challenges:

  1. people need a specific start but there is no one-size fits all
  2. expanding an approach tends to add complexity to it
  3. on-experts often can’t tell if a change is good or not but need this ability in order to be able to improve on their own
  4. providing optional practices so people don’t have to reinvent the wheel, but do this without causing confusion
  5. provide a simple model for Agile product management that aligns both business stakeholders and development groups
  6. provide training in an economical way that doesn’t stop people doing their day jobs and actually enables more interaction while learning

FLEX solves these challenges by incorporating approaches various Net Objectives consultants have done over the last 20 years. FLEX is an expert system that guides consultants in how to help an organization improve by both providing guidance and creating a shorter workshop tailored for the organization that will implement FLEX.

I am excited to have a group of people working with me on taking this into the future.

Learn more here