Friday, March 02, 2012

Learning SCRUM – Part 1

I’m currently running an L10N project as a SCRUM master for my employer.  This is also one of the first agile projects being run at this organization. I’ll save the L10N lessons for another post as this one is, as the title states, about learning SCRUM.

Those of you that know me, know that I haven’t had any formal education when it comes to software development. Everything I know, I taught myself. After working at a few startups, I landed my first corporate job. I am a quick study and I have filled in many gaps along the way: One major gap being Software Development Lifecycles (or SDLC).

In this series I’m going to take you through my journey of being part of a waterfall-based team to a agile organization.

Waterfall

 Some rights reserved by Saad FaruqueThe first way I was taught professional software development was a waterfall methodology. I was working in an organization that just achieved CMMI level 2. We had a mysterious Software Engineering Process Group that made sure the process was being adhered to via weekly audits, tweaked the process as needed, and probably did more than they let the rest of the group know.

When I first learned waterfall, I said to myself: “Oh my, this makes a ton of sense!”; and it did!

I was young and naïve back then. I really did believe that this was the correct way to make software. I mean, it really was a logical way to get the job done.

Lets take a look at what a typical waterfall process looks like:

  1. Requirements: Gather the needs of the client
  2. Design: Figure out how I’m going to meet the requirements
  3. Implementation: Actually implement the design
  4. Testing: Test that what I implemented actually matches the Requirements and Design

What is wrong with that? Well, unless you live the waterfall life for a few cycles, it’s pretty difficult to spot.

I came to realize that:

  1. More often than not, the requirements would always change during design, development, or both. This would impact the business analyst, the developer, and the tester.
  2. Many times, the deliverable didn’t meet the client’s needs because the requirements were incorrectly captured. This was usually noticed immediately after we shipped and resulted in a mad-dash to release a hotfix. This would impact the business analyst, the developer, and the tester.
  3. The aforementioned issues caused product destabilization due to the major changes we would have to make in a very short time period. This would frustrate the customer and make the lives of the account manager and product owner much harder than it needed to be.

All of this sounds like a really big mess, but really, we persevered and delivered what we needed to deliver..

The next post in the series will be about all of the things people tried to do in an effort to avoid change.

Tags: SCRUM,lessons,education,development,Lifecycle,SDLC,waterfall,team,methodology,CMMI,Requirements,Design,Test,destabilization