Our SCRUMified Development Process

I just thought I'll jot down my thoughts and views of the scrum methodology that we're using right now.

First of all, let me say that we're not using scrum in its purest sense. The methodology we are following is more of a tailored process that is inspired by scrum and other agile methodologies.

The nature of the project, its demands, the time lines and the concept was all highly complex and to be honest quite chaotic at the beginning. We needed to bring some sort of structure to the way we were going to execute the project, especially since we needed to leverage the onsite-offshore model.

The process:
2 week sprint cycles:
- Each sprint is planned upfront, basically setting scope for what we want to achieve.
- The first week is used for requirement definition and high level design.
- The dev team used this time to fix outstanding defects, perform research and develop proof of concepts to support the design.
- The second week is used to develop the defined requirements. This development process embraces the TDD methodology where, the main idea is to get something working first, and then start refactoring and perfecting it.
- The sprint concluded with a demo

Silo development at first
- The initial sprints were all about building individual modules as silo's. They were required to be "aware" of potential integrations but weren't scoped out, and so were not coded.
- It was all about consolidating your own world. Building features and ensuring each module achieved the required functionality

Bringing it all together at the end
- The latter sprints were focused around identifying all integration points and trying to put together these silo modules.

QA on the go
- The QA process kicks off at the end of each sprint. They test and log defects and issues against the previous sprint's code base.
- These defects are triaged and handled in subsequent sprints.
- This QA process is more like a continuous testing process - close to the continuous integration that agile promotes.

Here's my take on what worked and what didn't.

Pros
1. Iterative development: building functionality
- This definitely helped in terms of conquering the highly complex requirements. We were able to break down each requirement into manageable chunks and then take it chunk by chunk.

2. Quick cycles
This enabled the higher management and the dev team actually visualize what we were building. It also ensured that we didn't get lost and stray too far off the project direction.

3. Dependency and milestone documents
From the very beginning we maintained a dependency tracking document complete with milestones. This ensured that any dependency talked about was documented.
It also helped us track when a particular dependency will be available for integration.

Cons
1. Big picture
We lacked a big picture document. Even though there was an architecture document, it didn't really cover the big picture - how all the components "really" integrate with each other, what were the contracts, the entire business flow. I created a document that covered all the interactions and integration points with other modules for my module, but we lacked an overall document.
Due to this limitation, most of us relied on a "project champion", a single person who had the entire vision of the project. This was a huge bottleneck.

2. Iterative development: Rework
Even though this was a pro, I'm also listing this down as a con simply because of the amount of re-work we had to do. Re-work is alright, but when you have such tight deadlines to meet, the re-work should have been avoided.
What really happened was that when a feature was developed and demoed, the business most often came back and proposed changes to it. This is because, they finally were able to visualize what has been in their heads all this time, and they discover improvement points - Fair enough.

What we could have done to alleviate this situation is,
- First create paper prototypes or dummy html prototypes so that the business could visualize the application
- Only when the business has spent a decent amount of time reviewing and improving the look and feel and process flow should the development start.
(Notes for the future :P)
- Alternatively, if the UI and process flow have been signed off by the business, then all changes and enhancements should be considered as change requests and should be handled by the change request process.

3. Documentation
This is what suffered the most. I believe due to the shortness of the sprints we didn't have enough time to produce quality documentation. And this is definitely going to bite us later on, especially during maintenance.

4. Planning
Another drawback of this entire process, and the primary reason why the project isn't going as smoothly as it could, is because of the lack of planning time put upfront. The sprint planning was done in a very haphazard way.

5. Silo Development
Although it was a pro, this proved to be another drawback. I believe that we should have first developed a small prototype, complete with integrations (at some level) so that the basic framework was in place. All additional functionality could have been built on top of this framework.

Superbowl XLII

Patriots all the way.. woohoo.... !!!!

http://myspacetv.com/index.cfm?fuseaction=vids.individual&videoid=26894752