iLeadAgile

Individuals and interactions over processes and tools

The importance of the Agile mindset was striking in the site visits of The Learning Consortium. When people in the organization had the right mindset, it hardly mattered what tools, processes and practices they were using, the Agile mindset made things come out right. Conversely, if they didn’t have an Agile mindset, it didn’t matter if they were implementing every tool and process and practice exactly according to the book, no benefits flowed. Agile is mindset. Where does your company sit on the tools vs. people balance?

Searching on this topic you’re going to find lots of hits about tools and very few hits about individuals and interactions. I even found an article with 2 lines about people and 4 paragraphs discussing all the various tools they’re using. That’s not really surprising as many companies have created products to address the tools space of Agile but very few companies are focused on the people side of Agile. Fortunately there are some companies that are providing a ray of hope. Happy Melly and Management 3.0 are some examples of companies that truly understand that the focus needs to be on the people more than on the tools. Management 3.0 workshops are a great way for managers to start grasping what the people side of Agile is all about.

Working software over comprehensive documentation

A company with one of the lowest defect rates in the world, has shown through extensive data on many projects the benefits of agile practices. Specifically, they were able to systematically double the speed of production and reduce defects by 40 percent by taking the following actions:

·      Define acceptance tests when defining the feature.

·      Implement features serially and in priority order.

·      Run acceptance tests on each feature as soon as they are implemented.

·      Fix bugs that are identified as highest priority as soon as possible.

 Try these practices with some of your teams and see if you can realize the same benefits. 

Customer collaboration over contract negotiation

GitHub allows customers to look at the code if they are interested, and especially the specs. Jenkins allows them to watch the test suite grow, and see that they are keeping the tests passing. What? My customer looking at my code base and test execution? Yes. This is what transparency and true partnership is all about. Think of some of the true business partnerships you’ve experienced in your career and I’m sure that they involved a lot of transparency from both sides.

Responding to change over following a plan 

“Plans are nothing. Planning is everything” - General Eisenhower.

When the allies stormed the beaches of Normandy in 1944, they had a very detailed plan of attack. This plan led to their assumed victory over Germany before Christmas of that year. That plan was doomed from the start. How could it be otherwise? How could a plan for hundreds of thousands of soldiers, millions of pounds of supplies and thousands of missions all work out according to a plan on paper? Eisenhower knew it wouldn’t. That’s why there were always contingencies. That’s why the allies were always adjusting the plan based on the reality of the emerging battles.

Agile follows similar reasoning. A popular misconception about agile is that it doesn’t allow for plans. This isn’t true. Agile focuses on the activity of planning rather than focusing on a fixed plan. A certain amount of knowledge about any project is going to be well known. Just as the allies knew the location of the beaches they were going to land on, a game development project will begin with quite a bit of knowledge about the genre and market targets for the game to be developed. It is necessary to plan for these things and to share that plan. The problem occurs when the planning goes too far. I’ve seen a game design document for a fantasy shooter game that had the bullet count for each of the clip types of every weapon. How can we know how many bullets per clip we should have in a game? Why do we need to plan for that detail before we have the knowledge of what we need? This is an example of the source of problems that detailed plans can create. If the team sticks to the detailed plan, then it won’t be the best game possible. Great game emerge.

The agile approach is to plan for what is known and to execute against what is not known iteratively. In other words, agile is focused on gaining knowledge. If we don’t know how many bullets in a clip or what type of weapons will be the most fun, we don’t try to plan away that uncertainty on paper. We address it head on by building weapons early and learning what is best.

Many elements of a plan are assumptions. We assume the things that we put into a game design document are going to contribute to a hit game. Some of these assumptions are correct, some are not. By implementing and testing these assumptions, we change some of them. We then alter the plan to create a better game.

What does this mean for managers?

For the traditional manager encountering Agile for the first time, counter-intuitive ideas abound. Managers find they can’t tell people what to do. Firms make more money by not focusing on making money. Dealing with big issues requires building on tiny teams. Control is enhanced by letting go of control. Leaders are less like heroic conquering warriors and more like curators or gardeners.

When traditional managers enter an Agile organization where these seeming paradoxes are the norm, it’s like travelers visiting a strange foreign country where everything is different: yes may mean no, where no one pays fixed prices, and where laughter may signify fury. The familiar cues that enable travelers to function in their home country are absent. In their place are new cues that are weird and incomprehensible. The result can be bewilderment, frustration, and an inability to cope. Until the travelers grasp what has happened, learn the new cues of the different country and embody them in their behavior, they will find themselves disoriented and incompetent to deal with the different environment.

That’s why Agile can’t be implemented within the assumptions of current management practice. Agile means embracing fundamentally different assumptions. For traditional managers, the process usually isn’t comfortable. It isn’t easy. At the outset, it feels just wrong. It’s like learning a strange foreign language. It is only over time and through actual experience and practice that Agile becomes second nature and automatic. This is not about “doing Agile.” It’s about “being Agile.”

There’s much to learn for a traditional manager involved in an Agile transformation. The way you currently manage is most likely detrimental to your success. There’s much scientific evidence to support this. Researchers have documented that traditional management control is harmful to the development and progress of modern businesses. Yet, the management approach used by most companies to this day has remained largely unchanged over the last century. Traditional management methods are great if what you want is compliance from your employees. If you want real employee engagement you need to look at management in a very different way.

One way to look at this is by giving your employees more autonomy. As managers you can set the goals and let the employees decide how to achieve these goals. This is very different than the traditional approach to management. In fact, a study from Cornell University on the effect of worker autonomy at 320 small businesses found that the ones offering autonomy grew four times faster than traditionally-managed companies. Furthermore, these companies had one-third of the turnover of their counterparts.

So if you aren’t getting all the results you’re looking for, start by looking in the mirror and ask yourself: am I giving my employees the opportunity to operate to their full potential?

What type of company would you rather run?

Agile Values - Down to Earth and Practical

December 23, 2017

As 2017 comes to a close I wanted to share some of the experiences I came across this year that I thought were really simple, down to earth, and practical ways of approaching Agile. What follows is by no means an exhaustive list of Agile practices but it’s a set of down to earth practices that may be a good starting point for many companies who are still trying to wrap their arms around the whole Agile movement.