The Lean-Agile Manifesto

Originally published October 20, 2017

Context / Intent for Article

I have seen the Agile movement grow from when we new a fraction of what we have now and didn’t have a name for the overall approach. XP and Scrum were gaining ground. We talked about the value of co-location, self-organization, quick feedback and deliveries. Different people had different approach (there were Scrum and XP ‘wars’ during this time) and the Agile moniker was created with the Agile manifesto. Given that Agile, at the time, was focused on teams and didn’t require much management involvement (other than to let the teams self-organize and to not interrupt them) the Agile Manifesto reflected this.

As Agile moved to multiple teams, it was natural to try to expand Agile via current existing Agile methods. So Scrum-of-Scrums was born. Unfortunately, inter-team dynamics are not the same as intrateam dynamics and this method usually only worked in few situations where it was applied. Continue reading “The Lean-Agile Manifesto”

FLEX: FLow for Enterprise Transformation

Goal: Achieve business agility: The quick realization of business value predictably, sustainably and with high quality

Why: The purpose of an organization is to provide value to the customers and a great working environment so that their employees can manifest a sense of purpose and be acknowledged for that

What: Achieve flow in the organization using Flow and Lean-Thinking, culture, organizational development, human behavior, laws of software development, effective leadership and management

How: Provide a starting framework to an organization that has been tuned for the organization and a method to improve it on an ongoing basis

Continue reading “FLEX: FLow for Enterprise Transformation”

What We Can Learn From Mob Programming

Originally published Dec, 12, 2017

First, full disclosure. I have never used or even seen mob programming.  When its creator, Woody Zuill, first mentioned it to me I was intrigued but wasn’t sure it would work efficiently. But, knowing Woody, I didn’t doubt it worked. Just figured only for small, independent teams.  After talking to him recently I have changed my mind. This blog is my understanding of mob-programming now, inspired by Woody’s insights. Attribute anything valuable about mob-programming to Woody, anything incorrect to me.

The question for me about mob programming has always been – how big can you go with it?  I have known that paired programming was good (having done that).  Of course, people ask the same thing about that as well – how can two people doing the same thing be effective?  Of course, that’s a misunderstanding – they are not doing the same thing – they are working together. So, we already know that micro-mob programming (a mob of 2) works.  But what’s the upper limit?  How would you discover that?

In the conversation I just had Woody told me:

With some questions it’s very useful to identify an “opposite” question.  This can lead us to finding more meaningful questions. He said the first question he was ever asked while speaking about Mob Programming was “how can you be productive with five people sitting at one computer?“

The reverse question he came up with was “how can we be productive if we separate the people who should be working together?“ The purpose of asking the reverse question is to show that there are more possibilities in the questions we could ask, and in particular when the original question is not easily answerable. This led him to a slightly better question, which is “What are the things that destroy productivity?”   And of course, productivity is probably not a good thing to strive for, and he usually prefers to talk about effectiveness.

So what destroys productivity (or effectiveness)?

  1. Hand-offs
  2. Waiting
  3. Meetings
  4. Unfinished code that you’re not actively working on
  5. Unclear understanding between team members
  6. Delayed feedback on errors you’ve made
  7. Integration problems

There are probably other things not listed. Woody tells me these things don’t happen when you do mob programming.  While I have not seen it, I believe this to be true because Woody is a very trusted source whose only agenda is helping people. It also makes total sense when I stop to think about it.  Furthermore, when I look at teams whose individuals don’t work together I see these things taking up about 80% of their capacity. So even if mob-programming is a bit less efficient because of more people working together than is needed, the elimination of 80% of what teams normally do probably more than compensates for that.  It also produces higher quality code and a broader understanding of how it was built – meaning the team won’t run into the constraint of only one person knowing how it was written.

So how many is too many? I like the observation – “In theory, theory and practice are the same, but in practice they are different.”  So I’m not looking for a theoretical limit.  The real question is when are people not contributing?  Contributing doesn’t mean just doing the work but includes learning since that, as we mentioned, improves the people and the organization. Woody, of course, has thought this through. This is one of the great things about him – he’s not trying to promote or defend anything – he’s just looking for what works. So, the solution is easy – just people the option of self-selecting out when they feel they are not making a contribution. They will still be close by when needed.

There is another aspect to mob programming.  It sounds like fun.  So give it a try and pick a number you feel comfortable with.  Then try a little bigger (remember, people can self-select out).  Having fun has clear personal value, but also clear business value.

Al Shalloway
CEO, Net Objectives

Postscript: I talked to Woody at the Deliver Agile conference in Nashville this week. Here’s another point on mob-programming. It’s all about flow and true value delivery. When I consider that most organizations are running at around 5% efficiency (not a typo – five per cent) then mob-programming, even if it were a slight waste with 5 folks around at once, would be a massive improvement).

How Using MBIs Ties Strategies, the intake process, ATDD, and planning together

This is an excerpt from Introducing FLEX – FLow for Enterprise Transformation: Going Beyond Lean and Agile (online book). If you are looking for an alternative to SAFe, this is it. To those who’d like to study along with me as I publish this on linkedin, please ask to join the True North Consortium Linkedin Group where I will be happy to answer any questions or, even more importantly, discuss things you disagree with in the book. S

If you want to learn more about FLEX you can watch a webinar on FLEX, take an online course at the Net Objectives University or take a live course in Orange County, CA May 6-8 or in Seattle in June (both led by Al Shalloway). If you want to learn about how to adopt FLEX in your organization please contact the author, Al Shalloway

The concept of the minimum business increment (MBI) is key to Agile software development because it provides us with a container for all of the items required to realize value for a business increment. Its focus on being “minimal” provides us with the smallest batches possible, a practice proven to be effective. This alone would make them worthwhile. But they have another value, they tie strategies to the intake process, facilitate the use of ATDD and assist in planning. This chapter discusses both how and why this is so important.

Tying Strategies to the Intake Process

Business stakeholders and product managers provide the development group what to work on. Very often this is with the development group as they may be the originators of what to work on. By using MBIs, the development group gets smaller batches than they would otherwise. This is one of the best ways to manage work in process – have smaller chunks of work come in. The content of the MBI, that is, all of the tasks required to realize value, also provides the development group insights on who they will have to work with to get the software out the door and realize value.

Using MBIs to feed ATDD

ATDD is our recommended way to decompose and refine requirements. MBIs are containers of all of the features and stories that will be developed. By peeling off vertical slices from the MBI using ATDD, the MBI can be used to see what’s left to decompose while ensuring all necessary components of it are defined. By decomposing MBIs into features and then stories, teams also avoid features and stories that are bigger than needed. Without the MBI, team often work on an entire feature even though only part of it is needed for the first MBI.

Planning with MBIs

Big room planning in SAFe has people focus on getting features completed. However, features by themselves may not be releasable where they will provide value on their own. It is therefore possible to schedule features to be completed but not have something to release until the end of the program increment. It is better to schedule the completion of the MBIs, not the features. This manages work in process in a natural manner.

Why Not Having Adopted Agile Yet May Be Your Best Competitive Edge

Most companies have gone to some form of Agile in order to keep up with the competition. For large companies the ‘Agile’ method of choice is SAFe. While promoting a project to product mentality, its complicated portfolio & product management approach makes this very difficult to achieve. It devolves to a large scale project management system spouting Agile euphemisms while not truly creating a Lean mindset.

After watching SAFe continue to diverge from Flow & Lean thinking, I am convinced that organization looking at how to be Agile should take an approach that more directly focuses on Flow & Lean & less on a framework purporting to use them.

In my mind jumping to these methods directly, instead of taking the disjointed collection of them is a less risky path than SAFe. Especially due to its insistence on a one-size fits all jump in all the way which is actually not a safe thing to do.

Jumping to Flow and Lean thinking provides a competitive edge. And uses more advanced and mature practices than what has become popular by just using a few of their principles. The risk today is not in taking a lead, the risk is in following the crowd down a comfortable but less effective path.

This is not part of my series of posts on how Agile has become unagile but is, of course related.

if you find this post interesting you might want to check out my upcoming (May 3) webinar on FLEX – not another framework but a thought process you can use to solve your problems.


Step 2: Shift from Agile at the team to business agility

Agile is a great ideal. It feels good. It is a call to liberation. We should never lose this. But we must also remember Millard Fuller’s observation “It is easier to act your way into a new way of thinking than think your way into a new way of acting.”

This means working together will get you to trust and respect faster than saying to trust and respect each other will get you to working together. The latter is a nice thought but doesn’t work with divergent roles and values.

Continue reading “Step 2: Shift from Agile at the team to business agility”

Step 1: Acknowledge the need to move from a team focus to systems thinking

“We cannot solve our problems with the same thinking we used when we created them” Einstein

The team focus of 2001 is no longer viable. Early adopters could adopt Scrum without regards to the bigger picture. The key was having a cross-functional team that Scrum and XP were designed for.

But as soon as Agile spread beyond one team, it ran into challenges. Team dynamics are different from organizational dynamics. Scrum ran into problems because forming cross-functional teams required committing someone who was needed on several teams to one team. Agilists didn’t have methods that solved this problem.

Continue reading “Step 1: Acknowledge the need to move from a team focus to systems thinking”

How did Agile become so unagile

For a movement that’s about quick delivery, continuous learning, innovation & flexibility, Agile has lost its way.

Organizations with good minded people who see better ways to do things are faced with massive delays to get started because Agile has become a huge endeavor – an anti-thesis of Agile. Agile would say “start and learn.”

Continue reading “How did Agile become so unagile”

The falsehoods in the truth

I think Scrum is a good framework when it is used where it was designed for – a cross-functional team creating a new product. This, of course, represents a very small number of the time where it is used. The variation in where it is used requires a variation in the framework. This seems self-evident to me. But the response I get to this is “people need a well-defined, clear, set place to start.” I agree with this. But does it mean the place to start is the one people are promoting? I don’t think so.

From the Scrum guide, “Scrum’s roles, events, artifacts, and rules are immutable.” To me this means they are not as applicable as possible to most teams’ context since no one size fits all well. And Scrum is designed not to adapt – it works because of how it is defined.

When pressed on this, I get “we must keep it simple.” But this is the second falsehood. It implies that tailoring it to the need at hand will be more complicated. It doesn’t need to be. We must remember we need sufficiency as well – “as simple as possible but no simpler.”

My solution? Get a consultant who can quickly identify the ‘well-defined, clear, set place to start’ that works for your situation. Many consultants can do this, others can’t. Find one who can.

How to do SAFe “by the book” better than the book

I hear many C-level folks mandating doing SAFe by the book. This post is for those of you who need to do this but want to take advantage of the fact that SAFe is a framework and can therefore be modified to some extent.

As a former contributor, SPCT & gold partner I can give you some advice you won’t get from SAFe partners.

1) Find an SPCT that is not dogmatic about SAFe. Talk to a former client. Everyone says they are not dogmatic. I can give you a referral with no strings or cost attached as well.

2) Make it clear what an MVP is. The inappropriate use of MVP in SAFe in non-startup environments has caused confusion. If you don’t make it’s meaning clear it will mean everything, and therefore nothing.

3) If you have platform teams, ensure you set up your trains accordingly. SAFe gives little guidance here. Use Kanban to manage their work driven by other teams & prioritize by MVP importance. Chapter in book is coming soon.

4) Take ATDD up front and don’t think you’re getting it in the ASE. ATDD is a collaborative method with POs, devs and testers. By relegating ATDD to 2nd tier training & making it a technical offering SAFe is doing you a disservice. We offer ATDD training with SAFe if you’d like to learn more.