Couple of reasons for lack agility from my experience:-
- IT has different meaning in these organizations - it has almost nothing to do with software development. So called "IT Managers" are guys who have crawled up the corporate ladder the hard way or guys with no software background whatsoever, but who are supposedly good in managenment, can talk confidently and convincingly.
- Count the layers between actual users and "developers": Process team, Business Analyst team, Change Management, project management, release management and database administrators. Just imagine explaining a small piece of development to all of these groups - adding one field to an existing webpage could take months.
In the past, I have used Microsoft Excel to do UI prototyping. It has some features which can be used to convey the design:-
- Cell Comments: To mention any special logic etc on a particular field on the screen.
- Can show drop downs, buttons.
- Use multiple sheets and make the hyperlink work to navigate between sheets.
- Can use colors to mark changes to some sections to existing UIs.
Funny that I have been reading today in Gregory Bateson's "Steps to an Ecology of Mind" that when we learn something and make a habit it sinks deep down to subconscious such a way that we can do it without even knowing explicitly. This is supposed to save the effort of applying the knowledge of how to do it every time. So we can walk and ride bike without even knowing we are doing it. Maybe this study shows where all this "sinks" to.
When something new comes out, there will be a tendency to ignore it and watch it out of the corner of the eye to see if it goes away. Once something grows in size and complexity, it looks intimidating to get into. That disadvantage can be avoided by getting in early.
A new idea can sometimes be extended and new avenues of use can be found. Early adopters may get a chance to become innovators too that way.
- Have a good estimation template, guidelines for estimate, documentation to say how estimate is reached at. Explain the estimation procedure to management and get their approval. First cut of estimate can be based on previous experience and promise management that estimation figures will be improves by periodic analysis.
- Insist on estimating all developments upfront (this will require clear requirements upfront). While giving estimates, list the assumptions and features considered. Put in a disclaimer that any change to above will require a change in estimate.
- Implment a change tracker to show to management how many changes came in during development. Estimate the changes and appraise management periodically about changes. Insist on freezing requirement/design at a stage after which change will be more costly.
- Create a schedule based on estimate and publish the progress. Let the management know as soon you encounter any critical issue which may derail the schedule.
This kills agility of development and sometimes breeds lack of trust between users and IT. But putting it into a rigid framework of process reduces chances for others to blame you.
sometimes we stick to something just because we are comfortable and do not want to disturb anything that is going just fine. but as it goes, highest dividents are paid for highest risks. it doesn't mean we have to gamble with life, but if every instinct tells you to take that job and only money is pulling you back, probably you should take it. in my experience, psuedo-managerial jobs will only dumb you down.
every cliche in this world will ask you to go for happiness when faced with such choices. so that is a natural choice. but remember that always grass looks greener on the other side. life on the other side may not be as rewarding as it made out to be, but you will not know unless you try it out.
so, try it out and tell us how it went.
Slashdot Mirror
Couple of reasons for lack agility from my experience:-
- IT has different meaning in these organizations - it has almost nothing to do with software development. So called "IT Managers" are guys who have crawled up the corporate ladder the hard way or guys with no software background whatsoever, but who are supposedly good in managenment, can talk confidently and convincingly.
- Count the layers between actual users and "developers": Process team, Business Analyst team, Change Management, project management, release management and database administrators. Just imagine explaining a small piece of development to all of these groups - adding one field to an existing webpage could take months.
In the past, I have used Microsoft Excel to do UI prototyping. It has some features which can be used to convey the design:-
- Cell Comments: To mention any special logic etc on a particular field on the screen.
- Can show drop downs, buttons.
- Use multiple sheets and make the hyperlink work to navigate between sheets.
- Can use colors to mark changes to some sections to existing UIs.
Funny that I have been reading today in Gregory Bateson's "Steps to an Ecology of Mind" that when we learn something and make a habit it sinks deep down to subconscious such a way that we can do it without even knowing explicitly. This is supposed to save the effort of applying the knowledge of how to do it every time. So we can walk and ride bike without even knowing we are doing it. Maybe this study shows where all this "sinks" to.
When something new comes out, there will be a tendency to ignore it and watch it out of the corner of the eye to see if it goes away. Once something grows in size and complexity, it looks intimidating to get into. That disadvantage can be avoided by getting in early.
A new idea can sometimes be extended and new avenues of use can be found. Early adopters may get a chance to become innovators too that way.
- Have a good estimation template, guidelines for estimate, documentation to say how estimate is reached at. Explain the estimation procedure to management and get their approval. First cut of estimate can be based on previous experience and promise management that estimation figures will be improves by periodic analysis.
- Insist on estimating all developments upfront (this will require clear requirements upfront). While giving estimates, list the assumptions and features considered. Put in a disclaimer that any change to above will require a change in estimate.
- Implment a change tracker to show to management how many changes came in during development. Estimate the changes and appraise management periodically about changes. Insist on freezing requirement/design at a stage after which change will be more costly.
- Create a schedule based on estimate and publish the progress. Let the management know as soon you encounter any critical issue which may derail the schedule.
This kills agility of development and sometimes breeds lack of trust between users and IT. But putting it into a rigid framework of process reduces chances for others to blame you.
sometimes we stick to something just because we are comfortable and do not want to disturb anything that is going just fine. but as it goes, highest dividents are paid for highest risks. it doesn't mean we have to gamble with life, but if every instinct tells you to take that job and only money is pulling you back, probably you should take it. in my experience, psuedo-managerial jobs will only dumb you down.
every cliche in this world will ask you to go for happiness when faced with such choices. so that is a natural choice. but remember that always grass looks greener on the other side. life on the other side may not be as rewarding as it made out to be, but you will not know unless you try it out. so, try it out and tell us how it went.