Living up to the Agile Principles
Agile development is an approach to software development that we can all agree is effective and efficient. In many cases when companies adopt this approach they fail miserably, resulting in unfinished products or products that fail to deliver the necessary value.In my opinion the reason for this failure is a failure to understand the principles of the Agile Manifesto.
In many cases organizations focus way too much in the process itself as opposed to the philosophy behind it all. Organizations either approach it with a by the numbers approach as dictated by some certification process or agile specialist or with a make up the rules as you go approach. Both of these approaches have a negative effect.
In the former case an extreme amount of effort is placed on the process itself and not on the focus of delivering working software early and frequently. This also comes with working extra hours over 40 a week which in turn burns out the developers. Developers can become frustrated at this point and leave the organization at the smell of a project destined for failure, which in turn causes even more turmoil for the project.
In the latter case business analysts/customers run the show and believe that they can continue to make changes to the user experience and to the business rules. While it is true that agile promotes many forms of flexibility, it does not mean that solid acceptance criteria cannot be well defined upfront.
Our current approach is to break down tasks into manageable tasks and deliver working software frequently. Usually in two or three week increments. We don't work in the traditional manner where all agreed upon work must be delivered at the end of each two week sprint. Instead some work will be delivered at the end of the first week and some other work will be delivered on the second week.
We do all of this while keeping our focus on a strict deadline. Our deadline is fixed from day one and our milestones are set usually within the first week into the release and each milestone is critical within the schedule. When the clock starts ticking for us we only have some high level requirements that we have a ball park idea on level of effort. We work in parallel with our business analysts and QA team to ensure that we are all working on the functional requirements, coding, testing scenarios and user manuals simultaneously.
We have take this approach for several releases now and we have been successful at delivering each time.
Here are some of the things that help us achieve this
1. We use Cruise Control for continuous integration. This means that our build processes are only one click away. Builds occur within 15 minutes of any commit to ensure that our build is never broken (not for long anyway - it breaks from time to time but only for a few minutes). This means that we can build software with just one click. This also delivers the software to a location where the entire team can download it for install (it is a windows solution).
2. We use Redmine as a the bug tracking tool that enables to track all work - backlog and defects. This enables us to keep tracking of the current status of each feature, defect, etc.
3. We have daily stand-ups with all representative members of the team. There is too many people on the team to include everyone so each team meets with their respective leaders and all the leaders come together to discuss all the pertinent issues daily. Since we have daily collaboration amongst all members of the team there is no communication disconnects. Some of our teams also have their own individual stand-ups to track their own progress.
4. We work with known requirements but code for change and embrace it. In many cases we are still working while the functional specifications are being developed. We've discovered that as long as we all can agree that there will be change and the software will not be perfect the first time we all can get along a lot better. We also code with that concept in mind and try to anticipate the sort of changes that we might be faced with.
5. We take all suggestions from team members to improve the processes seriously. As an example earlier in the release we were holding all team member meetings but someone suggested that we only include the leaders since the usual response from the developers just pointed out the obvious. This allowed us to focus on issues that required further clarification or consensus from the team.
6. The members from each different team collaborate together on each feature. A normal collaboration may require a developer demonstrating a feature to a business analyst and a tester reviewing the feature with the latest build and providing feedback. This may also require some work from the DBA in the form of writing stored procedures. Because the technical writers also have access to the application they can also approach the developers for any additional information.
I think this can give you an idea of where we actually follow those very concepts advocated by the agile manifesto without actually operating in a formal agile methodology.
If you would like to read the Agile Manifesto you can read it at http://www.agilemanifesto.org/principles.html.
I am quite proud of what we've been able to accomplish using agile principles without actually adopting a formal agile methodology. We don't do many things that an agile purist would argue is necessary for a successful delivery like the use of user stories, swim lane/back log boards
, formal sprints, feature estimation. What we do is deliver working software frequently and adapt and embrace changes. We do all of this through frequent team collaboration. This is what agile is all about.
In many cases organizations focus way too much in the process itself as opposed to the philosophy behind it all. Organizations either approach it with a by the numbers approach as dictated by some certification process or agile specialist or with a make up the rules as you go approach. Both of these approaches have a negative effect.
In the former case an extreme amount of effort is placed on the process itself and not on the focus of delivering working software early and frequently. This also comes with working extra hours over 40 a week which in turn burns out the developers. Developers can become frustrated at this point and leave the organization at the smell of a project destined for failure, which in turn causes even more turmoil for the project.
In the latter case business analysts/customers run the show and believe that they can continue to make changes to the user experience and to the business rules. While it is true that agile promotes many forms of flexibility, it does not mean that solid acceptance criteria cannot be well defined upfront.
Our current approach is to break down tasks into manageable tasks and deliver working software frequently. Usually in two or three week increments. We don't work in the traditional manner where all agreed upon work must be delivered at the end of each two week sprint. Instead some work will be delivered at the end of the first week and some other work will be delivered on the second week.
We do all of this while keeping our focus on a strict deadline. Our deadline is fixed from day one and our milestones are set usually within the first week into the release and each milestone is critical within the schedule. When the clock starts ticking for us we only have some high level requirements that we have a ball park idea on level of effort. We work in parallel with our business analysts and QA team to ensure that we are all working on the functional requirements, coding, testing scenarios and user manuals simultaneously.
We have take this approach for several releases now and we have been successful at delivering each time.
Here are some of the things that help us achieve this
1. We use Cruise Control for continuous integration. This means that our build processes are only one click away. Builds occur within 15 minutes of any commit to ensure that our build is never broken (not for long anyway - it breaks from time to time but only for a few minutes). This means that we can build software with just one click. This also delivers the software to a location where the entire team can download it for install (it is a windows solution).
2. We use Redmine as a the bug tracking tool that enables to track all work - backlog and defects. This enables us to keep tracking of the current status of each feature, defect, etc.
3. We have daily stand-ups with all representative members of the team. There is too many people on the team to include everyone so each team meets with their respective leaders and all the leaders come together to discuss all the pertinent issues daily. Since we have daily collaboration amongst all members of the team there is no communication disconnects. Some of our teams also have their own individual stand-ups to track their own progress.
4. We work with known requirements but code for change and embrace it. In many cases we are still working while the functional specifications are being developed. We've discovered that as long as we all can agree that there will be change and the software will not be perfect the first time we all can get along a lot better. We also code with that concept in mind and try to anticipate the sort of changes that we might be faced with.
5. We take all suggestions from team members to improve the processes seriously. As an example earlier in the release we were holding all team member meetings but someone suggested that we only include the leaders since the usual response from the developers just pointed out the obvious. This allowed us to focus on issues that required further clarification or consensus from the team.
6. The members from each different team collaborate together on each feature. A normal collaboration may require a developer demonstrating a feature to a business analyst and a tester reviewing the feature with the latest build and providing feedback. This may also require some work from the DBA in the form of writing stored procedures. Because the technical writers also have access to the application they can also approach the developers for any additional information.
I think this can give you an idea of where we actually follow those very concepts advocated by the agile manifesto without actually operating in a formal agile methodology.
If you would like to read the Agile Manifesto you can read it at http://www.agilemanifesto.org/principles.html.
I am quite proud of what we've been able to accomplish using agile principles without actually adopting a formal agile methodology. We don't do many things that an agile purist would argue is necessary for a successful delivery like the use of user stories, swim lane/back log boards
, formal sprints, feature estimation. What we do is deliver working software frequently and adapt and embrace changes. We do all of this through frequent team collaboration. This is what agile is all about.
Comments