TOCIntroductionThe story (problem domain)The challengeThe goals

IntroductionOver the years I'd been hearing about different methodologies to manage the SDLC. I had felt a lot of pain along with my fellow devs as we were on pur path of 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 successful SDLC practices, greater control on quality and more experienced management.Time and time again I would be disappointed, only to find the same mistakes I had run away from in one place being repeated in the other. Only the names would change, but the story remained the same.

Vague requirements, would spark a project with a lot of assumptions, we would assume our way through the proposal phase, making the proposal itself extremely vague. If by chance we would succeed in securing the deal, the requirements would be gathered in an extreme rush and the design document 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 problem domain

associating what we were building to what the customer wanted1.Keeping track of our progress2.Tracking the impact of changes in requirement on the rest of the development cycle

3.

Keeping our documentation up to date 4.More importantly communicating changes/ designs/decisions/ guidelines to the team

5.

Measuring h0ow well the team was doing in terms of progress and quality

6.

As a company/team we would have major issues with the following:

Keeping the team morale during tough deadlines1.Making sure the team fully understood what was being built and how the components would fit together

2.

Convincing the team of the necessity of documenting change and making sure they have the discipline to do that

3.

Communicating the effect of changing requirements on the delivery schedule to the customer while negotiating more favorable payment terms

4.

Ensuring delivery on time with even the minimal acceptable quality5.

The challenge

The StoryI was a new hire in the company, with high hopes that I would be 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 projectManaging requirements, canceling the build, technology decisions

Lessons learned

Whitepaper on Agile implementationWednesday, March 03, 201010:11 PM

Presentations Page 1

Presentations Page 2