↑ Grab this Headline Animator

Thursday, March 19, 2009

SCRUM-An agile product development methodology


Scrum is an agile product development methodology. Though the agile product management phenomenon may seem new, Scrum has been around since 1986 and is used by world class organizations such as Microsoft , Google, IBM, Federal Reserve Bank, Yahoo!, Siemens, Sun and a host of smaller companies.

Scrum differs from other agile methodologies as it focuses teams and product over individuals and code. Scrum practitioners laud Scrum’s ability to product ‘hyper productive teams’ and release mature product while still being nimble. I believe, when properly applied, Scrum captures what it means to be a startup that aims to penetrate the most conservative environments; nimble enterprise.

The 41st Parameters adoption of Scrum as its Product Development methodology shows its commitment to Total Quality Product as well as releasing total enterprise product. To showcase and model the adoption, the engineering management team will conduct itself in a Scrum fashion.

Process Visibility

Anyone in the organization can witness an active sprint and some actions associated with Scrum by wandering over to 213. You might see a several people huddled around some cork boards, or a mixture of QA, BA and dev huddled around a single computer. What you are witnessing is the new product development methodology in action.

When we move to the new building there will be a Scrum room with cork board walls for Sprints, broken down by features and tasks. This room will also hold the daily stand-ups and several other events that Scrum introduces. The Scrum/Projects room is a showcase of the current efforts. Using cork board and index cards, any person in the company can get an accurate view of the ongoing tasks as defined by the teams. This is a physical representation of what will be tracked digitally via the dashboards.

This is to introduce a more visible product development organization. Product will still maintain the digital dashboards to which everyone is accustomed, but these extra steps serve to reinforce the active Sprint.


Any new methodology introduces terms, roles and parlance needed to accurately communicate with its practitioners. Scrum is not different. These are the major roles that Scrum introduces.

Scrum Master

Does whatever is needed to keep the team producing! Possibly the most critical role to Scrum, the Scrum Master is NOT a manager, delegator of tasks or someone in charge of people. The Scrum Master removes obstacles, gets coffee, keeps the team on process and overall is the grease and glue of the scrum team.

Product Owner

Responsible for achieving maximum business value by taking all inputs into what should be produced as the product. Inputs include customers, SMEs, end-users, team members and stakeholders.

Product Support and Release Management

While not explicit to Scrum, PS/RM is an important role that we need to ensure enterprise product.

Product support should be the first line of defense to the scrum teams. Product support should deal with all defects and issues coming from the field and should verify and validate those issues. Once defects are identified, they should be added to the backlog via the Product Owner. Product Support should also provide ALL details related to recreating the defect and making it easy to the scrum team to fix the defect.

If a critical defect is detected, the Product Owner should be notified and it should go into the sprint iteration. Each sprint iteration should have an item named ‘Product Support’ and it should be given some predefined hour amount to accommodate critical defects. This is a guessing game at first, but we should get better at the number of hours devoted to product support each iteration.
The Product Owner and Product Support are the keys to making support a success.


Typically 5-10 people, the team builds the product. This team should function as one unit giving their estimates together, working together and sitting together. Scrum works best when everyone is viewed as a team and people and not in their "roles".

Team typically consists of the following skill sets.
• BA
• Dev
• QA
• Other

The ideal Scrum process is custom to your environment as long as the spirit of scrum is honored. This means that we can put signoffs and specific gating points in the process if we so choose. We can define what it means to be “done”. It is just that “done” is what is important.

Also, and this is critical. The team wins or loses. The team succeeds or fails. If PN of FN fails for a particular reason, the whole team fails. This should illustrate that it is not just QA or Dev or Product, but it is in fact a team effort. We should reward as a team, praise as a team and also criticize as a team.

Support the team by respecting the rules and process of Scrum, remove impediments and make their experience and expertise available to the team.

Sprint Timeline

Product Backlog (General)
Will include a variety of items, such as features (enable all users to search by PCPrint), development requirements (refactor risk engine to allow easy updates of algorithms), exploratory work (investigate db move to Oracle) and known bugs.

The Product Backlog is owned and continuously updated by the Product Owner to reflect changes needed or requested by customers, new ideas, competitive moves or technical challenges.

Items in the backlog vary in size and effort. Larger items must be broken down before going into a Sprint Backlog.

What: Iterations of work which take place one after another. Sprints end at a specific date whether the work has been completed or not.
Duration: 1-6 weeks, but consistent in duration. Preferably 3 weeks to 1 calendar month.

Sprint Planning Meeting
When: Beginning of each sprint
Who: Scrum Master, Product Owner, TEAM, Anyone (silent unless specifically engaged)
What: Team, in concert with Product Owner and facilitated by the Scrum Master, choose the items to be worked for the upcoming Sprint. The items are selected in priority order by working down the prioritized Product Backlog list.
Duration: Several hours
Goal: Sprint Backlog is produced and all team members have allocated work for Sprint

Sprint Backlog
When: Artifact from Sprint Planning Meeting
Who: Owned and managed by Product Owner
What: Individual tasks with time estimates representing the work to be completed by the end of the active Sprint.

Daily Standup / Scrum
When: Ideally begins or ends the day.
Who: Scrum Master, Product Owner, TEAM, Anyone (silent unless specifically engaged)
What: Quick meeting each day to discuss activities related to the sprint
Duration: 15 minutes

Sprint Review and Demonstration
When: Immediately following Sprint
Who: Scrum Master, Product Owner, TEAM, Stakeholder, customers, experts and

executives plus anyone else interested
What: A demonstration of the Sprint. This is not a presentation, but a demonstration.
Duration: 30 minutes to several hours
Goal: Demonstrate work from sprint

Sprint Retrospective
When: Following the Sprint Review, ideally immediately (within 1 day)
Who: Scrum Master, Product Owner, TEAM. Should be limited to this group for honest feedback

What: A neutral outsider, possibly another teams Scrum Master, will lead an effort to gather feedback on what works, what does not work, challenges and changes needed to make the next Scrum more successful.
Duration: 30 minutes to several hours
Goal: Honest feedback to improve sprint process

TPQ – Total Product Quality

Scrum is a product development methodology but it is also a framework. Though the authors and agile enthusiasts wish an organization to use all aspects of the defined Scrum, sometimes it is necessary to augment the defined with one’s own necessities.

In our case we need more requirements reviews as well as validation of the testing criteria. This is The 41st Parameters commitment to Total Product Quality and it fits very well within an agile framework.

Below you will find some discreet tasks that can be associated with a specific feature, if needed. Not all features require this level of attention, but the ones that do deserve the care and focus that it takes to release enterprise product.

Submit this story to DotNetKicks

No comments:

Post a Comment

Post your comments/questions/feedback for this Article.


Latest Articles