Sometimes you have to lay low.
I know of a company where the IT department calls its monthly code releases “Agile” because they occur regularly. This confuses the rest of the IT department, because it has several teams doing Scrum, one of the best-known set of Agile software practices. The Scrum teams have been trained and know that key practices of Scrum include the following:
· A co-located team with team-managed processes
· The team includes QA & a business sponsor (called the Product Owner)
· Work is done in short iterations (usually 2 weeks) with demonstration of working software at the end of each iteration
· There is daily (or more frequent) integration of all code
· Automated test suites run at every integration
There are other practices, but that covers the essentials.
Now, why would the IT department want to call their monthly releases “Agile”? I can imagine several reasons. 1. Management wants to be seen as being on top of a current trend called Agile. 2. Doing monthly releases stresses the system enough that it makes sense to call the people running the releases Agile. 3. It forestalls the imposition of real Agile frameworks on the IT department, which would really change things.
A company has to decide to take the heat of change when it decides to go Agile in its software development. And by “company”, I mean the top management. Anything less than full commitment by at least one of the C-suite officers and a full chain of management command all the way down to a functioning team will not get the job done. And what is the job? Implementation of a framework for software development that will embrace change as it happens, be productive, and create a satisfying workplace for software developers.
We’re talking about serious productivity changes here. The studies I’ve seen show that poorly implemented Agile teams achieve only a doubling of results compared with a classic waterfall framework. The well-implemented ones achieve 9 times the productivity.
So if you’re in a large enterprise that has launched at least one Agile team, look around. If you find management support, good tools, and respect for the changing environment needed for Agile, then go ahead and lobby to join an Agile team.
If you don’t find those things, it may be best to lay low – and just start adopting Agile practices quietly, without calling attention to what you’re doing.
__________________________________
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
I know of a company where the IT department calls its monthly code releases “Agile” because they occur regularly. This confuses the rest of the IT department, because it has several teams doing Scrum, one of the best-known set of Agile software practices. The Scrum teams have been trained and know that key practices of Scrum include the following:
· A co-located team with team-managed processes
· The team includes QA & a business sponsor (called the Product Owner)
· Work is done in short iterations (usually 2 weeks) with demonstration of working software at the end of each iteration
· There is daily (or more frequent) integration of all code
· Automated test suites run at every integration
There are other practices, but that covers the essentials.
Now, why would the IT department want to call their monthly releases “Agile”? I can imagine several reasons. 1. Management wants to be seen as being on top of a current trend called Agile. 2. Doing monthly releases stresses the system enough that it makes sense to call the people running the releases Agile. 3. It forestalls the imposition of real Agile frameworks on the IT department, which would really change things.
A company has to decide to take the heat of change when it decides to go Agile in its software development. And by “company”, I mean the top management. Anything less than full commitment by at least one of the C-suite officers and a full chain of management command all the way down to a functioning team will not get the job done. And what is the job? Implementation of a framework for software development that will embrace change as it happens, be productive, and create a satisfying workplace for software developers.
We’re talking about serious productivity changes here. The studies I’ve seen show that poorly implemented Agile teams achieve only a doubling of results compared with a classic waterfall framework. The well-implemented ones achieve 9 times the productivity.
So if you’re in a large enterprise that has launched at least one Agile team, look around. If you find management support, good tools, and respect for the changing environment needed for Agile, then go ahead and lobby to join an Agile team.
If you don’t find those things, it may be best to lay low – and just start adopting Agile practices quietly, without calling attention to what you’re doing.
__________________________________
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
1 comment:
Hello nice blogg
Post a Comment