Just an outline,

1. Whitepaper on Agile implementation
Wednesday, March 03, 2010
10:11 PM
TOC
Introduction Introduction
The story (problem domain) Over the years I'd been hearing about different methodologies to manage the
The challenge SDLC. I had felt a lot of pain along with my fellow devs as we were on pur path of
The goals developing and delivering software. I would see mistakes repeated again and
again. Many times I would change jobs hoping to find a place with more
The problem domain successful SDLC practices, greater control on quality and more experienced
As a company/team we would have major issues with the following: management.
1. associating what we were building to what the customer wanted Time and time again I would be disappointed, only to find the same mistakes I
2. Keeping track of our progress had run away from in one place being repeated in the other. Only the names
3. Tracking the impact of changes in requirement on the rest of the would change, but the story remained the same.
development cycle
4. Keeping our documentation up to date Vague requirements, would spark a project with a lot of assumptions, we would
5. More importantly communicating changes/ designs/decisions/ assume our way through the proposal phase, making the proposal itself
guidelines to the team extremely vague. If by chance we would succeed in securing the deal, the
6. Measuring h0ow well the team was doing in terms of progress and requirements would be gathered in an extreme rush and the design document
quality would be a 2 week effort max, where we would spend the time creating pretty
diagrams.
The development phase is where we would start to have the real pain since this
i…...
The challenge
1. Keeping the team morale during tough deadlines
2. Making sure the team fully understood what was being built and how the components would fit
together
3. Convincing the team of the necessity of documenting change and making sure they have the
discipline to do that
4. Communicating the effect of changing requirements on the delivery schedule to the customer
while negotiating more favorable payment terms
5. Ensuring delivery on time with even the minimal acceptable quality
The Story
I was a new hire in the company, with high hopes that I would be Lessons learned
capable of changing the way we delivered projects. I was expected
to create a team, run a process and deliver a project all in one.
I really enjoyed the challenge and the idea that I would e allowed to
create my own team, the way I wanted to.
We started hiring, I made sure we had really high standards before
we accepted any resource. I was a firm believer in the "commando
theory" where a small team of really smart people would be better
than a large army of average skilled devs.
Team creation
Environment setup (night;ly builds, source control)
User stories-- the requirements issue (no BA)
Iteration 0-- delivering the prototype to production (minor
refactoring -- arrow anti pattern )
Iteration 1-- refactoring the prototype/ adding features/ fixing bugs
Iteration 2-- the P.M. enters the project
Managing requirements, canceling the build, technology decisions
Presentations Page 1

2. Presentations Page 2