the evolving agile development process at srijan

Agile SCRUM process at Srijan

Setting up and engaging an Agile TeamProcesses and Contracting methodology followed at Srijan

Table of Contents1. Agile Development Methodology ................................................................................................ 3

1.1 Advantages of an Agile-SCRUM development process ........................................................ 32. Constitution of a SCRUM Team .................................................................................................. 4

2.1 Cross-functional team .......................................................................................................... 53. Process ...................................................................................................................................... 6

3.1 Analysis and Design Phase .................................................................................................. 63.2 UI Design stage ................................................................................................................... 83.3 “Sprint 0” / Requirements Sprint ........................................................................................... 93.4 Daily SCRUM meetings ....................................................................................................... 93.5 Philosophy of DONE-DONE (Definition of DONE) ............................................................. 103.6 Sprint-End Demo ................................................................................................................ 11

4. Managing Distributed Teams | Communication Process ........................................................... 125. Creating an Agile Engagement ................................................................................................. 13

5.1 Importance of “Product Owner” role ................................................................................... 135.2 Trust ................................................................................................................................... 135.3 Staffing the Scrum team ..................................................................................................... 135.4 Using a Sprint to define an SOW ....................................................................................... 13

THIS DOCUMENT IS CONFIDENTIAL AND PROPRIETARY of 14

“Content Management Specialists”

Srijan Technologies Pvt Ltd | 303 Solitaire Plaza, MG Road, Gurgaon-122001, IndiaSales : www.srijan.in | +91 124 4849300

http://www.srijan.in/


Document change log:

Revision Date Notes Author

1.0 27 January 2012

First complete version of document Rahul Dewan

1.1 21 February 2012

Nature of changes: Major

1. Added note about “definition of done” to change/evolve based on project specifics

2. Added note on “Sprint-End Demos” about doign demos on Tue-Wed-Thurs and reasoning for it

3. Added a heading for Agile Contracts

4. Re-done the structure of the document

5. Added a note about cross-functional teams

Rahul Dewan

1.2 22 February 2012

1. Added the “Agile Engagement Model” heading

2. Added various edits/recommendations by management team

Rahul Dewan

Krishnan N






1. Agile Development Methodology

Srijan follows a SCRUM and XP development process for delivering projects internally. Here's what it means for you.

1.1 Advantages of an Agile-SCRUM development process

1. Greater Visibility : Nearly every 2 weeks there is a delivery, which is DONE-DONE state (see “Process” below for more details)

2. Deeper client engagement : Product Owner role to be filled by client (supported by a development-side Project / Account Manager doubling up)

3. Higher quality; less waste/repeat work

i. this happens naturally, as features most-required are prioritised well, thus ensuring that there are no/little features built into systems which are not going to be used)

ii. all sprint-end work is DONE-DONE; which means it is tested and ready to be released (please see “Definition of Done” below for more detail

4. Stronger, more communicative teams --> better team morale --> openness to receiving feedback --> more client respect --> happier teams --> better software






2. Constitution of a SCRUM Team

A SCRUM team is made up of the following roles and profiles, representing both the client and the development partners.

Role Responsibility

Product Owner 1. Owns and communicates the product vision

2. Defines and prioritizes features for development sprints and release

3. Adjusts features and priorities for each development sprint, as needed (with inputs from internal stakeholders at client's end)

4. Decides on release dates consisting of sprints

5. Constantly builds the Product Backlog

6. Participates in Stand-up meetings; ideally “daily” (which if is not possible, then an internal management function person – such as an Account/Projects Manager from Srijan facilitates/fills this role for the daily stand-up meetings)

7. Takes demos from the team on the Sprint cycle end-date

8. Accepts (or Rejects) deliverables of each sprint

SCRUM Manager 1. Works closely with Product Owner in managing the Product Backlog (entering User Stories; gathering requirements)

2. Estimates new items entered in Product Backlog from a high level

3. Gathers and details requirements for the upcoming sprint to ensure facilitation of next sprint goals and ensuring high level of team occupancy

4. Commits to next sprint goals

5. Primary person responsible for day-to-day communication with the Product Owner

6. Conducts “daily” stand-up meetings; facilitates conversations among team members for

◦ tasks done since last meeting

◦ plan for today






Role Responsibility

◦ roadblocks? accelerators?

7. Facilitates (sometimes, leads) sprint-end demos

8. Conducts the Sprint learning retrospective meetings among team members

9. Facilitates deployment of Releases on Staging/ Deployment environment

10. Focuses in improving productivity

11. Discusses roadblocks, task complexities, change requests with Product Owner; Re-negotiates Sprint goals with Product Owner, as needed

Development Team 1. Typically about 3-4 people (developers, front-end engineers, QA engineers)

2. Self-organises; Each one asks these questions to each other every day

◦ What was done yesterday?

◦ What will be done today?

◦ Any challenges/roadblocks?

2.1 Cross-functional team

A key aspect of an Agile development team is that such teams necessarily have to be “cross-functional”.

This means that when the team is staffed it has all competencies to handle the project, be it databases, coding (with project relevant technologies), theming, performance, business skills, etc.






3. Process

3.1 Analysis and Design Phase

1. Post-award of the project the Product Owner and SCRUM Master work closely together in defining the Product Backlog with (high-level) User Stories; a sample of user-stories is given below

2. We would setup the site on our Dev and Staging servers on Acquia's Dev Cloud OR on Srijan's environment OR the client's dev-staging environment as the project demands. Some advantages of using the Acquia Dev-Staging environment are:

i. Drupal-ready environment: Fine-tuned hosting environment for Drupal websites; ideally meant for developers; but can host low-traffic sites as well

ii. Launch readiness analysis: offers real-time inputs from SEO, Security, similar standpoints defining launch readiness

iii. Real-time analysis the website code and configuration settings to help maximize performance and security.

iv. Drupal code analysis: logs code modifications to quickly identify and resolve code-level issues, during maintenance

3. Prepare brief architecture document, as needed

4. In case of a UI Design exercise required, that goes on in parallel. An output in the forms of Photoshop files (PSDs) is what is delivered as an input to the Scrum Team.

5. User Stories : we prefer a rule of having user-stories of being less than 2 days of work. If they are bigger, we try and break them down into sub-stories




http://www.acquia.com/products-services/dev-cloud


Proposal for online benchmarking tool for NTEN

Sample “user stories” as they appear in a Product Backlog






3.2 UI Design stage

1. Srijan engages with our design partners www.designroute.in, www.icdindia.com or www.dolka.com for this design process.

2. Clients are free to choose the design company from among Srijan's partners, or choose an agency on their own, based on their internal evaluation

3. This is typically a fixed-cost effort (please see costing table for details)

4. For projects which require UI Design, atleast 1 wireframe sprint needs to be done before development (Sprint1) starts; this can coincide with Sprint “0”

5. This is estimated to be of 2-3 weeks with close interactions with design team

6. A one-page style guide will be created to identify the various header styles, link styles, bullets, etc. This will be utilized in theming and when creating custom WYSIWYG styles.

NOTE: We are happy working with any other design team that the client may choose. Communications and Design is not a core service offering within our portfolio. We're used to working with partners and agencies from all over the world.




http://www.dolka.com/

http://www.icdindia.com/

http://www.designroute.in/



3.3 “Sprint 0” / Requirements Sprint

This is a “planning sprint”.

1. The entire product backlog is analysed by the complete SCRUM team.

2. Atleast 3 Sprints are to defined at this stage.

3. Some key complex tasks are identified at this stage.

4. Sprint-1 is planned with 100% requirements gathered for all user-stories identified, and estimated in detailed

3.4 Daily SCRUM meetings

For each Sprint, a Daily-SCRUM meeting is planned. Here is how a “story-wall”, around which a SCRUM meeting happens, typically looks in the middle of the Sprint.






JIRA Studio and Greenhopper

We also translate all stories, and tasks under each story, into “JIRA Studio”, and use “Greenhopper” for Task Boarding.

3.5 Philosophy of DONE-DONE (Definition of DONE)

Each story when it moves from the column QA/Review to DONE – needs to be seen through the following parameters:

1. Code developed as per defined user-story

2. Code peer reviewed & re-factored

3. Unit Tests written wherever necessary and possible

4. Tested – by engineers/development team

5. Documented (just enough)

6. Verified to be bug-free, and approved by QA team

7. Accepted by the Product Owner (client)

8. Feature is ready to be released into the deployment / production environment

For this to happen the Product Owner – from the client side needs to be deeply involved into the development process, and atleast participate in the project progress several times a week, if not in Daily Stand-up meetings (due to different time-zones).

Definition of “DONE” (Completed)





http://www.atlassian.com/hosted/studio/


Do note that this “definition of Done” may vary based on the client engagement

3.6 Sprint-End Demo

Each sprint is typically 2 weeks long, at the end of which there is a “Sprint-end demo”. The SCRUM Master or another member of the team delivers the demo to the “Product Owner” (client) and to an extended management team within Srijan (Account Manager, CTO, Business Analyst).

We prefer “Sprint-End Demos” to be held on “Tuesday-Wednesday-Thursday” of the demo week agreed. This helps the SCRUM team be better planned and not be working weekends (Sat-Sun) to meet sprint-end goals. The SCRUM Team's objective is to achieve the “definition-of-done” which is not possible if developers are working remotely from their homes trying to meet deadlines.






4. Managing Distributed Teams | Communication Process

1. It is important for the Product Owner (PO) to be in conversation with the SCRUM team, if not daily during the Stand-Up meetings, several times a week. Story board screenshots can be shared on email or Basecamp. The snapshot is also visible on JIRA Studio to which the PO will have complete access.

2. It is equally important for the entire SCRUM team, including the QA engineers to to be part of the Daily-Stand-Up meetings

3. Srijan has a distributed Development and Quality team across its 2 offices in Gurgaon and Dharamshala

4. We conduct our daily stand-up meetings across locations using teleconferencing facility between our offices. We use http://www.vutelepresence.com/ for this.

5. Phone and Skype calls are always handy and encouraged between all team members.




http://www.vutelepresence.com/



5. Creating an Agile Engagement

5.1 Importance of “Product Owner” role

A client side PO, as it can be observed from the above, is an absolutely imperative role in such successful project engagements. The ownership of success and failure is with the PO as much as it is with the Scrum Team.

The Product Owner carries the “vision” of the project, and translates that to the Scrum Team. This is unlike traditional models of software development, where clients are “receivers of software” after a certain functionality is achieved, as defiend in functional specifications document.

The evolution of the project, and deliverables every 2-3 weeks is as much the responsibility of the PO, as it is of the development team.

5.2 Trust

A PO is an integral part of the Scrum Team, and shares the success and failure of sprint-goals and the project.

To get to this stage, the client must be able to evaluate and gain confidence in the team, and thus be clear about engaging with this development team.

The pricing methodology of the development team needs to be agreed upon as well.

5.3 Staffing the Scrum team

Apart from the Scrum Master, the development team needs to have the following:

1. Cross-functional people in the team, who can work on different areas of the project – databases, theming, site building, coding

2. Agile also subscribes that the “entire” development team be part of the project at the Requirement Gathering sprint as well. However, we at Srijan remain open to staffing the team differently, in different phases of the project, if costs do not permit a full-team engagement.

3. While Agile subscribes to the philosophy that the developers must “test for software quality” themselves – this does not work in our experience in India. Therefore, we recommended QA engineers to be part of a Scrum Team. QA does not have to be a 100% function, and therefore can be based on need. We recommend atleast 30% QA Engineer time be built into each Sprint-cycle

5.4 Using a Sprint to define an SOW

In an Agile team engagement, it helps to use the first sprint of the project to create this SOW. During an SOW sprint, the two parties can define the high-level business problem or opportunity, assemble a team, write the beginnings of a product backlog, define roles and responsibilities, and create high-level estimates. The first SOW itself is the output (or sprint goal).






More on creating SOW sprints at: http://www.agilejournal.com/articles/columns/column-articles/6419-five-steps-to-creating-effective-agile-contracts




http://www.agilejournal.com/articles/columns/column-articles/6419-five-steps-to-creating-effective-agile-contracts

http://www.agilejournal.com/articles/columns/column-articles/6419-five-steps-to-creating-effective-agile-contracts


the evolving agile development process at srijan

Technology

agile scrum process

agile teamprocesses

agile contracts4

scrum team

agile development methodology

agile engagement model

sprintend demos

requirements sprint