If you are having troubles with Agile at the team level you should read this - Scrum as Example. It is designed both for those using Scrum and those about to start. It is an extension of Scrum in that you can start with Scrum (the practices in the example are Scrum practices), but by realizing that these practices represent decisions that Scrum has been made for you, it gives you the opportunity to make better decisions when your context warrants it.
Continue reading here if you are interested in why Scrum often gets teams into trouble by its design, training method and promotion approach.
The Challenge of Scrum
Everyone acknowledges that there is a lot of bad Scrum out there. People often do some of Scrum's practices but not all. This has derisively been called "Scrum but." Unfortunately, the cause of this is inherent in the way Scrum has been designed, the way it is taught and the way it is promoted.
The Design of Scrum Is Flawed
Scrum is designed to discover impediments to development in a couple of weeks (for the purpose of this article we are assuming 2-week sprints are being used) and then to remove them. For example, interruptions, not having cross-functional teams, and doing daily standups. The idea is that by removing impediments you will be able to do Scrum properly. While Scrum can lead to success if can follow all of Scrum's prescribed practices, they are not always the best practices for a team to be doing. This leads people to stick with Scrum even when it is not appropriate and they do not know alternatives that will meet the same objectives.
The Challenge of How Scrum Is Taught
This situation is exacerbated by how Scrum is taught - "use the Scrum practices until you understand them and can go beyond them." The challenge here is that using them as defined may not get a team to effectiveness. So teams struggle with the Scrum practices. Unfortunately, they've been taught to follow Scrum as is. Their understanding on why they are doing the practices is not deep. This leaves them to try things on their own when they can't get the practices to work. Without understanding this often leads to just different bad practices.
The Promotion of Scrum Makes Things Worse
This situation is exacerbated again by how Scrum has been promoted. Many Scrum proponents have equated Agile to Scrum, ignoring the fact that Scrum is just one way to achieve Agile. But the impression for people who have decided to do Agile is that they should start with Scrum. Furthermore, Ken Schwaber, one of the creators of Scrum, says "Scrum is simple, just use it as is." The challenge here is two fold. First, consultants who only know Scrum and make their living off of it succumb to what Upton Sinclair referred to by saying "It is difficult to get a man to understand something, when his salary depends upon his not understanding it!". The second is it sets up the notion that Scrum is providing an answer to the teams and it'd work if they'd only follow it. This is why, if you want to use Scrum, it is better to use someone who also knows Kanban. S/he won't be attached to either.
The bottom line is that these three things combine to have people learn Scrum, try to follow it, and then not know what to do when it doesn't work.
Getting Out of the Trap
I am not suggesting that Scrum should not be used nor should people abandon their investment in it. Just the opposite. I created Scrum as Example so that one can still use Scrum while getting out of the above traps. Being aware of these traps is important, however, as it is easy to fall into them.
Another way out of the trap is to consider Scrum as a tool in your toolbox and not the entire tool box. Scrum has many brilliant ideas. It is where I learned the value of teams. But as a toolbox, Scrum may be a trap.
In mid-January we’ll become a bronze partner with SAFe after being gold for about 5 years. In reality, we’ve never been much of a SAFe shop. Our SAFe related revenues always being a very small percentage of our business. But more importantly, we’ve never done SAFe by the book. Even our first SAFe implementation at Northwestern Mutual, which ended up being a case study, was done against the “all-in all-the-way” implementation method somewhat demanded at the time. In addition, we added several practices that weren’t in SAFe that were key to its success.
We had already been effective at scale prior to SAFe and had significant overlap with SAFe when it came out. We have promoted SAFe because:
SAFe promotes some ideas that have been woefully missing in the Agile consulting industry
We’ve always felt that improving SAFe is a way of improving the industry
We were early contributors to SAFe in two ways. First, we were formal contributors by giving them our IP in Acceptance Test-Driven Development and Test-Driven Development. I also co-taught 3 courses with Dean, Jennifer and Alex. During these courses I taught the architecture sections and how Kanban can (should) be used for shared services. Several of the concepts I discussed showed up in later versions of SAFe which was my intent.
But we’ve always held a different view from SAFe. We’ve always believed in coming from business value, not starting by tying teams together. I recollect re-arranging the Leading SAFe deck to teach by the flow of work, and not bottom up. This reflects what still remains one of the biggest differences in our own approach and SAFe – we prefer to take complete value streams and work on them partially than take the SAFe Essentials view of taking only part of a value stream completely.
I don’t anticipate going from gold to bronze to change our attitudes much about SAFe. We’ve never been attached to is as evidenced by past blogs:
So why make the change now? Since starting out closely with SAFe our intentions have diverged. We have always wanted to provide the best methods possible to people. SAFe is going for a different direction – having the largest impact industry wide. In our case we can take advantage of having consultants with an average of 15 years experience in Lean and Agile methods. SAFe is going after methods of improving organizations having little experience. This is a good thing – demand has clearly outstripped supply.
But the result has been SAFe has become a somewhat commodity market – never Net Objectives’ calling. We are remaining a partner for 3 reasons:
We want people to know we understand SAFe even if we don’t use it a lot
We want to be able to help people who have reached the limits their SAFe adoption will take them
We want to provide alternatives to those considering SAFe that want a more tailored approach or don’t feel they need such a large framework.
This is why we are now documenting FLEX and letting people know about it being an alternative to SAFe – particularly in the mid-scale arena (50-1000 people in technology).
BTW – if you are looking for seriously good SPCTs who implement SAFe consistent with SAIs approach but have a flexible attitude, check out Martin Olson and Armond Mehrabian. These are both trusted associates of Net Objectives and I don’t think you’ll find better in the SAFe space.
Of course, as bronze partners, if you want to check out SAFe implementations, give me a call and check out our FLEX/SAFe site.
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 mis-understanding – 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)?
Unfinished code that you’re not actively working on
Unclear understanding between team members
Delayed feedback on errors you’ve made
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.
Before Agile crossed the chasm it was being adopted mostly by teams. When it crossed the chasm it started being adopted by organizations. Unfortunately, the early success has become a massive bog. So many companies have had such bad experiences with Agile that it has become a bad word in some places. What is so different about Agile as it started and Agile at scale?
Our goal at an organizational level should be achieving quick realization of business value predictably, sustainable and with high quality. This also increases the ability to pivot as needed. Agile at the team naturally works by creating an eco-system where people work together with few delays in workflow, feedback and between getting information and using it. To accomplish this when multiple teams are involved requires a shift in management from focusing on their people to focusing on the flow of value across the organization. “Who is managing this value” is often a question that is left unanswered in many organizations.
What we need to do
Building software, as in many product development efforts, one must:
Understand what needs to be done
Decompose the work into small implementable pieces (this decomposition should be slices of functionality so that they can be built quickly for quick feedback and potential delivery)
Focus on building the most important work to be done (based on value or feedback) and manage your work in process to build it efficiently
Continuously get feedback from the business to make sure what is being built is of value to the organization and with the customer to ensure it meets their true needs
Deliver as quickly as possible
A side effect of Agile methods is that there are fewer and quicker handoffs than before. The mere co-location of teams, focusing on one thing and using time-boxing achieves this. This is the unacknowledged reason that Scrum can work so well. It’s not so much the self-organization as it is setting up the eco-system within which the developers work. Cross-functional teams naturally reduce delays in workflow, feedback and useful information exchanges. These are three key ingredients for effective and efficient development.
Agile across the organization
Achieving these is a not tremendously difficult when you have a standalone team. However, focusing on improving individual teams is often counter-productive to improving the multi-team development. Intra-team dynamics are quite different from inter-team dynamics. At some point the challenges of working across the organization become more important to solve than the benefits Agile has achieved within the teams. Using Agile to solve the bigger picture is often akin to using a hammer where a screwdriver would be better just because you have one.
But when many different teams are involved what you have to do in order to accomplish the above items changes.
1.Understand what needs to be done. This is now no longer merely understanding what feature needs to be built but rather what investment the organization should be making.
2.Decompose the work into small implementable pieces (this decomposition should be slices of functionality so that they can be built quickly for quick feedback and potential delivery). The size of these chunks are larger now, and are going to be given to multiple teams. The decomposition must be done so that multiple teams can implement them quickly with high collaboration.
3.Focus on building the most important work to be done (based on value or feedback) and manage your work in process to build it efficiently. It’s now not ‘most important’ for the team, but most important for the group of teams. This requires both a planning and coordination across the teams. This decision is usually beyond the teams’ purview and almost certainly beyond their authority. Business stakeholders are usually the appropriate navigators of the organization.
4.Continuously get feedback from the business to make sure what is being built is of value to the organization and with the customer to ensure it meets their true needs. This gets a lot harder when a team is working on multiple chunks of business value from different stakeholders because they have skills and/or knowledge that is limited in the organization.
5.Deliver as quickly as possible. The delivery is no longer at the team level which likely has no value to the customer without the pieces from the other teams involved. The focus needs to be delivery of value to the customer.
6.Continuously learn. While we must continue to have our teams improve we must also look to see how to improve our work across the teams.
And now there is a seventh one. When multiple teams are involved we require other methods to reduce the number of handoffs required and remove delays in workflow and feedback. While this naturally occurs at the team level, it does not at the organizational level.
Solving a Different Problem
Clearly, the challenges at one team are quite different than when multiple teams are present, especially if the multiple teams are inter-dependent upon each other and the business stakeholders are competing for their capacity. Using a team focused software development method quickly devolves into a shadow of itself when attempted for where it was not designed.
Most organizations are organized by function, e.g., marketing, product management, development, support. Even if not highly siloed this leads to a kind of top down management structure. Managers have been trained to see if their peoples’ productivity, quality, and utilization. Not only does this tend to create a command and control attitude, it ignores the fact that our work runs across the organization. In other words, we should be managing the flow of work from start to realization. But in most organizations, no one is managing this. At best, it is a shared responsibility. Watch the first four minutes of Hierarchy vs the Value Stream to see this visually.
What we can do
First, we must attend to the whole and that a systems-thinking approach is required. We must also realize we are solving a different problem. What we now want to achieve is business agility. This is the quick realization of business value predictably, sustainably and with high quality. This is a different focus. It’s not that we don’t want Agile – we do. But we should realize that the drivers of those in the executive suite are different from those in the development arena. We all need to align and that should be on the mission of the organization and each group comes together to achieve it.
I am proud of the fact that I have been accused of method hopping. I have and I do. The question is why. Essentially I use whatever method I find to be valuable. Some have come and gone as being at the top of my list. Twelve years of building and expanding our own I finally see value in documenting it and using it as our explicit platform. But let me explain my history. This is not just a personal story, but is intended to illustrate some learnings.
In the 80s I started becoming reflective about my coding abilities. I was an extremely fast developer who wrote very brittle code. I had a reputation for being 10 times faster than the next best person. In 1984 I noticed a bug (I’m pretty sure not my first) and asked myself for the first time “what was I doing that I put a bug in my code.” I noticed the irony that before this I always described it as “I found a bug” but this was code no one had been in before, ever. I then realized the irony of asking the question and asked “how could it have taken me 14 years to ask this question?” From this point on I started to consider the source of my bugs as often being a result of the environment I was in. Not a coincidence that at this time I was also studying Deming in a 2 year long business seminar.
When I was introduced to XP in 1999 I was immediately struck by two things. First, it’s brilliance. I knew it would work because I had done most every practices at some point in the 15 years prior (for example, automated acceptance testing in 1983). However, doing the practices in the isolated way I had and doing them without a model to guide my actions was the equivalent of eating an ice cream bar with the wrapper on. I had clearly never been doing XP before 1999 even though I may have done most of its aspects. This impressed upon me the importance of a framework for thinking and the value of explicit knowledge. It also impressed upon me that I typically came up with what were later known as XP practices as a result of needing to fix a problem, but that doing so one, didn’t have me always use them and two, had me re-invent the wheel a lot.
When I couldn’t get development teams to pair-program I switched to Scrum. This, I believe is my one real sell-out. I see now that working more on getting XP adoption would have been good. BTW – pair programming is an interesting example of something that easy to explain and even easy to do. But difficult to get people to do it. After using Scrum for about 4 years, we started getting into Scrum at scale. Back in the day (2004) this was 3-4 teams. Scrum of Scrums was the in thing so we tried that. Couldn’t get it to work (still haven’t figure out how).
Our president, Alan Chedalawada (who is the one who originated most of our business driven philosophy), decide to try shared backlogs based on our prior Lean experience. It worked well, and Guy Beaver and I wrote some of this up (2009) in our Lean-Agile Software Development book and called the method the product coordination team – which is essentially what people now call Scrum-of-Scrums where the teams collaborate on what they will build before self-organizing on it.
It was clear to me that Scrum as limited to its practices and mindset on how to find impediments and remove them was great for a team but limited for an organization. Lean was providing us insights on how to see the major impediments with just a few conversations (see Value Stream Impedance VSI). Most people already have the ability to see this, but making the VSI more explicit enhances that ability. I started talking about the importance of Lean in Scrum around 2005 after having quite a bit of success in doing so. This was not appreciated by the Scrum thought leaders of the time and they accused me of trying to sell my own method (as if I owned lean).
I was in this dilemma of knowing there was something better than Scrum at the organizational level (for which it was not designed) and having to make agreements about what our CSM courses were containing. I decided in favor of going for customer value even though this definitely cost me hundreds of thousands of dollars in certification fees (at the time we were barely a million dollar company so this was a significant decision.
Fortunately, this was about the time Kanban came out so I joined forces with David Anderson. Unfortunately, his Kanban method ignored many of the good lessons we’d learned from XP and Scrum so we had a parting of the ways. At this point we did a combination of Scrum and Kanban and called it Team-Agility.
I found out about SAFe coming out and had a conversation with Dean about it. The challenge for me was mostly people were following Scrum and its bottom up scaling approach. Ken had even said one should always avoid getting teams to work together as that was less efficient. However, using Lean can create more efficiency and having small teams on big projects may increase efficiency but delay the realization of business value. SAFe addressed many of the issues that needed addressing. See Not Doing SAFe? No Problem. Not Doing These? Big Problem. We became SAFe partners (eventually Gold) because SAFe was exposing issues that had been ignored. I never endorsed the “all-in-all-the way” approach. In fact, in our first SAFe implementation at Northwestern (now a case study) I had to insist on our approach of doing it in phases. We also added many new practices that were not available in SAFe at the time (Kanban at the shared services level, more detail on emergent architectures, …).
SAFe has been an explosive success. Some people tend to dismiss this as marketing prowess. But there are three important reasons for this:
People want an answer
Large organizations can often only move forward with a set agreement
The demand for Agile at scale is much greater than the supply of experienced consultants
Hence, SAFe plays an important role in the Agile space – providing large organizations to move forward with less experienced people. This is a good thing. However, it’s not our thing. So, over the last few years we’ve been writing up more and more about our approach. While FLEX may be new, most of what will be on its website in the next 12 months comes from documents written over the last 8 years.
Finally, one other thing to point out. Since 2005, Lean has been the basis of my thinking. FLEX goes well beyond Lean, but Lean provides great insights into how things work in software based business development. Bottom line, I stick to things when they work. Move onto news things that I’ve discovered are better. I regularly challenge Lean-Thinking. Just a few years ago I admit to thinking it could explain most everything. Then one my folks (Luniel de Beer) introduced me to Turn the Ship Around (awesome book) and I realized this was a different model for management than Lean profess. Not inconsistent, but different. When you find one exception you know there are others. Perhaps this is why in the past couple of years I've seen so many other things that I hadn't totally appreciated. Yes, I wish I could have learned these sooner. But I learn at the rate I can and move along as new ways come up. This is why I said we use Lean-Agile as a backbone and it's not our method.
It's also why FLEX is being updated dynamically as we learn. I believe our Lean-Agile methods shold reflect our continuous learning. It also means my "hopping" days are over as FLEX will continue to be adjusted as our learning expands.
This was not intended as a vent, btw. I find that looking at the history of things to be valuable. Hope you found some value.
Net Objectives FLEX system (FLow for Enterprise Transformation) is guided by Lean-Agile thinking. There is much misinformation about what Lean is in the software world and even different opinions about what Agile is. Given that Lean and Agile are integral parts of the FLEX system it important that we have an understanding of what they mean.
What Is Lean?
Although the term Lean was coined to describe Toyota, and to lesser extent Honda, it’s become reasonably synonymous with Toyota’s Production System. However, we are not only not in manufacturing, we’re not even in the physical world. Software is quite different than both manufacturing and physical world product development. However, the core of Lean can be found by looking at the mindset Toyota had when they did what later became called Lean. Given Toyota’s commitment to continuous improvement and learning Lean is not a static definition – but rather an evolution of both understanding and practices to achieve its goals.
In a nutshell, the tenets of Lean are:
management must be involved in leading the change
we must take a systems-thinking approach
we must have a commitment to the quality of both how we are doing the work as well as the quality of the work
we must respect people – give them a good environment within which to work but also recognize they may not embrace self-organization immediately
make all work visible
strive for flow by managing queues and work-in-process (WIP)
drive from achieving the goals of the organization – be clear on the target value being manifested
Given we are not in the physical world we must apply these tenets differently than we would in manufacturing and physical product development. Visibility and managing WIP have overlapping goals one of which is to see delays (they show up as items in a queue).
Lean, however, is much more than the above. It is also about creating pride in our work, striving to be the best and personally making a difference. An example of this is one reason that Toyota builds different cars on the same assembly line – it is to make the work more interesting and to keep people “on their toes.”
What Is Agile?
There are huge differences of opinion here throughout the Agile community. Net Objectives has never subscribed to the common view that the Agile Manifesto, written in 2001, is the one sacrosanct definition. There are two reasons for this. First, the Agile Manifesto is not based on systems-thinking which we feel is a necessary agreement for organizational change. The second, after a few years it appeared oxy-moronic to us that a manifesto suggesting we be agile and to accept change is cast in stone. That being said, there is much to learn from the manifesto.
Where Agile and Lean Have the Same Intentions
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. (Principle 3)
Business people and developers must work together daily throughout the project. (Principle 4)
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. (Principle 5).
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. (Principle 8)
Simplicity--the art of maximizing the amount of work not done--is essential. (Principle 10)
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. (Principle 12)
Where Agile Goes Beyond Lean
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. (Principle 2)
Working software is the primary measure of progress. (Principle 7)
Continuous attention to technical excellence and good design enhances agility. (Principle 9)
The best architectures, requirements, and designs emerge from self-organizing teams. (Principle 11)
Lean and Agile Are not the Same
Agile was very much influenced by Lean, but not all of Lean was embodied in Agile. At the time of the manifesto the two most popular methods were Scrum (at the time sometimes considered synonymous with Agile) and eXtreme Programming (which is closer to Lean than Scrum) were inspired by articles written about Lean companies. Most significantly attended to was Hirotaka Takeuchi and Ikujiro Nonaka’s The New New Product Development Game written in 1986.
It is ironic that the Agile community has reasonably ignored another iconic work by Nonaka Toward Middle-Up-Down Management: Accelerating Information Creationthat explicitly discusses the role of (middle) management. In a nutshell management’s role is to look (up) at the business strategy to be implemented and creating an environment for the people they lead (down) can self-organize in to achieve those goals. While Agile is not inconsistent with this, the Agile Manifesto does not mention management at any point and even created its own role (the Scrum Master) to take on much of the responsibility that Lean managers do.
The Agile Manifesto is focused around the technology side and the technology side’s purpose of creating and manifesting value. A focus on customer value is not all a business does, however. Successful companies have clarity of purpose and a commitment to their employees. Both of these must be invested in.
Lean-Agile is taking the mindset of Lean, applying it to the software world while incorporating the lessons of Agile that are useful. Lean-Agile is not constrained to the workflows that have software in them. But then some aspects of Lean-Agile’s guidance must change.
There is no question that Scrum has changed the software world by leading the leading adopted framework in the Agile space. However, the Agile world has changed in the, now, almost 2 decades of its availability. This change has been threefold (at least):
Late adopters are now moving into Agile
Many of these are in large organizations
Much more is known now about process, particularly in how to use Lean principles in software, than was known 20 years ago
Some of Agile has moved from a focus on teams to include the entire organization
The Scope of Current Methods
There are several popular methods: Scrum, XP, Kanban, Kanban Method (LKU Kanban), SAFe, LeSS, and DAD
The scope of these methods vary. Scrum and XP are centered around the team. Kanban directly encompasses the product backlog through deployment, but many Kanban thought leaders consider Kanban to include the entire value stream. The Kanban Method is mostly focused on after it has been decided what to work on. SAFe, LeSS and DAD include the entire value stream but take different approaches to it. While FLEX is not popular (yet) it also includes the entire value stream.
No One-Size Fits-All and What That Means
It is pretty much agreed that no one-size fits-all. But if we believe that, then we must ask the question – where do our methods fit? Those that are based on practices or scope will clearly have limitations on where they apply. Specific situations require specific practices. But there are several principles that apply most everywhere. There are even laws of software development that apply everywhere.
It therefore behooves us to see if our frameworks/methods are suggesting practices that don’t always apply or if they leave out useful principles / laws that do.
As Don Reinertsen pointed out, waterfall is not evil, it just doesn’t apply in the real world. We need to see where things work and where they don’t. The fact that things work differently and have different contexts in which they work is not bad. For example, I have two cars – a Mini-Cooper and a Lexus. They are different. The Mini-Cooper is great around town. It’s small, gets great gas mileage, is fun to drive and easy to park. But it’s not so good on highways (not a smooth ride above 60). My Lexus is way better for going 70 or more. Smooth, quiet, nice. But doesn’t get great gas mileage and is harder to find parking spaces for. One is not better than the other, they are only better than each other in different situations.
FLEX, while definitely not designed as a one-size fits-all, attends to providing pertinent practices for common situations & thinking on how to solve the rare ones. In this way it creates an umbrella for making specific recommendations for where people are.
Why Systems-Thinking Is So Important
Systems thinking is critical because it attends to how different aspects of our systems interrelate with each other. Transformations are fraught with examples of attending to one aspect of an organization only to adversely affect another. See If Russ Ackoff had given a TED Talk for why this is true. An example of not attending to the systems when doing pilots is discussed in this short video - Successful Pilots Can Hurt an Organization. In this example, successful pilots created effective Scrum teams but at the expense of making the rest of the organization. We must be careful we don’t solve the wrong problem.
How One Uses Scrum to Improve
Scrum provides specific practices to follow, including:
Planned sprints of a consistent length
A product owner, Scrum Master and a team
A sprint backlog
A product backlog
Having work finished at the end of a sprint
Retrospections at the end of a sprint
It then lets the team figure out how to do it. Self-organization is the key here. When you can’t achieve these (most notably, cross-functional teams, not being interrupted during a sprint, planning for the sprint). Scrum goes further, however, and suggests that when you can’t achieve these practices that the way to improve your system is to remove these impediments. This provides a set of practices that people without a lot of understanding can follow.
However, there are a few problems with this. If no one-size fits-all then these practices will not always apply. While the intents are good, the practices are often either not generally applicable (the intention of sprints can be achieved in other ways) or the overly expensive to achieve (cross-functional teams is a way of avoiding handoffs, but not the only way when certain capabilities are scarce). There are several others which are currently being written up in our Team-Agility section.
The real danger to this approach, however, is that people new to scrum tend to think these practices are sacrosanct and, given Scrum provides no guidance on how to get past them, tend to become dogmatic. Another danger is that the focus on the team can have Scrum adoptions work more with intra-team issues when the real issues are inter-team or product management issues. See Successful Pilots Can Hurt an Organization.
The Need for Double-Loop Learning
Systems-thinking tells us that we must attend to the system we are in when we make local decisions. This means we must often transcend any method we’re using. Double Loop Learning is a way to challenge if what we are trying to do is, in fact, the right thing to be striving for.
Impediments to Scrum that May Be Reduced by Looking Outside of Scrum
One of the common impediments to Scrum is the lack of trust between business stakeholders and the team. It may be possible to lower the trust required if you can get alignment on what and why the business is investing in. Besides this positive benefit, it avoids the risk of teams evolving into siloes.
Why Including Scrum as an Aspect of Systems-Thinking Is Important
When a team undertakes improving their methods and select Scrum, it is important to understand the bigger goal – realizing value quickly – and the role they play in it. Scrum’s roots is in The New New Product Development Game which was about how to make a single team building a product more effective. By focusing on the team, Scrum may cause a focus on local-optimization. When a single team is involved, local optimization may be global optimization. But in our modern world, it typically isn’t.
In many cases having 2 or more teams working together will result in business value achieved both quicker and with more efficiency that a single team working by itself. Teams working together properly in a systems thinking approach may result in greater results than teams working by themselves.
Why Understanding Key Principles Before Undertaking Scrum or Adding them Quickly Is So Important
Most new teams learning Scrum make the same mistakes. These include:
Opening up too many stories at the beginning of a sprint
Not having enough agreement on how they should work together
Not have good definitions of ready and/or definitions of done
Not understanding effective ways to deal with interruptions
After a few sprints they’ve figured this out. However, basic Lean-principles could avoid them having to figure this out for themselves. In any event, practices such as explicit work-flow, managing Work-In-Process (WIP) and attending to root cause are core Lean practices that all Scrum teams should be using.
Better Ways of Revealing Issues
One of the key intentions of Scrum is to frame the work to reveal issues. Following Scrum’s core practices are key to this. But there are other ways to reveal issues. The Value Steam Impedance (VSI) Metric is one way of quantifying what people know intuitively about the impediments they face.
FLEX includes its own team-level approach – Team-Agility. We are in the process of integrating some articles on it now, but here are two sources for more information on it:
Understanding the challenges present in changing behavior is important. There has been a lot of conversation about simple, complicated, chaos and complex events. While discussed by many, some of these discussion ignore three salient points:
The relationships are often not inherently the way they are but are that way because of limited understanding
Chaos is a result. We should be discussing ‘chaotic events.’
All of this needs to be taken from a systems-thinking point of view.
First, some quick definitions
Simple means there is a well defined relationship between an event and the resulting action from that. Dropping a pen and seeing that it will fall is a simple relationship. Or, if one wants more accuracy, there may be other factors (such as wind velocity) taking it out of the simple domain. Doing this in space may be a more complicated relationship. Hence, relationships may be simple but not in all contexts.
Chaos is a result, not an event. Its definition is “complete disorder and confusion” as in “snow caused chaos in the region.” It can result from behavior so unpredictable as to appear random, owing to great sensitivity to small changes in conditions.”
Chaotic event is an event that is unpredictable even if there is an underlying science. The “straw that broke the camel’s back” and the “butterfly effect” where a butterfly flapping it’s wings in Asia can theoretically cause a typhoon on the west coast of the US. These are often called “non-linear” events since a small change may cause a large change.
Complicated events are when there are several well-defined relationships between cause and effect. If all of these relationships are known then we can predict the outcome of the actions. Launching a rocket is an example of complicated.
Complexity means that the exact relationships between things are neither known and possibly unknowable. Complexity does not mean general predictions can’t be made, but that exact predictions cannot. For example, weather is complex, but there are patterns to weather we can learn.
Different between inherent nature and what we understand.
Many things that appear complex in the past were really just events for which we had no understanding. See Complexity Is Not What it Used to Be for an example of what appeared to be complex, was solved by someone, but couldn’t get it adopted because of the lack of understanding.
Chaos is a result.
While chaotic events, by their very definition, can’t be predicted, they can be controlled. This is the driving force for quick feedback. We can always introduce errors into our system. If we can find them quickly, we can eliminate most of the impact of the error.
Taking a Systems Thinking Point of View.
Systems-thinking provides us with two main tenets:
We must recognize that all of the parts of a system are interrelated and that changing part of the system affects it all. Furthermore, the system is not the sum of the whole but exhibits its own behavior. See What if Russ Ackoff Gave a TED talk.
The system affects the behavior of the people in it in a very significant manner.
What this means is that a system likely exhibits all 4 types of events: simple, complicated, chaotic, and complex. And definitely all four if people are present in it as people’s behavior is complex. See People Are Complex, Software Development Isn't.
What This Means
When a transition to new methods is attempted, the actions being attempted become part of the system. This is why one should consider the effect of following a particular approach will have on your organization. That is, include people's reaction to Scrum, Kanban, Kanban Method, SAFe, FLEX, DAD, LeSS, …The method you are using becomes part of your system. This should be accounted for in the design of your approach. Many approaches take a different attitude about how they will/should affect the system. For example, Scrum suggests that impediments to doing Scrum should be removed. This works in some contexts, but not so well in others. Lean suggests taking a systems thinking point of view so that any adjustments to your workflow must consider the value streams being affected.
If you want to learn more about how we attend to systems-thinking in transformation, look at our FLEX system on our portal.
A lot of people in the Agile community talk about ‘simplest’ as it’s a good thing. I like simple better than complicated if all other things are equal, but all too often simple is simplistic, not a desirable thing. What makes for a ‘simpler’ framework or method? Some people suggest it’s the size of the guide or number of things you must do. I would suggest it’s what’s more understandable to people.
Work on items that will have us realize the greatest amount of Business value across the enterprise
Collaborate with each other in order to maximize the realization of Business value across the enterprise
Ensure that all work will be made visible
Take the necessary steps to sustain or increase predictability
Keep the work throughout the value stream within our capacity
Encourage everyone to strive for continuous improvement
Each of these will lead to other steps – but can function as a start.
Agreeing to work on greatest amount of business value will lead to the use of Minimum Business Increments and even further (what are the items we want to invest in, what are our strategic initiatives for that, how do we get MBIs from them).
Agreeing to collaborate leads to consistent cadences and visions in order to implement business value. It also requires the next agreement to make all work visible.
We of course want to be able to improve our predictability which is partially achieved by keeping work within our capacity.
And continuous improvement has us not only do ‘inspect and adapt’ but incorporate double-loop learning into the mix.
What to Work on
The desired focus is on quick realization of business/customer value predictably, sustainably, and with high quality. If starting with people who can work on this directly, this is likely the place to start. Teach people to use Minimum Business Increments (MBIs). Use collaboration to define features (first phase of Acceptance Test Driven Development).
If starting with technology, then probably best to start with lowering the value stream impedance from as early in the value stream as you can. Still teach the concept of MBIs as technology can work with that. And, of course, use ATDD as well.
If You Want to Learn More
These are two pieces of the FLEX system. You can learn a lot more by going there.
Last night after a very successful but very intense trip to a client I was on an airplane headed home. I had told myself I would just relax but couldn’t. I made the mistake of getting on twitter (something I know I shouldn’t do when I’m tired). I got into some dialogs and said something that was plain old wrong. I deleted it, and restated it, but the restatement was still wrong. For those who weren’t there (and I am sure are now curious) I will repeat the deleted tweet:
The fact that I am the _only_ person who has put forth an approach to Agile at scale and am requesting that people tell me what’s wrong with it so that I can improve it tells more about this industry than anything else I know.
I restated it for clarity:
Let me restate this to make it clearer. Net Obj is the only company with an approach to Agile that works at all scales who is also asking ppl to tell them how it can be improved. We want discussion of what is the best approach so as to make it better.
Both tweets are wrong and I have deleted both now and I apologize for both. My intention for both tweets was to bring forth the idea that we need more discussion about what works and what doesn’t in this industry. I was not trying to make myself be anything special. But the implications regarding others were clear and not appropriate. And that’s what I am apologizing for.
Now explaining why you did something wrong does not diminish the mistake. But it may help shed some light on what may be useful thinking. As many of you know, I have been involved in the forefront of XP, Scrum, Kanban (both Lean based and LKU kanban) and SAFe. I have not gotten involved in LeSS or Nexus because disagree with the assumptions/mindsets on which they are built.
Over the last 19 years of consciously doing Agile (some before it was called that) I have seen a lot of misunderstandings by very bright people. Sometimes it’s just been a learning process, sometimes its been due to them being misdirected by people they trust (I am not saying intentionally). After seeing these patterns over and over again, I sometimes get very frustrated. The frustration is that I sometimes think that some of the people that I believe are contributing to this don’t recognize this. In many cases, I believe their intents are good. I really do. But good intentions with bad results are still bad results.
One of my fundamental beliefs is systems-thinking. That we must look at the whole. We can not take components of a system and change them and expect to change the system. That modifying one part of the system has a system-wide effect – often not anticipated. Russ Ackoff did a great talk that if you haven’t see it I highly recommend you do.
Systems are complex. But we make them much worse if we deal with only one aspect of them. This means that if you introduce a framework or method to a company you are embedding your approach into the system – and it becomes part of the system. How people are affected by this, in my mind, should be part of the approach.
This impact is often ignored. Or at least aspects of it are. It’s why we often see initial success only to lead to stagnation in most every approach I know. Sustaining success typically happens when an experienced consultant or internal transformation leader keeps adjust the transformation. We hear the words “inspect and adapt” but usually they are stated on how to improve the framework or method. Often we need to go beyond the framework or method using double loop learning. People describe this as “shu ha ri” (going from following to owning to transcendence) but typically don’t talk about how to go from shu to ha. My question would be how do we set that up. I actually don’t believe shu ha ri is a good metaphor for this, but that’s another story.
It’s easy to say – “well that’s bad X” but if X causes it to happen on a regular basis, then it’s part of X. In fact, this is exactly what triggered this conversation with the inappropriate tweets. I came across, for the hundredth time, a client who had a former consultant who was doing Scrum “by the book” – meaning “do it this way because that’s what’s in the Scrum guide.” As Ron Jeffries so astutely pointed out, you can’t really do that if you read the whole book because the Scrum guide says to inspect and adapt. But you get the idea. This is bad Scrum. This is dogma. But this is common.
This industry has a lot of misunderstanding. It would be like having a highway system where some of the people say “here we drive on the left” while others say “here we drive on the right” yet both sides don’t talk to each other. And when someone tries to ask “well, when should we drive on the left and when should we drive on the right?” others say – “let’s be in this together and unify things and not talk about differences.” Sorry, this just makes me crazy. Especially when I’m tired.
My intentions in discussing things have always been about helping people better understand ideas that will help them. Sometimes they’ve “learned” things that actually are incorrect and, in my opinion, need to be told, that that won’t work. I don’t always say this well. And some people are nervous about having someone telling the world that something won’t work that they make their livelihood on. Some people just are passionate about their beliefs and feel attacked if you suggest their ideas are incorrect. Some people can only apply ideas in a certain way and are afraid if that manner is claimed to be ineffective.
I am thinking about what can I promise as I am writing this to have more effective and appropriate behavior. Promises are a commitment to change action. I am considering what promise would have me communicate more effectively when I am in a situation of frustration, passion, and weariness. I take my promises seriously. It’s a commitment, it’s something that I say is consistent with my beliefs and values.
I don’t think I can promise I won’t talk about people misapplying Scrum to their clients. Nor can I promise not to talk about something in method or framework that I believe is harmful. At this point I think all I can promise is not to tweet when I am tired. That does make sense – but I’ll think some more on this.
A Call to Action
I believe that we reached a stage in the early 2000s where how to write high quality code was known. Albeit few did it. Unfortunately, in the last 15 years the number of people using these approaches is still relatively small. Some of this, of course, is that new folks come in every year. But it has been encouraging me to see people like Uncle Bob Martin and many others create forums for discussing what is effective coding.
Sometime a few years ago I would suggest that we also now know good practices for effective software development and how to discern what should even be built. In this case, however, there is not agreement. There are several different philosophies out there. Some work better in different places than others.
I don’t believe there is one-size fits-all approach, or even one-size fits-all mindsets. It depends what you are going after. If you are a small development team where you have control over what is to be done, a different mindset may be better for you than if you have a group of 300 developers being driven by 5 different stakeholders.
A challenge I see in this industry, and what I was trying to point to in my misguided tweets, is that we should be discussing these issues openly. What are our mindsets? When do they work? How would we apply them? How do they affect not just people who are experienced but who are new to the game? What truth is out there that is truth everywhere? That is, is there something like gravity in the world of software development?
I have recently announced FLEX (FLow for Enterprise Xformation). This is a writeup of parts of our approach to enterprise transformation, whether it be 50 or 50,000. It is not a framework, but rather a method of thinking to create a step-by-step transformation approach to helping organizations solve the dilemma of needing a solid place to start while knowing there is no one-size-fits all. This has been guided by our successes and failures over the last 19 years. When we have succeeded, fortunately more often than not, we look to see why. When haven’t met our clients’ expectations, we’ve also looked to see why.
It’s easy to ascribe less than successful implementations to a client not adopting what we suggested. But the reality is that as soon as we enter the door we become part of their system. Our approach has to include the way it affects their thinking process. Years ago I created a system I called “the inflection point system” which could be used to model any framework or method. It was very powerful. In the right hands we had some great success. But in the wrong hands we had some failures.
Open discussions about what worked and why and what didn’t and why had us (or I should say me because I was the one wielding this particular approach) change it. Others in my company had taken a more effective route and have a better track record. The point is we learn. We have more to learn. No one has a solution – nor is there one. There is only movement towards better ways. This is how to acknowledge we are in a complex field and the real challenge is always a people challenge (kudos to Jerry Weinberg).
I believe we still have much to learn about how to make organizations more effective. I believe that the bigger problem is not figuring out what to do but in getting people to do it. I don’t believe we can stand on mantras such as “it’s simple just do it.” What is being stated may be simple but getting people to do it is not. Not to mention “simple” is not the goal anyway – understanding and effectiveness is. No system stands on its own. Every approach becomes part of the system that it is trying to affect and therefore is complex.
So my call to action is to join me in trying to figure out how to solve this problem of first, figuring out what’s good and where it applies, and second getting people to adopt it. This is in the form of a general conversation about what we should do in particular situations, and what we shouldn’t do in particular situations. I believe our industry can only solve the issue of how to be more effective by discussing what works and what doesn’t. I am requesting people’s opinions about that and inviting open dialog. I have put forward FLEX as a way to codify what we’re doing so as to allow a discussion of what works. I invite you all to tell me what you like, but more importantly, what you don’t like.
It’s not that we learn by failure. The oft repeated mantra of “failing fast” is misguided. Many of my learnings have been due to quick success when I hadn’t expected it. It’s “learning fast.” We often learn from failures because they challenge our belief systems. So I’m looking for feedback that challenges my beliefs, although getting a “that’s pretty cool” is always nice to hear.
If you’ve reached the end of this blog I thank you for your time and hope you’ve found it valuable.
Read Full Article
Read for later
Articles marked as Favorite are saved for later viewing.
Scroll to Top
Separate tags by commas
To access this feature, please upgrade your account.