The Evolving Agile Development Process at Srijan

Agile SCRUM process at Srijan

Setting up and engaging an Agile Team
Processes and Contracting methodology followed at Srijan

Table of Contents
1. Agile Development Methodology ................................................................................................ 3
1.1 Advantages of an Agile-SCRUM development process ........................................................ 3
2. Constitution of a SCRUM Team .................................................................................................. 4
2.1 Cross-functional team .......................................................................................................... 5
3. Process ...................................................................................................................................... 6
3.1 Analysis and Design Phase .................................................................................................. 6
3.2 UI Design stage ................................................................................................................... 8
3.3 “Sprint 0” / Requirements Sprint ........................................................................................... 9
3.4 Daily SCRUM meetings ....................................................................................................... 9
3.5 Philosophy of DONE-DONE (Definition of DONE) ............................................................. 10
3.6 Sprint-End Demo ................................................................................................................ 11
4. Managing Distributed Teams | Communication Process ........................................................... 12
5. Creating an Agile Engagement ................................................................................................. 13
5.1 Importance of “Product Owner” role ................................................................................... 13
5.2 Trust ................................................................................................................................... 13
5.3 Staffing the Scrum team ..................................................................................................... 13
5.4 Using a Sprint to define an SOW ....................................................................................... 13

THIS DOCUMENT IS CONFIDENTIAL AND PROPRIETARY Page 1 of 14

“Content Management Specialists”

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


Document change log:

Revision Date Notes Author
1.0 27 January First complete version of document Rahul Dewan
2012

1.1 21 February Nature of changes: Major Rahul Dewan
2012
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

1.2 22 February 1. Added the “Agile Engagement Model” heading Rahul Dewan
2012
2. Added various edits/recommendations by Krishnan N
management team





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




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.





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)





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.





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




The Evolving Agile Development Process at Srijan

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (10)

Similar a The Evolving Agile Development Process at Srijan

Similar a The Evolving Agile Development Process at Srijan (20)

Más de Srijan Technologies

Más de Srijan Technologies (20)

Último

Último (20)

The Evolving Agile Development Process at Srijan