“Well, in our country,” said Alice, still panting a little, “you’d generally get to somewhere else – if you run very fast for a long time, as we’ve been doing.”
“A slow sort of country!” said the Queen. “Now, here, you see, it takes all the running you can do, to keep in the same place. If you want to get somewhere else, you must run at least twice as fast as that!”
This episode, called the Red Queen’s race, has been used as a metaphor in, among other subjects, theoretical biology and marketing. In the third millenium, it is a metaphor which concerns us all; no matter which pursuit you choose in life or in business, the world has become a big race.

.
Career in multiple countries

Dr Jan Bosch is professor of software engineering and co-director of the software research center at Chalmers University Technology in Gothenburg, Sweden and an adjunct professor at the University of Groningen (NL). Formerly, he has held executive positions at Intuit Inc and Nokia Research Center. His research activities include compositional software engineering, software ecosystems, software architecture, software product families and software variability management.

When talking with Jan Bosch, Professor of Software Engineering at Chalmers University of Technology, the message is straight-forward and precise. Through a distinguished career in the Netherlands, USA, Finland and Sweden, working both in industry and academia, Jan Bosch has attained an unmatched overview. His observations could be summarised by paraphrasing the singer Leonard Cohen: “I’ve seen the future, brother: it is swiftness.”
“The biggest, biggest trend right now is a shortening of the feedback system. There is a general need for speed,” says Jan Bosch. “It is your readiness to minimize the feedback loop that decides whether you are going to succeed or fail in the marketplace.”
To Jan Bosch, innovation resulting from “struck by lightning moments” belongs to the past. The innovative companies of the future do not need developed, integrated ideas. Instead, they just need to analyse the customer’s feedback, come up with suggestions on how the company can move forward in the market and then start experimenting in a structured manner. This is also useful for embedded systems, where you can apply the same feedback loop to improve, for example, fuel efficiency in a car, throughput in a telecom system or throughput in a high-performance computing system. Step one: implement. Step two: measure. Step three: replace, drop or improve. Next cycle, please!
The hard currency in Capitalism 3.0 – where only companies focussed on customer needs will succeed – is of course user information from millions of users. If you have a feedback system where you can dynamically test customer behaviour, you have the strongest possible opportunity to move faster than the rest. You don’t need to dig deep, explain or analyse – just use an A/B testing or some other method where comparing is simple, and then start crunching numbers. Google has been ridiculed for testing “500 shades of blue” to find which one generates the most clicks, but apparently they were the ones to laugh all the way to the bank as rumour says that they managed to generate millions of dollars in additional revenue from this …
It seems that these insights promptly need to be communicated to the Scandinavian industry. The need for speed will affect all business areas – not only the traditional software companies. The ones that don’t shift gear to remain where the value is generated, will be left in the dust.
“If we don’t get it right, others will use our platform for their services,” Bosch says.

.
How can Lean & Agile methods help Scandinavian industries to remain competitive?

We have to remember that Lean and Agile methods are means to an end and not goals in themselves. Companies improve their competitiveness by more rapidly responding to requests from customers and by testing their own innovations with customers. The shorter the feedback cycle, the quicker companies can respond to customers and the faster companies learn what innovations generate interest among customers.

.
Which other organizational tools are useful to shorten the feedback loops?

Traditionally, organizations have relied a lot on processes to define the interaction between functions and individuals in their organization as well as with others in their value network. We now see that companies are moving toward small, multi-disciplinary, crossfunctional teams that own the entire process from identifying a customer need to delivering the solution to customers. One of the important techniques that companies use is to put the solution in the hands of customers while it is still under development. The feedback from customers is then fed back into the R&D process and steers the prioritization and implementation of features. In general, the goal is to minimize the amount of R&D investment between customer proof points.
.

Are there any new tools in the making which seem promising?

One of the important trends is that 
in the near future all products will be connected to the internet, ranging from your car to the appliances in your kitchen and the consumer electronics in your living room. Ericsson, for instance, often talks of 50 billion connected devices. That offers three important advantages. First, the software in these products, which is a constantly increasing part of the R&D cost, can be updated even after the product has been sold. Second, connectivity allows the product company to collect all kinds of data from the product as it is in use, including usage metrics, performance, safety and other metrics. Finally, the ability to measure and to push new software to products allows for A/B testing even in embedded systems. In a world where products are increasingly turning to services, these tools are becoming mandatory and necessary.

.
How do we coordinate and align the different levels – individual, team and organization – in this process?

In many domains the age of the top-down steered hierarchical organization is rapidly coming to an end and the role of management is changing quite fundamentally. Successful organizations are starting to organize themselves as ecosystems of activities performed by self-selected and self-directed teams. These teams even manage themselves based on quantitative output metrics. The role of management is now to define the right metrics that cause optimal alignment between team performance and business performance. Second, in the areas where metrics cannot be formulated well, the role of management is to build the right culture in the organization.
For the individual, there are two important implications. First, the ability to choose the team that you want to be part of is exciting and very liberating. Secondly, the fact that you have to have a proactive self-starter attitude rather than waiting for someone to tell you what to do is very important.

An every day situation:
“Where the heck are those test data for this module?”Sam asked.
Silence in the whole office, nobody seems to have them.
“Did we request them from the client?” he asked this time.
More silence.
“And by the way, did we order SubSoft to assist us this week? I haven’t seen them this morning. And where is the test version from HardCore on their damned new gadget?”
A sigh from the corner – but no answer.
All of a sudden question upon question comes up, and the whole developing process comes to a grinding halt. Waste of time all over the place.

This is an every day situation which we can all relate to – nothing out of the ordinary. Sometimes you may also hear conversations like this one:

“I think we should take into account that two sprints from now we are going to add x functionality. Let’s already now make sure we can easily integrate it into the architecture.”

“No – you should not think of that now. We are not supposed to do that in Agile development. Let us cross that bridge when we get there.”

Planning Ahead

It is definitely true that software can be over-engineered and be configurable to handle all kinds of more or less probable enhancements in a distant future. But it is equally certain that it has never been the aim of Agile development to make teams behave more stupidly than they actually are by deliberately ignoring knowledge that is available to them and to make precautions in due time. Teams with this approach are faithful to the letter of Agile methods but not to their intent. They can be compared to a group of scouts going on a hike who, when they start, know they will have to cross a river some time later on the trip. However, when one guy wants to bring some rope the others tell him to leave it at home, because “when we get there, we will find a way to cross the river”.

Anti-planning Syndrome

More of something good is not always better. That holds true for most principles in software engineering. “The simplest thing that can possibly work” does not mean “Ignore everything you know” but rather “Do the simplest thing that may possibly work” (in the context of your current knowledge).

Overdoing this principle can lead to the “Anti-planning Syndrome” which can sometimes be seen in Agile development. We have recognized that Big DETAILED design upfront BDDUF is not good, because we can’t oversee the complex nature of the problem anyway. But that does not mean we should not spend enough time to understand the core of the problem and design at least the outline of a solution we are going to apply, before diving in and starting to write code.

Doing it Right

So how much planning is optimal? One way to look at it is this: if your team are routinely modifying what has been planned in detail, then you are planning too much, too early. If, on the other hand, they routinely have to redo work or get stuck halfway through a task because they miss information, decisions or deliveries from others, you are planning – or rather preparing – too little.

There has been a lot of emphasis on “Done”-criteria and making work really “done-done” in the Agile team process. The other side of the process, “Only working on stuff that is really ready”, has not gained the same attention, even though the consequences of starting work which is not ready is at least as costly as not delivering work which is not really done.

Putting backlog grooming to work

To avoid the waste of starting work that cannot be completed, you may have to implement a process that will ensure that only ready work is undertaken by the development team. On a number of occasions we have implemented the Make Ready Process in Agile teams, to help them bring the stuff they need to cross the river.

The Make Ready Process consists of a process similar to the development process in Scrum and other Agile processes. Make Ready starts with loosely defined user stories or other forms of functional requirements and ends with user stories ready to work on. The process is aimed at giving maximum speed in development, so when a user story is actually ready to be started, it is most likely to be completed in the current sprint.

Guidelines show the way

Bent Jensen is Director and Consultant at the Danish agile consulting firm BestBrains. BestBrains primarily helps software companies implement faster and more effective ways to create software with a Lean and Agile foundation.

The criteria for when a user story or a task is ready to work on, will differ from project to project. However some guidelines can be found in looking along the streams which feed the flow of work and make the work packages “sound”. By a sound work package we mean a task that is in good shape regarding:

Dependencies
Is there any development work that needs to be completed before this should be done? Do we need to coordinate with other teams?
Skills
Do we have the skills on the team to complete the task?
Space
Can we actually get to make the change. What is the state of the code we are looking at?
U.X designs
Does the User Story have an associated U.I design and workflow?
Stakeholders
Is there anyone that needs to be informed and involved in this user story that maybe later can disapprove?
Work ahead
Is there anything coming later that this development work needs to take into account?
Following work
Are the receivers of this work in place and ready to receive it?

Stuff ready to work on

Sven Bertelsen has worked for 40 years as consulting engineer and project manager and has been partner in NIRAS for 25 years. Today he is an external lecturer at the Danish Technical University as well as working as consultant.

In practice this means there is a perspective on the projects that have a range of 4–8 weeks. It is not focussed on detailed planning, but on making sure there is stuff ready to work on when the time comes. And here we are not only looking at previous work but at all the prerequisites for the task – internal and external. By “ready” we mean really ready with no exception or maybe. A smaller group will usually be responsible for the Make Ready process. Someone from the customer side will ensure the needs are well understood. A technical lead or architect will together with developers make sure we can actually do the work in the code. Developers may spend time making a spike to outline a solution. UX designers may work on high-level designs and people from other teams may participate to ensure that work between teams is coordinated.

The Core of Coordination

The group should have joint responsibility and their performance should be monitored. A reliable flow of work is the key to higher productivity, shorter development time and lower costs. The process will usually we supported by a weekly meeting and progress will be tracked on a task board especially designed to visualize the make ready process. Often this process has its home in a development team, but on multiteam projects, the Make Ready Process and associated meetings belong to the overall project and are the core of coordinating several Agile development teams. A general question at all sprint and scrum sessions should be “Is this task ready”, and – if not – “By whom and when will it be so?” More from this inspiring initiative will be coming up in our consultancies and in future editions of Lean Magazine.

Download PDF-version of article: Make Ready PDF (54)

Don Reinertsen at Lean Tribe´s seminar in Lund

Anders Sixtensson: In most of the examples you give in articles the cost of a month’s delay is often surprisingly big (at least for someone who has never done the calculation). Is it often a surprise for those that really make the effort?
Don Reinertsen: There are usually three surprises for newcomers to calculating cost of delay (COD). First, they are surprised at how large the number is. Second, they are surprised at how little time it takes to do the calculation. Third, they are surprised at how much consensus they can reach on the value. All three of these surprises occur because people’s intuitive sense of cost of delay is way off. The intuition of members of the same team typically differs by 50 to 1, so the real estimate surprises most team members. In general we have good intuition about things we have seen more than once. People who have never calculated COD have no basis for any intuition on the subject.

.
In pure software development, you do not usually have any high production costs. On the other hand you have maintenance and bug fixing. In your life-cycle profit model, where do these running and variable costs fit in?
For manufactured products the majority of the recurring cost is the cost of manufacturing which is proportional to the quantity of product sold. Software also has recurring costs that are proportional to the quantity of product sold. For example support costs are typically proportional to sales volume. On the other hand, software also has costs that are relatively independent of the quantity of software sold, such as bug fixes. Both of these costs influence the P&L of a software company, and they should be reflected in any economic model that is used in a software company. It is a solid general principle to have life-cycle profit models keep score the same way management keeps score in their P&L.

.
Technical debt is a term often referred to. Usually this means that previously done work has led to bad architecture, high failure rate, high complexity, etc, which make future development and maintenance even more expensive. In a life-cycle profit model, it could be worthwhile to amortize your debt by refactoring or cleaning up the code etc. Where do these kinds of activities fit into your economy-based decision model?
I do not find that technical debt is sufficiently similar to financial debt to reason by analogy on this matter. Financial debt almost always has to be repaid and the total cost of repayment rises as a function of time. In contrast, there are many cases where technical debt will never have to be repaid, and other cases where it can be repaid at a lower cost in the future than the present. When a developer makes the choice to defer work they are generally doing so to achieve another economic benefit such as earlier introduction. Deferring work may have an economic cost. If this added cost is less than the financial benefit of deferring work, for example the value of early introduction, then creating technical debt is a good economic choice. To correctly model such a situation one should include the one-time and recurring costs caused by the technical debt. In general, although I recognize this is not the practice in the software industry, I prefer to refer to this problem as “deferred work” rather than “technical debt”.

.
Our customer runs a portfolio of projects in parallel and tries to manage this pipeline of ongoing projects in such a way that the pipeline as a whole delivers as much business value as possible over time. If we have a bottleneck and need to sequence a number of projects, first to go is for example Project A, then Project C and finally Project B. This sequencing decision should be based on some kind of accumulated cost-of-delay for all the projects together. Have you used or seen Cost-of-delay as an input to portfolio management? Would it be possible?
To maximize the economic benefit of a portfolio of projects the sequencing of projects should consider both the cost of delay of each project and the amount of time that the project will block scarce development resources. This approach is known as a weighted-shortest-jobfirst (WSTF) queueing discipline and it is discussed in the book, “The Principles of Product Development Flow.” The sequence of projects that will produce the best total return will prioritize projects with the highest cost of delay per unit of scarce resource consumed. This illustrates a key point: in product development we can reduce the cost of delay without shortening average cycle time. We can do this by ensuring that jobs that are delayed the most are jobs with the lowest cost of delay.

.
I have read somewhere that one way to get a better understanding of cost-of-delay could be to imagine the following: “How much would I be willing to pay for a ‘magic consultant’ to solve my existing problem NOW?” So, that price divided by the time difference from NOW until I have solved it myself is really the cost of delay. Could you argue like that?
I would not use this approach. A cost-of-delay calculation establishes the value of time on the critical path of the project. Whenever we pay less than this amount for time we are improving the economics of a project. Let’s say cycle time is worth $25,000 a week. If we can save a week of cycle time by spending $500 to expedite a shipment this is attractive. If we can save the same week of cycle time by hiring a consultant for $10,000 it is also attractive. However, neither of these amounts are the cost of delay, which is $25,000. In general the maximum price you would be willing to pay to maintain a project schedule will be the project’s cost of delay, however using your intuitive sense of a maximum price is a very poor way to calculate cost of delay. This price will be determined by intuition which, as I mentioned earlier, typically can vary be a factor of 50:1. It is much better to calculate a cost of delay

Now, what is “Rapid Software Testing” – and how does it differ from “traditional testing”?

Well, until we establish what “traditional testing” is, it’s hard to identify the differences. But let me describe Rapid Testing, and people can decide on the differences between that and “traditional testing” as they think of it.

James Bach and I describe the Rapid Software Testing approach as a skill set and a mindset focused on doing excellent software testing in a way that is very fast and inexpensive, yet entirely credible and accountable, so that managers can make informed decisions about the product, the project, and related risk.

Michael Bolton is the co-author (with senior author James Bach) of Rapid Software Testing, a course that presents a methodolgy and mindset for testing software expertly in uncertain conditions and under extreme time pressure.

Testing’s job is to help to defend the value of the product by helping people to become aware of problems and risks. When there’s value on the line, unskilled slapdash testing isn’t going to cut it. Ponderous testing, where everything is buried under mounds of paperwork and bureaucracy, is too expensive and takes too long unless you have lots of time and lots of money–and you don’t mind wasting them. “Complete” or “exhaustive” testing has several problems: it would take too long, it would be so expensive that management wouldn’t fund it, and nobody knows how to do it because it’s an infinite task and therefore impossible.

So, in Rapid Testing, we focus on doing things quickly, with minimal fuss and busywork, and with all the skill we can bring to the table. We also focus on the fact that excellent testing is far more than confirmation and verification and validation. Instead, great testing is focused on loops of exploration, discovery, investigation, and learning – and reporting quickly and concisely and cogently on what we’ve learned.

Now, as soon as we’ve said something like that, it’s common for people to say, “So, you don’t believe in documentation.” Not true; we do believe in documentation. But we believe in communication more. We don’t believe in wasteful documentation, and we don’t believe in documentation in circumstances where conversation is clearly faster and more effective. Some people say “Exploratory testing? So that’s manual testing; you don’t believe in test automation.” Not true; we do believe in automation as a tool. We favour interacting with the machine as the users of the product do, but we also love using automation for things that automation can help us with.

What is the context-driven testing school?

For a long time, discussions in the testing world seemed to be oriented towards identifying The Right Way to do testing. Various writers and speakers touted their approaches as being appropriate or correct, as being best practices. Cem Kaner, at least, had noticed fairly early on that “best practices” coming from academia didn’t work so well when you tried to apply them in industry; that “best practices published in books by people who worked in the telecom business didn’t work so well for people in Silicon Valley; that “best practices” for mass-market commercial software went against the cultural grain in banks and in the medical business. The trouble, I think, was that people were coming to conclusions about testing without really considering the premises. Based on those conclusions, they were declaring that testing should be thus and so. It’s not that the conclusions were wrong; they may have been right for their context. The bigger problem is that the premises aren’t universal.

As time went by, Cem recognized more and more people were having similar experiences and making similar observations to his. Controversy about testing among reasonable people suggested that you can’t label something a “best practice” and expect it to be relevant to all domains in which testing happens. Standards relevant to the defense industry were ruinously expensive and unhelpful for people developing computer games. Unless you want to put serious limits on your career opportunities, you can’t declare, as some people have suggested, that you should refuse to test until you got a clear, complete, up-to-date, and unambiguous specification. It wasn’t helpful for the testing mice to declare that someone should put a bell on the business and development cats.

James Bach on Rapid Testing. "The closest thing in the business to a martial art of software testing."

The people who recognized these issues went on to declare a set of principles based on the idea that if you wanted to do testing well, you’d have to consider the context first, before anything else. Then you could make pragmatic choices about what was right for your situation. You can read that declaration and some clarifying remarks at www.context-driven-testing. com. Cem, James Bach, and Bret Pettichord wrote Lessons Learned in Software Testing; the sub-title of that book is “A Context-Driven Approach”.

Not too long after that, Bret Pettichord published a paper identifying what he and others called the four schools of software testing. These included the factory or routine school (following templated processes and documents will guide us best), the mathematical school (intensive and rigourous functional analysis and graph theory will guide us best), and the quality school (requiring other people to adhere to rigid processes and driving them to high standards is our real calling). The context-driven school suggested that ideas from the other schools might be relevant, but no idea was universally best and that people were the most important part of any project’s context.

Naturally, this was controversial. It put the whole idea of best practices in question, and it meant that certain cherished ideas about testing would have to be questioned. Testing itself would have to be tested. This represented a threat to received wisdom and offended some people’s idealized world-views. After all, experts are typically heavily invested in their own expertise. Other people weren’t quite so threatened, and pointed out that, sure, they considered context. What many of them seemed to miss was (is) that to be context-driven, you’d have to consider the context first.

In addition, people didn’t like being labeled or pigeon-holed. I don’t think that we the intention; the intention was to to identify schools of thought, or paradigms. Perhaps the notion of “schools” was unfortunately named. People seem to have a lot of bugbears about the word “school”. It might have been more politically palatable to identify them as four cultures of testing. We’ll never know.

Thinking back, how did you get involved in “Rapid Software Testing”?

I was lucky enough to learn important things about the craft of testing at Quarterdeck in the early 1990s. At that time, Quarterdeck was the publisher of memory management software that regularly topped PC Magazine’s best-seller list; that is, with the exception of DOS, it was the bestselling piece of software in the world. In the context of commercial software that had to be compatible with all of the other software on the market, we had no choice but to test rapidly. That the style the company had, and that I took on: exploratory, highly collaborative, concisely reported, lots of face-to-face – and fast. Like all software, our products shipped with bugs, but we found and eradicated the important ones, and the decision to ship was well-informed. When the product reached the field, we were rarely surprised by bugs that we hadn’t known about.

James Bach introduced me to his Rapid Software Testing course in 2003. As he and I both realized, I had been practicing rapid testing, or something like it, for a good long time before that. I had been missing something, though. I hadn’t paid a great deal of attention to the structures of rapid testing, although I had been using many of them intuitively. As a consequence, it was harder than necessary to describe my work in contexts outside of commercial software. In large financial institutions, for example, I could find more important bugs, more quickly, than the in-house or contracted testers who were given script to follow. I could learn what was important more quickly because I used fast cycles of reading about the product, interacting directly with it, exploring its behaviours, applying curiosity, and asking questions of the people around me. For me, the focus was finding out how the product worked – and how it didn’t work, rather than simply checking to see whether test cases passed or failed. I could create and edit and narrate stories about my work, showing how I had made responsible choices in the face of uncertainty. Yet those stories were often more improvisational than I might have liked. James and Rapid Testing offered a means of identifying the structures of testing, and of describing testing work in a more structured way. Moreover, becoming aware of the structures offered a means of developing testing skill even further – not only my own skills, but the skills of our testing students; not only testing skills, but skills needed to develop and teach testing skills.

I started teaching the Rapid Testing class in 2004, and I’ve been a coauthor and co-developer of the material since 2006. James and I have been refining the class continuously. That’s for three reasons at least: one, because we’re always learning about new things in the world that we can relate to testing; two, because based on that, we’re constantly learning new ways to observe and to model and to describe testing; and three, because testing itself is constantly changing as the world and technology change.

Would you say that anyone can do “Rapid Software Testing”?

Anyone who is capable of learning and practicing the skills can do Rapid Testing. That requires some personal commitment and some work, though. First, there’s a lot of information- gathering and learning to do. It’s important to be an information sponge, inside your working life and outside of it. It’s a great exercise to relate the things that you see, hear, and do back to testing. It’s also very important to observe and reflect on what’s going on, and to be self-critical.

Rapid testing also takes practice in certain patterns of thought. It’s our job to question things, to put “unless …” at the end of sentences that we hear or read, to see the complexity behind apparent simplicity, to consider alternative interpretations of what we hear or see. Rapid testers are professionally uncertain about what we know when everyone else is sure.

Why do you think there is the general notion that “anyone” can do software testing?

Anyone can do unskilled and valueless testing. The certification peddlers don’t help the image of the craft when they provide “certification” for passing a 40-question multiple choice test that involves doing no testing work that anyone observes. Pretty much anyone can do pretty much any kind of work if all that the work requires is following a set of steps laid out by someone else. Anyone can do software testing if, as the person commissioning it, you’re indifferent about the quality of the work.

I think the reason that people (managers, mostly, so it seems) think that anyone can do software testing is that those people simply haven’t been exposed to excellent testing and they haven’t thought very much about what good testing would be. So there’s this feedback loop: poor testing fosters poor expectations about testing. That’s why outsourcing to the lowest bidder seems to make sense; there’s no point in paying big money for valueless work. I’d argue that there’s no point in paying any money for valueless work. Instead, focus on training and requiring people to do valuable work, and then get the benefit from that.

Is there a downside to “Rapid Software Testing”?

If you follow the principles, Rapid Testing makes it hard to do fake testing. That can be a problem for the people who are afraid of learning about scary things in the project. It can be frustrating, for a while, for rapid testers to work in non-rapid environments, unless they pick up a kind of Zen about the situation. Even if you’re doing excellent work, people have a big investment in their security blankets, and won’t drop them lightly. In a highly non-rapid context, it takes time and patience to help people recognize valuable testing.

Michael Bolton Recommends!

Perfect Software: And Other Illusions About Testing

Gerald Weinberg Dorset House (2008) ISBN-10: 0932633692

”This is a book that I encourage testers not only to read, but also to give to their managers to expand their concept of what testing can do for them.”

”Agile testing is contextdriving, not contextdriven”

.

Lessons Learned in Software Testing

Kaner, Bach & Pettichord Wiley (2001) ISBN-10: 0471081124

”A great practical guide for testers, and suggests lots of ways to do testing well.”

.

.

.

In your view which are the most desired characteristics and behaviors for good Lean & Agile managers?

Managers in any context need to enjoy working with people, or be willing to learn to work with people. Many managers have faulty ideas about motivation. Many of these ideas are based on the assumption that people are lazy and won’t work hard unless they are enticed or threatened. Managers need to understand what really motivates people and how to shape their organizations to harness intrinsic motivation.

On one hand, they need to be wellversed in team dynamics, and how to structure the organization to support team-based work. On the other hand, they also need to be able to understand and work with systems. That’s a skill that’s largely neglected in business schools, management training, and the popular management literature.When managers don’t have these skills, they rely on telling, selling, and yelling.

What are the most common mistakes made by management in your view when implementing Lean & Agile?

Thinking that fixing the development process will fix organizational problems. No method can solve problems unless managers also change.

There are different types of managers in a typical development organization. Could you very simply describe the major changes for these roles when you go from traditional management to management in a Lean & Agile valuebased organization?

We have Project Managers, Product managers, Line Managers and Top level Management.There is no simple answer. The answer depends on the needs of the people and the work. What works for a company of 100 people with two software products won’t work for a company with 10,000 employees, companies with many products, or companies whose product involves hardware and software.

This is an area where we need to look outside our profession and find guidance from the research and practices of organizational design and organization development.

My colleagues and I notice a lot of confusion when we meet managers. They see a new behavior in their development teams when these have started to work according to Lean & Agile principles. Although the development teams are usually happy with the change, the managers often start to ask themselves questions. “What should I do now? How can I support this? How do I avoid destroying the good things?” What is your message to these confused managers?

Esther Derby is a consultant, speaker and author who lives in Minneapolis, MN. She helps managers manage better and works with companies who want to do better at delivering valuable software to their customers. She is co-author of two books – Agile Retrospectives: Making Good Teams Great and Behind Closed Doors: Secrets of Great Management. She is a founder of the AYE Conference and currently serves on the Board of Directors of the Agile Alliance. Read some of her many articles at www.estherderby.com

Don’t tamper if things are working. Ask what is getting in the way, and go fix it. Ask what the team needs, and obtain it for them. Ask what you can do to help.If the team says “nothing”, don’t inflict help.

The truth is, when teams are working well, managers don’t need to intervene. The hard work is in establishing a real team and ensuring enabling conditions are in place. When managers of self-sufficient teams feel like they aren’t doing much, it’s a sign they’ve succeeded. But managers shouldn’t abandon the team. Teams need support and a connection to the organization.

Managers still have an important job to do, working at the system level. Collect metrics that will give a window into the system. Start by tracking the ratio of fixing work to featurework. Then, find out what is driving the fixing work, and start working to improve those issues.

Are there individual managers that will not fit into this ”new” management?

People who cannot manage themselves should not manage others. People who can only work through telling, selling, and yelling won’t be successful in companies that embrace Lean & Agile philosophies.

Some companies find they don’t need as many managers. Some people who are in management roles find they are happy to go back to technical work. But, to me the new roles for managers are exciting and full of promise-developing people, seeing and steering the system, creating environments where people can build products and services that delight customers, satisfy stakeholders, and empower employees.

Can everybody change their behavior or do we need to move some people? To where?

Not everyone is capable, and not every one will want to. Some of those people will leave of their own accord. If there is a place in the organization where people who can’t or don’t want to change can still be of service within the organization, support them to find it, and then let them be.

We can never be 100 % successful when we expect everyone to change. Don’t spend your precious energy trying to change people who don’t want to. Work with the people who want to change, and most often, when a critical mass has moved to a new way of working, most will come along.

If there are some people who are acting in a way that is destructive to people or the organization, help them find the door. (This advice applies whether you are using Lean, Agile or any other method known to man.)

We usually say that ”Measurements drive behavior”. What kind of measurements or KPIs do you see drive the ”right” management behavior in a Lean & Agile organization?

When managers are measured on meeting trickle down objectives, delivering fixed functionality by a fixed date, meeting fixed budgets, we will see the same behavior we’ve seen for decades. This is the story of local optimization that comes from Management by Objectives (MBO). MBO (and similar schemes) pit managers against each other, vying for scarce resources, and meeting their own goals at the expense of the organizational goals. To quote Deming,“If you give a manager a target, he will meet it, even if he has to destroy the organization to do so.” If you want the patterns to change, you need to change the structures that are holding the old patterns in place.

“If you give a manager a target, he will meet it, even if he has to destroy the organization to do so.”
W. Edwards Deming was an american statiscian who, among many other things defined fourteen key principles for transforming business effectiveness.

When managers are evaluated on improving the organization, that’s where they will focus attention.Rather than set improvement targets (which almost always lead to dysfunction) they should look for year over year improvements, and evaluate people on what they can control.

When making a Lean & Agile transition within an organization you start a journey that changes your employees’ ways of thinking that makes it impossible to turn back to “the old way of working”. How do you make sure management really understands the impact on the individuals in the organization and what this journey entails?

I’m not sure people can understand exactly what such a journey entails, unless they’ve been on a similar journey. It’s one of those things that must be experienced. You have to be open to learning along the way. It’s hard to imagine how enlivening, satisfying – even fun – work can be when you’ve been working in a soul-sucking organization. Sadly, many people don’t have first hand experience of anything else. They don’t know what it’s like to work where people are empowered to do good work, are treated like intelligent adults, and create products and services that delight their customers.

That said, it helps to have an accurate model of how people experience and respond to change. As much as we’d like to see immediate improvement, when organizations take on a big change, performance will be rocky for a while. When managers panic and pull back from the change, or try another option, they shock the system again. People need some time to learn and integrate any new method or process. They need to get their feet back under them before the next change.

It is essential to change the structures that hold the old patterns in place. For example, if your organization has used individual goals, make part of each person’s goal dependent on team success. Make it a big enough portion that it matters. This works on two levels. First, it signals that the change is real, not the sameold same-old with a new name. Second, it makes it more likely that the desired new pattern of behavior will emerge and stick.

Six tips from Esther Derby on how to get commitment from management in making the transition to Lean & Agile

1. Make sure managers know they still have a part to play, and involve them in shaping what that part will be.
2. Make sure you carry forward the good parts of the existing system.
3. Consider the structures that will help the new patterns form.
4. Adjust the structures that will hold the old patterns in place.
5. Provide training, coaching, and support to help people in management roles learn a new way to work.
6. Model the behavior you want to see from the top of the organization.
7. Celebrate successes, acknowledge and learn from mistakes.
8. Enjoy the journey.

For Åke Sundelin quality issues have always been absolutely central. It began in his student days, when he decided to study engineering at Linköping University, initially with a focus on manufacturing. While his fellow students chose to be educated in saving the environment or making money, his focus was on quality. Åke Sundelin’s own description of quality is, in addition to responding to customers’ expectations, “to create a design that is robust enough to continue working, despite any problems and errors that may arise.”

“Whatever technical system you’re using, you cannot eliminate all errors. The important thing is not to let the errors take over so that they affect the entire architecture,” he says at the beginning of our conversation. It soon becomes clear that he is already touching on one of the key issues in what we are really here to talk about: Lean & Agile projects, size XXL.

Large and complex projects

Methods based on Lean & Agile principles in some form or other have been used within the Ericsson Group for just under a decade. Ulf Hansson, Ph.D. in Communication Theory at Chalmers University of Technology, says the company’s “Lean & Agile story” provides a number of lessons and insights that are becoming increasingly clear – especially when we talk about scale. Here we are referring to huge systems with millions of lines of custom code that have to work reliably for 5 to 10 years and sometimes even longer than that.

Åke Sundelin works at Group Function Technology & Portfolio Management, (~ CTO Office). He is the driver for Product Development Strategy work within Ericsson as well as a change agent and facilitator/teacher for Ericsson’s internal SW leadership training

These development projects are not only large but also multifaceted. Today the group works with hundreds of customers, typically telecom companies with widely differing needs and requirements. These include everything from experienced operators with large technology departments to “greenfielders” in the form of new players with no heavy engineering staff and with completely different expectations of the systems.

“We must have a system for product development that can respond to both types of customer,” says Ulf Hansson. Åke Sundelin also underlines the technical diversity between assignments – everything from infrastructure to applications. It is a broad playing field, where different rules apply in different zones. Some of these rules are formulated not by the customer or supplier, but by international standards organizations.

“It is a huge challenge to manage such breadth. An implementation of Lean & Agile methods that works at one end of the spectrum does not necessarily work at the other,” says Åke Sundelin.

Developing a Lean & Agile structure

Lean & Agile is widely used at Ericsson to increase competitiveness. Ulf Hansson recalls a comment from a happy developer: “Nowadays, we use all our brains.”

Dr. Ulf Hansson, Business Unit Networks, is the Deputy Head of R & D Operations and overall driver for deployment of Lean & Agile ways of working within Business Unit Networks.

But how do you create a sustainable Lean & Agile philosophy in a company of Ericsson’s size? First of all you have to understand the size difference that exists between their own projects and those undertaken by other companies in the Lean & Agile community. When Jeff Sutherland writes about “Scrum for the Big Ones” in Lean Magazine (# 1, June 2007), these are medium-sized projects by Ericsson’s standards.

“Agile methods were born in a small-scale context,” says Ulf Hansson. “It is a simplification to think that you can take a carbon copy of The Agile Manifesto and apply it to a large organization such as ours.”

The starting point of the Lean & Agile-based methodology at Ericsson is – as you would expect – out in the field, among the developers. It starts with small teams with shared responsibility for the backlog, clear “ready” criteria, short feedback loops, continuous system growth, and so on. Nothing unexpected, in other words, and so far, so good.

Upscaling is the challenge

The challenge is to upscale to a large and complex task without increasing the actual volume of the project; rather, finding the right methods to divide the task into smaller parts that together make up the whole. Of course this opens up a conflict between large scale and basic Lean & Agile principles. The challenge for method developers is to reconcile bottom-up and top-down perspectives.

There are two approaches. In the traditional model the task is divided into subsystems or components that are eventually pieced together into a functioning system. Experience shows that this integration step takes a long time and can cause more difficulties than the entire initial work on the components. Instead the aim is to slice the task into parts that are each testable on their own at system level. These parts are developed in parallel by crossfunctional teams and are integrated continuously during the development process. This avoids a long integration phase at the end. Furthermore, testability of components at the system level gives the teams the opportunity to take full responsibility for ensuring that their solution really works. No one outside the team “fixes” the quality retrospectively

Good architecture is everything

Good architecture and continuous work on the architecture is central to managing and minimizing the dependencies which in practice always exist between the teams’ tasks. The teams must understand and take responsibility for how they affect the whole. A simple and well documented system architecture is critical for success; it is based on modularity, it is easy to add and subtract features, and errors “do not rattle through and affect the whole system.”

“It’s easy for developers to embrace Agile practices, but if we do not create the right conditions for them, their chances of success will be very limited,” says Åke Sundelin. “The key enabler we can create for them is to work seriously with architecture and to reduce dependencies.”

“The consequence of inadequate system care leads to the teams unwittingly ‘colliding’ and getting in each other’s way, which you simply cannot hide when you’re using Agile methods,” adds Ulf Hansson.

At Ericsson they use the traditional tool of dependency mapping. The more you can understand dependencies, the more control you have over your system and can minimize the risk that teams collide during development.

“The person who successfully analyses dependencies gets no negative surprises. It creates space for solving problems, and attacks them proactively,” says Åke Sundelin.

Part of a community

These two colleagues both think it is important that Ericsson has a generous exchange of knowledge and experience with the rest of the Lean & Agile community. They see it as healthy to allow themselves to be influenced and inspired by other companies. They give as an example the Swedish vehicle manufacturer Scania, which is recognized as an excellent Lean enterprise and whose knowledge and experience of modularisation is valuable, even for Ericsson’s software developers.

“We must be part of the mutual learning process – and then smart enough to apply the lessons to our own development work,” says Ulf Hansson. As one of the biggest players in the industry Ericsson has unique knowledge and experience to offer.

“The large-scale application of Lean & Agile places special demands on our understanding; it’s really, really hard!” says Åke Sundelin.

“The transformation to large-scale Lean & Agile is difficult and disruptive, but it is something that is far too good to be dismissed simply because of the obstacles we often encounter. If we do not share our experiences, chances are that the concepts are watered down to ‘water-scrum-fall’, confidence dissipates, and in a few years people will turn up with a new set of buzz words,” says Ulf Hansson.