I was expecting slightly more response to my “Why managers don’t get Agile” post last week because this is an issue that comes up again and again and again. Hans Wegener (of metadata fame) did respond and for some unknown reason his comment ended up on the wrong blog post (May’s post on making strategy) - his comment is here.
I certainly didn’t intend to come across as anti-control. True, I do believe that less control and more self-organization can improve results but I know that some control is necessary. The point i was trying to make is: Agile methods do not discuss the role of the manager much, and they appear to loosen control on the development effort. Therefore it is hardly surprising that managers don’t “get” Agile.
Actually I believe that Agile development improves control in an organization for several reasons.
First the illusion of control is exposed. Estimates, GANTT charts and “management by exception” never really controlled development work, they just presented an illusion of control. So much upfront planning was just planning theatre, it never really changed much, development work carried on much the same, work took as long as it took whether the estimate was 1 day or 1 month. Agile strips away many of these illusions - that’s why it is painful at first.
Secondly Agile improves control because work can be stopped at any time and still produce benefits. Stop a traditional project half way through and you have a lot of code which implements some features but is so full of bugs that it is usually unusable. Stop an Agile project half way through and you may have fewer features but the features you have are usuable, there is no need for a test-fix-test cycle.
The removal of the test-fix-test cycle also improves management control. Traditionally this cycle takes up an unpredictable amount of time at the end of the project. Because it is unpredictable control is lost.
Third - and final for the moment - because Agile teams are focused on delivering what the business wants they don’t develop anything else and do deliver what was asked for. Again more effective control.
However this third point does put a responsibility on the customer/business side of things to be able to articulate what it actually wants and to take a part in creation and verification. Again this might look like a loss of control but it isn’t.
For example, a traditionally request might be “Add a widget to the website” and at some unknown date in the future the widget would be added - the colour, size, shape and functionality of the widget might not be what was expected but was there. Such a request given to an Agile team is likely to result in a whole bunch of questions: “What shape do you want it? Colour? When by?” etc. etc. This might look like a loss of control but in fact the team is giving more control to the requester.
One of the things I always tell clients is that Agile exposes problems, and in this case a problem with the management of IT work has been exposed.
Hans ends his post with the comment: “I can't prove this, but I have a theory: developers don't "get" management” and I have to agree with him. Superficially management is like coding, its about organizing stuff, connecting things and putting things in order. However it is very different: the fundamental building block of management is not lines of code but people. Mangers work in ambiguous environments with a lack of information and few ways of testing a hypothesis.
I’m also convinced that many (even most) of the problems software development faces are the result of poor management not technology. Developing software may look easy but it is hard, not only do you need good coders and testers but you need good managers. Being a good coder does not make you a good manager and being a good manager does not make you a good development manager.
I certainly didn’t intend to come across as anti-control. True, I do believe that less control and more self-organization can improve results but I know that some control is necessary. The point i was trying to make is: Agile methods do not discuss the role of the manager much, and they appear to loosen control on the development effort. Therefore it is hardly surprising that managers don’t “get” Agile.
Actually I believe that Agile development improves control in an organization for several reasons.
First the illusion of control is exposed. Estimates, GANTT charts and “management by exception” never really controlled development work, they just presented an illusion of control. So much upfront planning was just planning theatre, it never really changed much, development work carried on much the same, work took as long as it took whether the estimate was 1 day or 1 month. Agile strips away many of these illusions - that’s why it is painful at first.
Secondly Agile improves control because work can be stopped at any time and still produce benefits. Stop a traditional project half way through and you have a lot of code which implements some features but is so full of bugs that it is usually unusable. Stop an Agile project half way through and you may have fewer features but the features you have are usuable, there is no need for a test-fix-test cycle.
The removal of the test-fix-test cycle also improves management control. Traditionally this cycle takes up an unpredictable amount of time at the end of the project. Because it is unpredictable control is lost.
Third - and final for the moment - because Agile teams are focused on delivering what the business wants they don’t develop anything else and do deliver what was asked for. Again more effective control.
However this third point does put a responsibility on the customer/business side of things to be able to articulate what it actually wants and to take a part in creation and verification. Again this might look like a loss of control but it isn’t.
For example, a traditionally request might be “Add a widget to the website” and at some unknown date in the future the widget would be added - the colour, size, shape and functionality of the widget might not be what was expected but was there. Such a request given to an Agile team is likely to result in a whole bunch of questions: “What shape do you want it? Colour? When by?” etc. etc. This might look like a loss of control but in fact the team is giving more control to the requester.
One of the things I always tell clients is that Agile exposes problems, and in this case a problem with the management of IT work has been exposed.
Hans ends his post with the comment: “I can't prove this, but I have a theory: developers don't "get" management” and I have to agree with him. Superficially management is like coding, its about organizing stuff, connecting things and putting things in order. However it is very different: the fundamental building block of management is not lines of code but people. Mangers work in ambiguous environments with a lack of information and few ways of testing a hypothesis.
I’m also convinced that many (even most) of the problems software development faces are the result of poor management not technology. Developing software may look easy but it is hard, not only do you need good coders and testers but you need good managers. Being a good coder does not make you a good manager and being a good manager does not make you a good development manager.
I think its tough for organisations that don't have a Lean bias as "First the illusion of control is exposed." is essentially telling management: you know all that time you spend in meetings trying to plan and control, it's all wasted because it has no effect on the outcome. This puts people on the back foot. So I think the key to getting buy-in is presentation, education and transition in a way that doesn't cause the management of the team to feel too bad about what they've been doing in the past.
ReplyDeleteInteresting stuff, thanks!