Five Things Managers (Usually) Don't Get About Agile

Clash 1: Goals
Traditional development methods set three goals:
  • Keep within budget
  • Implement all requirements (often specified before the project starts)
  • Make the deadline
Agile projects set the following goal:
  • Maximize the Return On Investment (ROI)
To maximize the ROI, an agile project changes the following variables:
  • Cost
  • Scope
  • Time
In other words, what traditional software development, and most companies, set as fixed goals, are just the things an agile project need to change to reach its goal.

Clash 2: Push vs. Pull
Another major difference is that most companies, and traditional development methods, are based on push systems, while agile is based on pull systems. :
  • In a push system, each step in a production line does what the previous step tells it to do.
  • In a pull system, each step in a production line does what the following step has to do.
The situation when orders start travelling from both ends of the command chain can at best be described as chaotic.

Clash 3: Cost Efficiency vs. Lead Time Reduction
A third difference is that traditional methodologies, and traditionally managed companies, seek to raise the cost efficiency, while agile methodologies seek to reduce lead times. There is a connection between the two:
  • When cost efficiency goes up, lead times will also go up
  • When lead times are reduced, cost efficiency goes down
It should be IOTTMCO that if corporate management seeks to push cost efficiency up, while a project team seeks to push lead times down, there will be a clash.

Clash 4: Responsibilities
A fourth difference is that agile is based on systems thinking, and views most problems as systemic, and therefore the responsibility of the system owners, which is of course the management. Traditional management, on the other hand, views most problems as special cause problems, and leave it to their work force to do firefighting.

Clash 5: Attitude to Knowledge and Training
Scientific Management based, management seeks to make people easily replaceable by reducing the amount of training each person needs to do his or her job. (This shows very clearly in the RUP philosophy of dividing work into very narrowly defined roles.) In original Scientific Management, the idea was that profound knowledge of how processes work should reside with management. Today, the SM philosophy has lead to management reducing their own knowledge about how systems work to practically nothing.

In contrast, agile emphasizes very broad training, so that each individual can fit as many jobs as possible. Management is expected to have very deep knowledge of systems thinking, Lean, TOC, and of course of agile philosophy and practices.

Comments

Post a Comment

Popular posts from this blog

Waterfall vs. Agile: Battle of the Dunces or A Race to the Bottom?

Image
The major software methodology wars since the mid 1950’s. Someone was wrong on the Internet, so here we go… In a recent HBR article, It’s Time to End the Battle Between Waterfall and Agile , the author sets up a false premise: There is a war between Waterfall methodology and Agile. The war must end. And finally, you can combine the approaches to get the best of both worlds. This sounds good, but the article is based on a misunderstanding of both Waterfall and Agile. Also, there is no war between Waterfall methodology and Agile. There can’t be, because Waterfall methodology does not exist! Waterfall is a name for large projects that failed in the 1960’s. Waterfall was never a methodology, but a failure to apply the methodologies that existed back then. As I will show towards the end of this article, at least one of the “successful” Waterfall projects mentioned in the HBR article was neither successful, nor a Waterfall project. I got invaluable help from Alistair Cockburn. He fact che
Read more

Performance Evaluations, Business Strategy, and Agile Methodologies

Image
It is performance evaluation time in many companies. This can be stressful, both to the people being evaluated, and the people doing the evaluation. In companies adopting agile software development methods, the tension can be extraordinary. Individual performance evaluations run counter to agile philosophy, which emphasizes team performance over individual performance. However, managers and corporate leaders need to take a few steps back, and consider the impact performance evaluations have on the organization as a whole. Especially now, in the midst of a recession, it is important to look at a companies current policies to see if they can be improved, or if they are actually holding the company back. So, how can a manager evaluate policy? Performance evaluation policies can serve as an excellent example. I'll confine myself to discussing the so-called ‘rank and yank’ methods. These are performance reviews were employees are ranked using a forced ranking system. It usually looks so
Read more

Agile Requirements Structures, Part 1

Image
If you have worked in large Agile projects or programs, you may have noticed that there is often quite a bit of confusion about requirements, what the requirement types are, their purpose, how to write them, how to use them, and above all, what not to do with them. There are many causes for this confusion. Here are some of the more common I have seen: Nobody in the organization has read up on the requirements model it is using, so everyone makes their own interpretation. The organization deviates from a standard requirements model, but nobody knows which standard model the organization is deviating from, and/or there is no agreement about how they deviate from it. The organization has not documented its own requirements model very well. The organization mixes two or more different requirements models, often without realizing it. The organization has documented its requirements model, but finding the documentation is an epic project in itself, on par with when Henry Sta
Read more