Rolling out an agile development process
I have been asked to help in introduction of a development process for the team working on a greenfield project. The team consist of dozen or so developers with a given task to replace an old legacy system with something which will perform better, will be more flexible and easier to maintain. The existing process that is based on individuals being assigned to never-ending stream of tasks (mostly maintenance, bugfixes and improvements) might work, in my opinion, when system is not in active development stage, therefore not ideal for the greenfield project when there is much bigger density of innovation and collaboration required to succeed.
Interesting task I have to say. I think I will approach this by addressing both project management and engineering requirements by setting up an iterative process based on bits and pieces from Scrum and XP. It shouldn’t be a surprise to anyone involved in the past in Web21C Experiment. The Scrum process will kick off with pretty standard set of features hence I will not bother you with details.
What I want to achieve in field of team organisation is to:
- grow a successful team that delivers business value (doh!) as soon as possible (doh!)
- improve internal and external communication and information flow
- share common understanding of the domain and the system
- learn how to cope with inevitable change
- activate developers to be more encouraged to introduce new ideas and solutions
- put the team in position to be more in the partner relationship with business
- improve motivation and satisfaction from work
- encourage being passionate about technology and sharing that passion
In the same time in field of engineering practices I’ll stand my ground on:
- automation, automation, automation
- continuous integration
- code coverage
- automated integration tests
- patterns
- non mandated on-request pairing (you wonder what it is?)
- lightweight solutions
- shared code-ownership
There is an interesting lean Kanban process on horizon which looks as a good match for the environment however I will not be pushing for this initially. As the process should evolve over time there is always time to navigate original agile scrum process towards something which can be maybe a better choice. Only time will prove.
Comments, advice?
Popularity: 27% [?]
