Q: Are there a few tactics that folks like me—who work on a legacy program with a long history of “doing things the way we do them”—can engage in that would most effectively help tip the culture over to embracing the agile/lean/DevOps (A/L/DO) mindset?

A: I have discovered that adopting A/L/DO mindset is a challenge. Since Agile is a value system and a set of principles, making changes at the team level without a change of values above the team will result in a lot of frustration. I call this the Agile Trap:

Email exchange with a client regarding starting the journey to transition a traditional command-and-control mindset to a Lean-Agile mindset following a presentation at the Raytheon Joint ISaC/SE&A TN Symposium back in April. Below is a paraphrase of the email exchange.

Lean-Agile Consulting

That stated, there are some things you can do that can help you “Be Agile” even though it may not look like you are “Doing Agile”. Don’t get caught up in the trap of scrum ceremonies, sprints, story points and burn down charts. These can be useful, but are largely noise.

Here are some key things to do to “Be Agile”:

1) Build off of what is working. Don’t ever try to remove and replace. Agile is not a process. Agile may change how you instantiate your process over time. Use the good things in your culture as building blocks. Learn how to do what you do best in a different way that reduces cycle-time and provides a sustainable delivery of small batches of value to your customer.

2) Create fast feedback loops – Once work is completed, have someone consume that work as soon as possible. The consumer has to be the person who has approval authority for the work being performed.

3) Map your value stream – Understand how work is supposed to flow through your development/O&M system. Map this from Concept to Cash. In an O&M organization, this is generally more straightforward. How does new work come to the team (ECP, DR, …).

4) Create small batch sizes and have work flow through the value stream in small batches. Work is generally organized into work items that represent customer value. These can be called Epics, Capabilities, Features, etc. Sprints are used sometimes to create batches. I am not in favor of this. Take a look at Kanban methods and allow work to flow naturally.

5) Limit work in progress – Organize your team around the work (e.g., Feature Teams). These must be cross-functional, this is a cross-functional reality. Don’t start new work until some work in progress has finished. Focus on Finishing, not on Starting.

6) However long it takes to build, package and deploy your product, work on reducing the time and effort to do so. New value (code changes) made yesterday and delivered to the product baseline should be looked at and verified by someone today. Reduce queue lengths and reduce overall cycle time.

7) Create a culture of SW trunk development – Rely on your CM system and processes to maintain a controlled, high quality baseline. Have all teams continually integrate and test their code in a production-like environment. Drive the trunk to a stable state daily. This is a big challenge but this is probably the most important thing you can do to coordinate the work across teams and improve effectiveness.

When trying to change the culture, it is not usually very effective to talk about sprints, daily standups, story points, etc. This is noise and turns virtually everyone off. The key is to talk about well-established principles of product development flow.

Keep your eye on the BEING, not the DOING.

Also:

There is a lot of literature out there. I will recommend a short book that I found a couple of years ago that I like a lot (mostly because it is short). It is called Leading The Transformation – Applying Agile and DevOps Principles at Scale by Gary Gruver and Tommy Mouser. I think it is a great place to start.