Agile managers are supposed to be "servant leaders" and to spend a good deal of their time removing impediments to effective work by the team. What happens when the impediments you're trying to remove are so big that (a) the team is working at half efficiency at best, and (b) removing the impediments requires intervention up the management ladder at least 2 or 3 levels?For example, an enterprise I know about has barriers to efficient work that have to do with software environments and bureaucratic procedures for deployment of releases. A manager at the VP level has reported that when a funding request to fix the environments comes up, it gets knocked out by the financial folks "because it won't increase revenue." Meanwhile, releases take an extra week or two because approvals have to travel up a 3-link chain, the last two of whom are not in fact concerned with (or knowledgeable about) the particulars of the intended release.
It's easy to get frustrated with such impediments. As one of the technical staff said recently, it's a case of "I love the work and hate the company." Not that the place of employment is unpleasant -- on the contrary, it's a very supportive and friendly physical place to work, at least on the surface. But the ossified bureaucracy indicates that something about the enterprise is extremely un-Agile.
Within this context, however, there are positive indicators: a significant number of bright, capable and "agile" people who recognize what should be done; strategic initiatives coming from the top that seem well-focused; and a willingness to bring in new ideas -- and consultants. This sets up an interesting tension between the "let's get the transformation done and move on" people and the "we have to follow the rules and processes that have worked for us for so long" people. Even this statement is not entirely fair: the "rules and processes" people are doing what needs to be done to satisfy the financial processes that make the place run, even as they know that something has to change. So the challenge is to establish ways to evolve the processes into something more agile.
Can an agile software consultant do that? Probably not. But the consultant can do a number of useful things. One is to encourage teams to operate in an agile way, while finding practical ways to feed the needed numbers into the financial gear-works. Another is to provide unbiased information from grass-roots teams to key change agents (managers who are moving the enterprise in the Agile direction). And finally, a consultant can advise the decision-makers when old processes are just too creaky to keep as the enterprise moves into the 21st century competitive world.
Of course, you may be able to do all of these things from within the enterprise, too. Be the consultant and change agent; but be sure you have the support of your network of other change agents -- you may need it to keep your job.
_______________________________________
John Levy consults on Agile development and is an expert witness in computer & software patent cases. He has 30 years’ experience as a technology manager at Quantum, Apple, Tandem and DEC. His book on managing technology, Get Out of the Way, is due out in 2009. Check him out at http://johnlevyconsulting.com
It's easy to get frustrated with such impediments. As one of the technical staff said recently, it's a case of "I love the work and hate the company." Not that the place of employment is unpleasant -- on the contrary, it's a very supportive and friendly physical place to work, at least on the surface. But the ossified bureaucracy indicates that something about the enterprise is extremely un-Agile.
Within this context, however, there are positive indicators: a significant number of bright, capable and "agile" people who recognize what should be done; strategic initiatives coming from the top that seem well-focused; and a willingness to bring in new ideas -- and consultants. This sets up an interesting tension between the "let's get the transformation done and move on" people and the "we have to follow the rules and processes that have worked for us for so long" people. Even this statement is not entirely fair: the "rules and processes" people are doing what needs to be done to satisfy the financial processes that make the place run, even as they know that something has to change. So the challenge is to establish ways to evolve the processes into something more agile.
Can an agile software consultant do that? Probably not. But the consultant can do a number of useful things. One is to encourage teams to operate in an agile way, while finding practical ways to feed the needed numbers into the financial gear-works. Another is to provide unbiased information from grass-roots teams to key change agents (managers who are moving the enterprise in the Agile direction). And finally, a consultant can advise the decision-makers when old processes are just too creaky to keep as the enterprise moves into the 21st century competitive world.
Of course, you may be able to do all of these things from within the enterprise, too. Be the consultant and change agent; but be sure you have the support of your network of other change agents -- you may need it to keep your job.
_______________________________________
John Levy consults on Agile development and is an expert witness in computer & software patent cases. He has 30 years’ experience as a technology manager at Quantum, Apple, Tandem and DEC. His book on managing technology, Get Out of the Way, is due out in 2009. Check him out at http://johnlevyconsulting.com
No comments:
Post a Comment