Anda di halaman 1dari 57

Scrum-Agile - 1

How to conduct the Daily Stand-up / Daily Scrum meeting effectively?


As a scrum master, this is one of your most important daily activities to hold the daily
scrum meeting same time and same place every day. But believe me it is not that easy
as you are thinking. You need to think that how this daily stand up can bring value to
the project. You should always try to create some tools, methods, practices by which
you can bring more and more value in the project. This is a wonderful communication
tool where all the team members are on the same platform to communicate the status.



There are some rules for this meeting:
1. Who should participate - Product Owner, Scrum Master and Team. Other
stakeholders can also join the daily stand up sometimes but they do not have right to
speak. Only the PO, SM and team can speak in the daily stand up.
2. Duration: 15 minutes meeting - if meetings are going beyond 15 minutes then SM
need to find out ways to finish it within a range of 15 min.
3. Agenda of the meeting: Some points that each team member to answer:
1. What did I do since last meeting
2. What I am planning till next meeting
3. Team member to talk about the impediment if they have any.
4. I keep a list of all the action items, issues and follow up items in the Microsoft
Notes under the sprint # page. I review all the open items and ask who is working on
the open items.
5. Distributed Team: If you are executing project in distributed environment, you need
to have a conference number, skype, GoToMeeting tools for the effective daily stand
ups.
6. Burn Down Review: All the team members should update the Agile Management tool
on a daily basis in terms of the effort burn, real status of the task assigned to the team
members. This will be required to review the burn down in the meeting.
7. Weekly Extended Scrum: This is one of the best practice that I always perform. You
need to get more information from the team on a weekly basis. You cannot finish this in
15 minutes. So I schedule a 30 minutes extended meeting on every Monday. Main
agenda of the meeting will be:
1. Create/plan the current weekly goal
Scrum-Agile - 2

2. Review the weekly targets set by the team during the planning
3. Review/Update the agile management tool based on the efforts, task status
8. What I always do is to make my notes every day and for my tracking I do compare the
notes from previous day. This help me as a scrum master to track things better.
9. All the team members reach on time. When we expect the meeting to finish the
meeting in 15 minutes then each and every second is important.
10. This is not a problem solving meeting. If you feel that there is some topic that needs
more discussion then as a scrum master, you make a note of it and discuss it post
scrum and only required participants can stay in that meeting.
Ideally daily stand up should happen in the morning time so that team knows what is
their today's goal but in the offshore-onshore scenario, it happen in the Indian evening
time and US morning time.

At the end of day, the main purpose of the daily stand up is to solve and track the
impediments so that team members can continue working on the engineering activities.
And another one is to check the sprint health whether team is on their track to meet
the commitment. Based on the information collected during the daily stand up, scrum
master can plan his day accordingly.

Scrum-Agile - 3

Scrum Master Roles & Responsibilities
Below is the Scrum alliance definition of the scrum master roles and responsibility at the writing of this
blog:
The ScrumMaster is a facilitative team leader who ensures that the team adheres to its chosen process and
removes blocking issues.
Ensures that the team is fully functional and productive
Enables close cooperation across all roles and functions
Removes barriers
Shields the team from external interferences
Ensures that the process is followed, including issuing invitations to daily scrums, sprint reviews, and sprint
planning
Facilitates the daily scrums

Scrum Master according to me is the most critical role in the project. What I learnt from my experience
is that he should be a senior, mature, qualified person, who can lead the team and turn the
requirements in to the working software. He should be on the floor with the team all the time. When
team members are busy in their engineering task, he should keep on watching everyone and help the
team members in such a way that they deliver the world class software. If you will read the
responsibilities below, you will feel that we are expecting this person to be a superman, who has
multiple skills. But that is what this person should be. Here are my thought on the scrum master roles &
responsibilities:




1. Servant Leader - Scrum master will serve the team and product owner to turn the requirements into the
working software. So as per my experience, scrum master role is a critical role in agile and one should be
very cool, intelligent and knowledgeable while playing this role. Failure and success reasons will asked
by this person. On one end, product owner is responsible for return on investment but execution and
delivery is scrum master responsibilities.
2. Monitoring and Tracking - Team gives the commitment, scrum master has to track the progress and
help the team to achieve the given commitment. Tracking is important on a daily basis so that if needed
proactive measures can be taken well ahead of time. Ultimate goal is to make the sprint successful.
There are various ways or rather I would say that it depends on the individual to create their own way to
make things successful.
Scrum-Agile - 4

3. Reporting & Communication - All the reporting about the progress of the sprint is scrum master
responsibility. Risk, issues, challenges, achievements, success, failure, improvements etc will be reported
by the scrum master to the higher management on both the sides customer and internally.
4. Process check master - SM is responsible for the scrum processes agreed in the project. First of all, SM
creates the scrum rules for the project. Then he has to make sure that each and every process is
implemented in the project. At the end of the sprint, he need to check the agile management tool at the
user story level that each and every user story is completed as per the definition of done.
5. Quality master - during one of the recent discussion, I was asked whether SM is responsible for the
delivered quality in a project, where project has roles like development manager, QA manager, program
manager and the scrum master. If there is a bad quality, who is responsible for the quality. As per me,
primary responsibility lies with scrum master and the development manager. Bad quality is the result of
the process gaps, so as a scrum master you need to find out which process was not followed seriously.
6. Interface between the technical team and the business i.e. product owner. As a scrum master, you have
to play a crucial role between these 2 stakeholders. One is giving commitment at the start of the sprint,
but team has a dependency on the PO to provide the requirements and the clarity on the requirements.
Scrum master many a times need to help team to understand the requirements also. According to me,
one has to go one step forward to help team and do whatever so that team can deliver the working
software's quality, volume as per the commitment.
7. Resolves impediments - scrum master need to be there on the floor all the time with the team. Scrum
master will resolve all the impediments and team should concentrate on the engineering tasks. Then
only team will deliver the working software at the end of the sprint. Some of the example of the
impediments are requirement dependency, wireframe dependency, environments down etc.
8. Resolves conflicts - resolving conflicts between the team members. Agile does not have any room for
negative conflicts. We have limited time and we have to deliver the committed work. You cannot afford
to lose any time otherwise how will you manage the time. So be in touch with the team members so
that as a scrum master you can sense the conflicts early and resolve them. Coordination is critical here. I
have seen people do not coordinate in one team. So you need to talk to them, if they agree to work as a
team then it is fine otherwise put the team members in other team.
9. Lead all the meetings in the project - as a scrum master, you need to lead and guide all the team
members in all the meetings proposed by agile like preplanning meeting, planning, daily scrum, review
and retrospective meetings. So all in all you need to be on top of everything.
10. Shields the team - So the ultimately you have to make sure that team gives at least 6 hours of
engineering productivity. For all the external interference, scrum master should stand in front of the
team.
11. Team formation - This is one of the difficult work. Agile team formation is not an easy task. Specially
when you are working in big teams. I have learnt that if you are forming the team, never ask the team
member that which team does he want to work. He will put himself in a team where you will not require
him or every team member will try to work in some particular team. So as a meta scrum master or
scrum master, you put your thought and off course some logical thinking and go ahead. Everything will
be fine after 2-3 sprints.
12. Estimation - scrum master will coach the team on how to estimate. Further scrum master will also
participate in the estimation during the planning meeting.
13. Performance Appraisal & Feedback - scrum master will provide necessary feedback about the team
members during the appraisal. Delivery unit head or whoever is the responsible person will take care of
the rest. But as scrum master is working with the team on the floor, scrum master will have most of the
information on the individual performance here.
14. Improvement - Find out the ways to improve on the quality, velocity, value to the business. Team is
working on some product since last 1 or 2 years, scrum master need to show the improvements quarter
Scrum-Agile - 5

by quarter. Team will say that they are doing fine. Quality is fine, velocity is fine but scrum master need
to find out some different ways for improvements.

This is just a start. I will keep adding more responsibilities here in this list. But I need your help also here.
Please suggest what all things are missing in the list.

Scrum-Agile - 6

Agile Sprint ETVX
When you are starting any new project, you need to know each and every activities that you are going
to perform in the project. First thing before the project kick off is the sprint 0 activities that I have
discussed in my previous blog on sprint '0' activities. Let's talk about the activities during the sprint.
What I have done is to group the activities based on the phases/milestones like Release planning, pre-
planning meeting etc. Let discuss them one by one:

Release Planning
Before the sprint planning meeting, release planning is a critical meeting where product owner will show
the release backlog to the project team for the first time. This backlog need not be completed. But at a
higher level, product owner should be able to explain his vision about the product to the team. User
stories will keep adding into the backlog even at the later stage. Below table shows the major activities
that should be planned in the release planning meeting.

Phase Input Activities Output
5 to -10 days
prior to kick off
Prioritized
Release Backlog
by Product Owner
Agile team will understand the release goal. This
is the first time when team will have a look at the
release backlog. Before start working on the user
stories, team need to understand the key
objective behind the release.
Understand the business requirements at a
higher level. Understanding the core purpose for
the project and the release.
A prioritized set of user stories that will be
developed in the release.
A coarse estimate for each story.
A date for the release
Draft Release
Backlog

Pre-Planning meeting
One of the main purposes of the pre-planning meeting is to identify the dependencies for the upcoming
sprint. If team can resolve the dependencies in coming 3-5 days then these user stories will be part of
the sprint backlog otherwise these user stories will be dropped for the coming sprints. Team will discuss
the user stories to have an understanding and then estimate the user stories.
Phase Input Activities Output
-5 to -3
days
before the
sprint start
date
Product Owner is
ready with prioritized
user stories (well
above the teams
base velocity)
with acceptance
criteria
All pre-requisite e.g.
data model, UI mock
up, Wireframe
should be available
Sprint Backlog prioritization by
product owner
User stories walk-through by
product owner
Technical complexity explanation by
application architect
Discuss and confirm all pre-
requisite e.g. wireframes,
localization requirements, HTML
dependency, Webops dependency,
database dependency etc.
Wireframe reviewed with UX team
Point sizing of user stories

Draft Sprint Backlog
High level point
sized user stories
Prioritized user
stories
Inter team
dependencies
should be agreed
upon and time lined
Scrum-Agile - 7



Planning Meeting
Planning meeting is the key milestone for the upcoming sprint. If team is able to do the planning
effectively and efficiently then sprint will be completed smoothly. But we have a dependency on the
functionality and technicality details of the requirements.
Phase Input Activities Output
Day 1 of
the sprint
Product Owner is ready
(well above the teams
base velocity) with user
stories with acceptance
criteria
All pre-requisite e.g. data
model, UI mock and
wireframe should be
available

Kick-off meeting
Capacity planning by the scrum
master
User stories query resolution
with product owners, modeling
team, UI design etc.
User story walk-through by
Product owners for newly added
user stories
Vertical slicing of user stories
Determine Sprint defect backlog
target
Point sizing of newly added user
stories and defects
Refine Point sizing of user
stories due to added
complexities/unknowns to data
model/wireframe
Inter team dependencies should
be identified and communicated
Task planning, estimation and
allocation
Agree to sprint commitment
Sprint Backlog with
point sized user
stories
Teams Capacity
Plan
Task and related
Effort Allocation
Team Commitment
List of Sprint risks
and dependencies
All dependent user
stories should be
moved out of Sprint
scope

Sprint Execution/Daily Work
Details of the daily work is given here. Close tracking of the tasks that are planned in the planning
meeting is very important. Daily scrum meetings will give you a chance to talk about the progress and
raise your concerns over the roakblocks, dependencies.

Phase Input Activities Output
Sprint
Execution/Daily
Work


Sprint Day 1
committed user
stories/Sprint
backlog
Scrum Master

Daily Scrum meeting
Burn-down tracking
Roadblock and
dependency resolution
Risk identification and
mitigation plan

Team

Scrum Master

Daily Status to Meta scrum
master
Risk & Issues or any roadblock

Team

Daily scrum meetings
Design Document
Shippable code
Scrum-Agile - 8

Daily scrum meeting
Ongoing/as needed
query resolution /
discussion with PO and
application architect
Collaboration meeting
with onshore team
(technical discussions)
Internal user stories
demo before PO
Acceptance
Preparation of
acceptance schedule
Product owner
acceptance demo

Development Activities

Design discussion &
review
Heuristic review as soon
as UI is done
Code development &
review
JUnit/NUnit tests are
written and executed
Where ever applicable
Deployment to QA
environment
Defect fixing

Testing Activities

Preparation of
acceptance criteria
Test case design
creation (automation +
manual (if needed)) and
review
Test case execution and
automation script review
Logging/verify the
functional defects into
the agile project
management tool.
Unit test cases (If applicable)
Test Design document
Automation script or Manual
Testing result for all the
applicable user stories as per
the PO acceptance scenario
Acceptance Demo to PO as
soon as User Story is complete


Sprint Review
So here is the last day of the sprint. Team need to give a final demo to the customer of the
functionality/features that are just developed in the sprint.


Scrum-Agile - 9

Phase Input Activities Output
Last day of
the sprint
Completed
Sprint
Accepted user
stories
Provide demo to Product Owner and other
stakeholders
PO to share any feedback. Prioritized defect
fixes will happen based on the timeline
available in current sprint, if not consider for
next sprint /moves to product backlog.
Review the accomplishments
Track all requirements completeness
Traceability matrix
Demo output
Updated
Requirements
Traceability
matrix

Sprint Retrospective
How to improve on quality, productivity is something discussed in this meeting.

Phase Input Activities Output
Last day of
the sprint
OR
1
st
week of the
next sprint
Completed / to
be completed
Sprint
Conduct retrospective meeting with team with
focus on What went well, What did not go
well & Action plan for improvements
Prepare action plan for improvement areas
Identify any spike and learning opportunity
Knowledge sharing across scrum teams
Retro Notes
Improvemen
t Plan

These are the high level thoughts that I have put together here. If you need any more details on any of
the activity then please left me a comments below and I will talk to you for the same.

Scrum-Agile - 10

Agile Fix Price Projects
Agile in a fix bid? Is that possible?

This is happening in almost all the service delivery organizations nowadays. I am not sure how and
why companies commit and propose the fix price model in Agile projects. When you do not have
requirements clarity upfront, how and on what basis companies commit the fix price that is
something beyond my imagination. I have been asked by many delivery managers to help the
projects which are in deep RED during the execution.

First of all, let me write my own feelings on this topic. I personally do not agree to provide a solution
in the Fix price/fix bid agile. It is not in alignment of the agile manifesto. At one side, we are saying
that agile team should be self-organized, transparent, honest and on the other side, we are
compelling team to finish task within the set timeframe and cost. Team need to be happy while
working on the project, only then they will be able to deliver the project with very good quality and
creativity.

Here are my thoughts if at all you don't have any option other than the fix bid then following points
should be taken care of while executing the project:


1.

Scope of work or Requirements:
We all know that if requirements are not ready up front then Agile is the best methodology for the
software development. Requirements will evolve with the product development. So we should
always try to convince customer to go for:

Option 1: Time & Material type of the contract.
Option 2: If customer is not willing to sign the T&M contract then second option should be the T&M
with cap
Option 3: If customer does not agree to any of the above 2 options then that means we do not have
any option other than the fix price.

Under option 3, if detailed and stable requirements are available up front then you can do a kind of
Function point estimation and can give a fix price quote. You will be able to manage the show in that
scenario. But what if there are no requirement available at all. What should we do in that case? Keep
on negotiating. There might be some middle way by which you can save your self and deliver the
required product.

At this stage what I am thinking is to propose a one time 2-3 months of requirement phase, where
vendor and customer together dig into the requirement and create the detailed requirements. Once
you get the requirements, from there on you can adopt agile. There are still so many benefits agile
will bring into the development and testing. Customer will still be able to propose changes or
reprioritize things along with the development.

Ultimately, while adopting agile whatever requirements team is receiving need to be concrete,
detailed, stable and accurate. Scrum master need to make sure that these requirements do not
Scrum-Agile - 11

change. If at all they need to be changed, it should be tracked and reported in your sprint summary
report to the higher management on the both side i.e. customer and vendor. This will help the scrum
master during the crisis situation.

2.

Change control board need to be in place like we have in all the waterfall projects. I have already
written on blog on the Agile Change Management. Please have a look at the blog from the following
URL:
http://amitsinghmalik.blogspot.in/2012/07/agile-change-management.html
Requirement changes are welcome but we need to keep a cap on that. A very close change control
board need to be in place all the time.

Apart from that here are some more points on the CCB. I got these points while browsing through
the Google. I do not remember at the moment where from I got these lines. But below 5 points do
not belong to me.
Change Control Board
1.

The client can replace any requirement that the team hasnt yet started working on with one or more
of equal total size and complexity.
2.

Priority shifts are free of charge if the total estimate for the entire work does not change.
3.

New features can be added to the backlog if low-priority items of equal work are removed from the
backlog.
4.

The client may request interim releases at any time and will be charged an agreed-upon time and
materials cost.
5.

If the clients business goals are satisfied early, they may terminate the contract early for a specific
percentage of the remaining unbilled contracted amount.

3.

Involve customer on your day to day operations during the collaboration hours. Usually, in fix price
contract customer try not to be part of the team but try to convince the customer by explaining him
the benefits of him to be part of the team. This will help in the long run because customer will speak
on your behalf most of the times because he already knows the issues/challenges team is facing on
a daily basis. But don't forget that he might not help when you will need him the most.
4.

Risk Management: Very close watch on the project's risk. Scrum masters need to focus on the risk
all the time proactively. Provide an open and transparent platform for the team to raise the
concern/risk immediately. Give them the authority to float the information to everyone as soon as
they sense any risk. This can be done easily in your weekly team meeting. Make sure that you have
Risk as an agenda in your weekly meeting. If you will discuss anything in the meeting, I am sure you
will get what you wanted to achieve in the meeting specially from the team members.
5.

Critical Path: I like this concept very much from waterfall projects. You have to identify the critical
path (may be at high level) and keep a close watch on the critical path. If you are able to complete
the critical path on time. Most probably you will be able to complete the project on time.
6.

As I wrote in the introduction that while implementing Agile in Fix Bid, we are going against the agile
principles.Sprint Demo is one of the most important tool in agile where customer provide his early
feedback. But you know this is where customer suggests lot of requirement changes. Scrum Master
Scrum-Agile - 12

need to track it to save his project cost and time to keep a cap on that too. Each and every change in
the fix bid need to be analyzed for scope, schedule and cost. If any change has a business value, it
should go into the coming sprint backlog despite any impact. Take a help of the change control
board here.
7.

Release: If you have already planned the requirements implementation in form of smaller releases
then you will have some mid point checks on project progress. If not then please do so as soon as
possible. Create the virtual releases in the project, you might not send the code into the production
but at least you can send the release for UAT. Planning at release level and sprint level will help
project to meet the deadline at release level. This is one of the ways by which chances of the project
success will increase. Proactive measures can be then taken after each sprint and releases.

What I would also like to suggest that if we can propose the fix price quote on the release basis. Try
to complete the rough estimate for the 1st release. Once you complete the first release, project will
have data by which you can actually do some kind of the estimates based on the sprints completed
during release one.
8.

Estimation: You can commit something here. That something is available in form of hours. After
doing the high level resource loading, you will get to know the number of developers, testers and
architects for your project. Now calculate the productive hours per sprint wise. Based on this you can
do some mathematics. As a customer, you can commit the available hours to the customer. X
amount of hours worth of work will be delivered to the customer. Now it is up to the customer how
does he want to manage these hours? A kind of staff augmentation project.
9.

Velocity: This is difficult at this stage. According to me, there is no way that you can calculate the
velocity without completing at least 2-3 sprints. Velocity has a dependency on items like team
members, technology, domain, complexity etc. So I would not like to comment anything on this.

I believe my thought will help you in some way or other. Please do provide the feedback so that we
together make the points complete on this topic. I will also try to put some lesson learnt from some of
the team who has already burnt their fingers in similar kind of projects.

Scrum-Agile - 13

Sprint Zero Activities
In one of my recent assignments one of the customer, who earlier wanted to implement the project in
waterfall, now wanted to execute the project in Agile. Reason to adopt agile was non-availability of the
requirements up front. I was asked to check if we could adopt agile in given scenario. I did a quick
assessment and found that it was a perfect fit for the agile implementation. During the assessment, I
had to create the agile implementation road-map for the customer. While preparing the sprint '0'
activities, I thought that sprint '0' was the most critical sprint for any project. If we do not plan it with
greatest focus, it will be very difficult to make changes later on. Sprint '0' is the foundation for any
project. We all know that foundation for anything should be very strong. So let us focus on the sprint '0'
and try to make it a robust one.
Sprint Zero is usually kept for the readiness for the sprint 1 and for all the up coming sprints.
Management has to make things like requirements, infrastructure, people etc. ready for the up coming
sprints. Duration of the sprint zero is something that needs to be decided by the project team and has a
dependency on the procurement of all the required items. So what I did, I broke sprint '0' into 2 sprints.
Sprint 0_1 was for procurement, architecture, product backlog etc and sprint 0_2 was actually a
rehearsal for sprint 1 i.e. POC, where team actually done the coding and testing to check if everything is
as per the plan.

Sprint Zero is also called as Iteration Zero. Activities listed below will make the team ready for the sprint
1. It is a kind of the preparation for kick off.
Product Backlog/Requirement: These are the product requirements that team will be building in
the coming sprints. Product owner and Technical Architect need to work closely here to prepare the
backlog for the team. Product owner should be ready for the release plan so that team can visualize
the PO's vision from the product perspective.
Product Onwer's Vision on the product
Product Owner should be ready with the Release Plan
Preparation for sprint Planning
Requirements freeze at least for sprint 1 and 2
Prioritization for sprint 1 & 2
Decision on Definition of Done
Scrum-Agile - 14

Infrastructure readiness: Without the infrastructure, team will not be able to progress on anything.
So a high dependency on the systems, software, licenses, environments etc. Delivery Manager need
to work with the infra stakeholder to get these things done.
Network requirement
Connectivity if there are more than 1 location is involved
Minimum environments readiness; to start with team at least need dev and QA
environments
System readiness with all the software installed
Logistic requirements like phone, video conference etc
All the tools up and running
Design/Architecture: High level architecture management plan that talks about the technical
architecture of the future product from the technical architect. Next step will be to convert the
architect plan into the architecture solution i.e. the coding platform for the developers.
High Level Base architecture should be ready
Decision on the coding framework and make it ready for the team
Decision on the tooling & IDE
Coding standards & processes
Review Process
Automation Testing framework readiness
Team Readiness: Creation of the team as per the resourcing plan. You do not need the entire team
on day 1 of sprint 0. But you have to make the team ready with the training, tools, systems
configured for them for coming sprint.
People hiring
Team ramp up
R&R from each role
Each developer and tester will also make their system ready with all the required
software
POC: Developers and tester should make their self ready for the sprint 1 with some kind of POC
where they will actually code and test. This exercise is very important so that they can make the
sprint productive. From sprint 1 onwards team is start delivering the working software.
Training: Training will make team ready for the development/testing. These trainings are critical to
project success. I would also recommend that these trainings should be recorded for the future use.
Recorded sessions will be utilized during the ramp up period for the new associates.
Domain
Technical
Architecture
Development Framework and Process
Testing Framework and Process
Tools
Project Management Plan: Comprehensive project management plan will be the bible for the
project team members as far as project processes are concerned. Agile PMP document is different
than the traditional PMP. Here critical items are the test and defect management plan. You should
clearly write down the process of testing in the project. What kind of testing?; which environment
will used for which testing?; how many types of defects?; how will team fix the defects?; all these
questions should be answered by the test strategy.
Agile Management Plan
1. ETVX
2. Each and every step for implementation; basically an agile Bible
Scrum-Agile - 15

Test Management Plan
1. Test Strategy
2. Test Plans
3. Templates
4. Performance Testing
5. Security
Defect Management Plan
Continuous Integration Process
Risk Register
Roles & Responsibility of each role like scrum master, project manager, agile coach,
delivery manager, developer, QA, sponsor etc
Other Plans
Well, I feel this should be good checklist to start with. However, apart from the checklist, I would also
recommend to have a daily scrum call right from the day 1 of the sprint '0'. There should be an action
items list that should flow on a daily basis with the clear ownership for each of the activities listed
above. Having a war room will be a great idea during this time because this is a planning period where
lots of things gets clear while having the brainstorming within the war room. Once you start, things will
shape up automatically as you will proceed further. All the best!!

Scrum-Agile - 16

Agile Coach Roles & Responsibility

When you are starting a new project in Agile and team does not have agile knowledge. It is one of the
scenario, where you need an agile coach for the project. Project sponsor should involve agile coach in
the project as early stage as possible. Agile coach will set the ground rules and regulations and will
create a winning strategy for the project from the initial phase of the project itself. This is a critical role
that needs to be played by a senior experienced person, who has executed projects on floor. Theoretical
knowledge will not work here.


I have been playing this role in two of my previous projects. I found coach role very exciting and
challenging. Coach, Train, mentor people and make them ready to play the game on the ground is not
that easy. There are various challenges while playing this role. I think "Challenges while transitioning
into Agile" will be a topic for the next blog. Right now, I am posting the roles and responsibility of the
agile coach. Help me to make this list complete. I am just posting the first iteration and will keep on
adding the more bullet points under the list.

Agile Coach Role & Responsibility

1. Facilitator: Facilitate the team with the knowledge so that team can start the project.
2. Trainer: Provide training to the team on the agile process; training will continue all the time during
the project execution on agile and continuous improvement on velocity, quality, processes etc.
3. Help in preparing the overall planning of the project that means he will work as a consultant. He
will provide various ideas, suggestions, strategies.
4. Make sure that team is following agile processes in each sprint at user story level as per the
Definition of Done (DoD); However this is the responsibility of the Process Check Master but if
project does not have a role of process check master, this activity should be handled by the agile
coach.
5. Help team to answer all the questions on the agile process during the project execution; that
means agile coach need to be on the ground so that he can answer the questions immediately.
6. Identify project risks and raise them immediately
Scrum-Agile - 17

7. Make the winning strategy according to the ground conditions
8. Mentor: Focusing on people and Continuous Improvement all the time; provide team a platform
for improvement not only during the retro but all the time. Create a safe environment for healthy
conflict and meaningful collaboration.
9. Identify process issues and improve them
10. Help product owner to write user stories
11. Help team on the estimating of the user stories and prepare them for the same
12. Help scrum master to plan meetings like
1. preplanning,
2. planning,
3. daily scrum,
4. Review & Retrospective
13. Provide capacity calculator template for the team
14. Provide the common tasking codes for the team for better tracking on technical front

As I wrote above, this is not a complete list but should be sufficient to start with. Every project has
different dynamics and this list can be customized according to the need.

Scrum-Agile - 18

Transition Steps - Version 2.0
In my last blog on transition from waterfall to Agile, I wrote some details to adopt agile. Now I
am writing more steps, when you have chosen the project, which will be a kind of pilot project.
Following are the steps, that one has to follow in any project while transitioning to Agile.
1. Identify Agile Coach: According to me, this should be the first step. You need to identify
an agile coach, who will help you to dive into the agile concepts for initial couple of sprints.
He will also help the team to train with Agile concepts.
2. Get Agile Knowledge
1. Training: This is the first step for the team. Team should be well versed with the
agile concepts. For that you need provide them at least 8 hours of training. Training
should be a instructor led class training. After completing this 8 hours of training,
team can go through some recorded sessions and read some agile books.
2. Training should focus on the rehearsal of the daily scrum and estimation
methodology.
3. Agile Books: Buy some agile books for the team. As I wrote in another blog. This is
very important to gain more knowledge on agile. More knowledge team will have,
more easy will be to implement the Agile.
4. Change the mindset: The biggest challenge is to change the people's mindset. But
as an agile coach, you have a target to change team's mindset as soon as possible .
PM, Tech Lead will try to keep their powers with them. However, we have to set the
people free so that they can create more value in the project. Freedom, trust,
honesty, matured team members are the pillars in the agile transition.
5. Print Some agile posters and paste around the wall in the war room or on the floor
where team is sitting. This will help to create great ambiance for the team.
3. Define Rules & Guidelines: Now, agile coach has to create the rules and guidelines
document for the agile execution. This document will help entire team including product
owner, scrum master, application architect and team to proceed with agile execution.
Document will contain the what, how of the agile. This should be a working document that
can be updated regularly by scrum master and agile coach.
When I created this document, team was not sure why was I creating that document. But I
knew the important of that document. Once finalized, document immediately became a hit
within the team and at account level. Because this document had almost all the details for all
the stakeholders including acceptance criteria, test management plan, defect management plan
etc. This document can also be part of the project management plan.
4. Create Inventory: Following artifacts will be created before we kick off the first sprint.
1. Selection of the agile project management tool like Rally, JIRA etc
2. Selection of the automation testing tool like QTP, RFT, Selenium etc - cannot
survive without it.
3. Code development and deployment procedure
4. Identify all the environments that team is going to use
5. Capacity Calculator
6. Common task codes
7. Analysis and Design template
8. Definition of Done
9. Product Backlog Creation
10. Prioritized sprint backlog
11. Estimation methodology like Planning Poker
Scrum-Agile - 19

5. Creating Product Backlog/Home Work for the sprint 1: Before going to the pre-
planning meeting, scrum master, application architect and product owner need to sit
together and make the sprint backlog ready for the team.
6. Estimation: As per my experience, initially team members face difficulty to understand
the concept of the story points. Most of them do not understand the concepts of story
points and its complexity. Team members always feel comfortable estimation in terms of
efforts. What I do for initial couple of sprints till the time project has its own standards. I
give them some relationship of story points and efforts to complete 1 story points of work.
How many hours will be a right fit against 1 story points that you can take a help from
team members. You can ask team members that how much time it takes to complete the
smallest activity in the project. That should be your 0.25 SP of work. If you can multiply it
by 4, you will get around 1 SP relationship in terms of hours.
When team is estimating any work, that includes every activity before UAT. That means
analysis, design, coding, unit testing, test cases creation, execution, defect fixing, defect
verification and all kind of reviews should be included in your estimates.
Note: Remember this is just to kick off the sprint 1. After a couple of sprint, team should be able
to understand the complexity of the user stories and then they should be able to estimate the
stories without worry about the efforts.
7. Preplanning Meeting: Now entire team is there in one room to discuss all the user
stories one by one & to estimate each story. The main agenda of the preplanning meeting
is to estimate the user stories and to identify the dependencies/preconditions for the
stories that team is going to target in the coming sprint. After this meeting, team will have
prioritized and estimated sprint backlog. This meeting will be scheduled around -3 to -4
days ahead in case of the 2 weeks sprint and -5 to -6 days in case of 4 weeks of sprints.
Question: How much work to pick in the sprint?
I would recommend that you under commit the work in the initial couple of sprints. As soon as
you complete the committed work, you can ask your product owner to pick another set of user
stories.
8. Planning Meeting: Duration of the preplanning and planning meeting should be 2 hours
each for a 2 weeks sprint. Main agenda of Planning meeting is to :
1. Re-evaluate the newly added user stories from preplanning meeting
2. Assign user stories to the developers and QA
3. Tasking the user stories and efforts against each task. I would like to give one
suggestion here. When you are putting efforts against each task. You should not
keep the story points in your mind while doing the tasking. That may affect the
efforts. Just keep on filling the efforts on actual basis. That is how you will get the
variations for analysis after some sprints.
9. Testing: There are some difference in the waterfall and agile projects testing. Let's talk
them one by one:
1. Writing test cases: Testers should write the test scenario rather than detailed test
cases. Remember, agile manifesto also says that we need to have minimum
documentation. No need to write each and every small common sense test cases.
We should write the business test scenarios only.
2. Automation: continuous integration is the core pillar of the agile projects. As soon
as a user story is completed. It should be tested with the overall software that is
developed so far. You have to test the entire functionality with the newly added
Scrum-Agile - 20

piece of code. So you have to automate your testing, otherwise if you will think about
the manual testing, you will be killed. Try to automate all kind of testing in the project
right from unit testing till the integration testing.
3. Developers and QA collaboration is one of the pillars of the agile success. They
need to develop and test the code together.
10. Daily Scrum: This is where team members will face a lot of pressure initially. But as a
coach, SM, you need to bring every team member on a comfort level so that they become
transparent, honest and proactive in order to raise the concern/issues/risks.
11. Daily collaboration meetings: Team need to have around 2 hours for collaboration on a
daily basis. They can use this platform for:
1. Clarification of the requirements from PO
2. Dev and QA will have a detailed discussion of the requirements before starting the
work on the story
3. Dev will discuss the analysis and design
4. QA will get the test scenario reviewed by PO
5. Review demo of the work
12. Sprint Review: At the end of the sprint, team will give demo to the work that they have
just developed. Senior management, sponsors, end users will also attend these demo and
see how their product is growing sprint by sprint. One of the advantage of the agile is to
have minimum surprises. If stakeholders feels that this is not what they wanted, they can
immediately provide their feedback and things can be corrected in the next sprint

Scrum-Agile - 21

Sprint Process Flow
I wanted to create a simpler sprint process flow diagram for my training purpose. We all are seeing
the mountain goat picture since a long time. And may be the most widely used picture across the
globe. I, myself is using that picture to explain the sprint. Below is the picture that I have created
which not only talks about the various activities that we use in the project but also includes the owner
of those activities and output artifacts from each stage.

Scrum-Agile - 22





Scrum-Agile - 23

Below picture represents another view of the above process flow. The first box represents the major
activities in the agile projects. In front of each box, there are activities within those activities, who all
should present in the meeting and what is the outcome of that exercise?



Scrum-Agile - 24



I hope this representation will help the people who are new in agile world. I tried to make things
simple here. Please let me know if I am able to succeed in my thoughts

Scrum-Agile - 25

Agile Testing

Testing approach in Agile projects and in traditional waterfall projects is different. We were struggling in
one of our Agile project once upon a time. That time, we did not know, what all things should we do in
testing while executing the project using scrum? We continued learning things on our own and kept our
focus on the Quality of the deliverable all the time. Over the period of time, we got good hold on the
testing practices in Agile project. But there still some questions those are debatable and should be
customized based on the project nature.

Some of the questions I had were:
1. Developer Vs QA ratio
2. How much to automate?
3. Should we log the internal (exploratory) defects?
4. What should be the frequency of the regression and sanity suite run?

The different types of testing that will be carried out during the project, and each plays a critical role in
the projects ultimate success. The testing strategy includes:











Unit Testing
This is the first level of testing that is done in any software development project. Developer complete
with his coding and then does the unit testing in his local/development environment. Purpose of unit
Scrum-Agile - 26

testing is to make sure that individual components are working as per the requirements. Remember we
are not targeting the integration testing here.

As Agile has a limited time, we have to automate everything coming in our ways to save time in future.
That is the reason, automated unit testing is recommended. JUnit for Java should be created for all the
test cases wherever possible. Another important thing is the testing coverage, As per the definition of
done there should be a target coverage % of unit testing test cases. This unit testing coverage should
also present in the Definition of Done.

There are some tools available in the market like EMMA, which measure the % coverage.

Functional Testing
Now is the time to test all the individual components together. This is where a tester/QA will fold
his/her sleeves and will be there on the floor to test the developers code in QA environment. The main
purpose of the functional testing is check if one use case is working properly as per the requirement.

There is a need to test chains of transactions that flow together and which reflects important business
processes and scenarios. Scenario testing will be performed for each module separately as and when the
development or customization is over for that module. During subsequent integration testing these
small scenarios can be used to build larger end-to-end scenarios.

There could be 2 types of functional testing i.e. Manual and Automation testing. As the name suggest,
manual testing is something when a tester jumps on the keyboard and test the functionality manually if
everything is working fine. Automation testing is done with the help of the tools like QTP, RFT etc. Here
tester does the coding to test the scenarios with the help of the tool. Primarily, this code becomes part
of the regression suite. Regression suite is run in the coming sprints to check that the existing
functionality is not broken by the modification of the current sprint coding.

Regression Testing
As soon as sprints are complete, automated and manual test cases are added into the regression test
suite. Sometimes, bigger projects keep 2 automation suite i.e. regression and sanity test suite. Sanity
suite is around 10% of the regression suite. Usually, sanity suite is run on a daily basis and regression
suite is run twice in a sprint. A high focus should be given on the regression and sanity defects. As soon
Scrum-Agile - 27

as, any defect is detected, it should be assigned to the particular scrum team. Defect status should be
floated as a weekly status report. Apart from that, sanity and regression suite run status should also be
floated as soon as suite execution is complete with the pass/fail status.

When project is large, a separate QA team is formed to maintain the regression/sanity suite. In my last
project, we had a separate testing team apart from the development teams, who had dev + QA. My
development team was using scrum and QA team was using Kanban. Main responsibility of the QA team
was to:
maintain and run the regression and sanity suite.
to add more and more acceptance scenario to the regression suite
to complete the pre-conditions for the development QA teams based on the pre-planning meeting
to follow up on the open regression defects so that they can be closed asap
and to fill the development team's QA capacity shortfall if needed due to some emergency.

I do not think that you need this team from day one. We created this team when we sensed that we
were not able to manage the regression suite and needed somebody full time to manage the team.
After the creation of this team, our defect management and running of regression suite became smooth.
We got several benefits out of this team.

Regression Testing will be done before making any release to a controlled environment to ensure:
That the application works as specified even after the changes/additions/modification were made
to it
The original functionality continues to work as specified even after
changes/additions/modification to the software application
The changes/additions/modification to the software application have not introduced any new
bugs

System Integration Testing
System Integration Testing (S.I.T.) is the testing of the sub-systems, as a whole, to ensure that they work
as a system. Final integration testing is accomplished through the execution of predefined business
flows, or scenarios, that emulate how the system will run. Integration Testing involves cross-functional
integration points and end-to-end business scenarios. This also includes testing of all peripheral devices
(like scanner, digicam etc) that are integrated with the system.

Non-Functional Requirement Testing
Scrum-Agile - 28

System testing consists of technical tests and performance related tests. The technical tests aim to
validate that the technical components of the production environment are working properly. These tests
include validating the system for:
Response time
Fail-over Test
Availability Test
Disaster Recovery Test
Backup and Restore Test
System Administration Test
Security Test
Performance/ Load Test

User Acceptance Testing
User Acceptance Testing is the final step before rolling out the application. This will be conducted by the
selected end users, who will be using the applications test the application before accepting the
application.

Usually, business users who provide the requirements to the development team does the UAT. They
have a separate environment to check if everything is working fine.

Scrum-Agile - 29

Tools used throughout the SDLC

I thought to prepare this list of tools, used throughout the SDLC many a times, but could not make it
earlier. Now when I was struggling myself in one of the assignment, where I had to suggest some of the
development tools. I thought, this is the time. I started writing it down. I also thought that if I write all
the tools then I will end up with a really long list. So here is the list of tools that are most widely used.
One more point, this list can never be frozen. It should be a working list which might need an update
every quarter or so. So whoever is reading this list. Please suggest me to improve the list. And I will keep
on updating it for the larger group. So here is the list that you can refer to:



Requirement Tools: with the help of these tools, requirements of the system will be
IBM Requisite Pro - I believe this is the most widely used tool.
Contour - J2EE-based requirements management tool by Jama Software.
Cradle - Systems engineering and requirements management tool by 3SL.
Dimensions RM - Requirements Management Tool by Serena Software.
Concerto - Concerto is a software project and requirements management platform by
Parasoft.
Analyst Pro - Software Requirements Tool by Goda Software
Design Tools
IBM Rational Rose
MS Visio
MS Office
Agro UML
Magic Draw
Scrum-Agile - 30

Rational Software Architect (IBM)
Project Management tools
MS Project
MS Office
Customized Project Management tracking tools - for metrics
Configuration Management Tools
IBM ClearCase
VSS
SVN
Java development tools (IDE)
IBM's VisualAge for Java development
Borland's Jbuilder for Java development
Eclipse is from IBM
Nebeans is from Sun/oracle
Spring source tool (STS)
IntelliJ from Idea
Rational Software Architect (IBM)
Code Review Tools
Code Collaborator
Cast
Eclipse
Sonar
Microsoft development tools (IDE)
Visual Studio
Application Servers
Jboss
Glassfish (Open Source)
Apache Geronimo Applications Server
IBM - WebSphere Application Server
BEA WebLogic Server
Web server
Apache Web Server (65% applications are hosted on apache)
Internet Information Server (IIS) - 15% applications are hosted on IIS.
Nginx from Nginx hosts around 12% of applications.
GWS from Google (5%)
Zeus Web Server
iPlanet Web Server
Roxen Web Server
Jigsaw
JRun
Sambar Server
Sun Java System Web Server
Portal Server
Websphere portal server
Oracle WebCenter
Adobe LifeCycle
Middleware tools
Mule ESB
Scrum-Agile - 31

IBM Tivoli
SOA Based tools
SalesForce
Amazon Web Services (AWS)
Windows Azure
Google
BPM Modeling tools
JBPM
Activity
WPS Websphere process server
Build Tools
Apache Maven is the build engine
Rake
Ant +Ivy
Gradle
Gant
Buildr
Agile Project Management Tools
Rally
Jira
Redmine
Extreme Planner
VersionOne
TargetProcess
AgileTrack
Bamboo
Testing Tools
QTP
RFT
Test Manager
Selenium
Concordian
JMEter
Jprofiler
Jprobe
Loadrunner
Defect Tracking Tools
ClearQuest
Rally - Online service for agile project management, requirements and test case
management, and defect tracking. Consulting for agile project management. Located in
Boulder, Colorado, USA
Jira
BugZilla
Continuous Integration
Hudson
Cruise Control
TFS (MS First Sight)
Hot deployments
Scrum-Agile - 32

JRebel
Collaboration tools
Zipline,
Basecamp
Sharepoint

Scrum-Agile - 33

Lesson Learnt / Retrospective Meeting Acitvities

Lesson learnt is the key activity in the software development. Continuous improvement is something
that every product/project company is focusing nowadays. Agile provides one important pillar i.e.
retrospective meeting by which team is able to grow and mature over a period of time. In my last
project, we tried many new things in retrospective meetings. Every quarter, we used give a new
theme to the team like productivity, quality, efficiency etc. We used to ask to the team members on
these parameters for improvement. Over the period of time, we were able to improve on many things
in the project. As a manager/ scrum master, you just need ask the questions from the team on the
following areas:



Following are the areas that we should touch upon during lesson learnt:
1. Communication: How to improve the communication, collaboration between the distributed teams?
a. Onshore offshore communication
b. Offshore offshore communication
c. Communication between QA Vs Dev is very important

2. Planning
a. Any learning/issues/challenges from overall planning perspective?
b. Are we taking adequate time for the planning meeting?
Scrum-Agile - 34

c. Are we scheduling pre-planning meeting?
d. Are we able to close the planning meeting on day 1 or do we have open items for the next day also
where we should start the development?
e. Are the entire pre-requisite ready for the stories that will be worked out by the team during this
sprint?

3. Requirements
a. Were all the requirements and pre-conditions available at the time of planning meeting?
b. Did we take care of the NFR (response time, performance, peak load etc) beforehand?
c. Were the entire wireframes ready before the planning meeting?
d. Changes in the requirements and their reasons
e. Requirement understanding
f. Query Tracking
g. BA Availability
h. Definition of Done Clarity/Acceptance Criteria
i. Availability of the Traceability matrix

4. Design
a. How many changes did we receive in the project architecture during the execution?
b. Architecture Understanding
c. Impact analysis of the design change

5. Quality
a. Testing overall? JUnit + Automation?
b. How was the outcome of the UAT and performance testing? Did we plan both of them well ahead of
time before system goes live?
c. How was the change management during UAT + SIT?
d. How was the defect management process?
Scrum-Agile - 35

e. Was there an adequate time given to the SIT and functional testing?
f. Were the sufficient people available in the team?
g. Was the delivered quality up to the mark from team perspective?

6. Team Management
a. Team motivation what did we do to motivate people?
b. Knowledge dependency on a single person?

7. Risk Management
a. How were we doing the risk management? Any learning? Did we miss any risk that we could not
identify and occurred during the execution?

8. Customer Involvement
a. Was PO available whenever team needed him/her?
b. Query response time
c. Was the completed work accepted on time
d. Availability for the demo

9. Infrastructure
a. Were there sufficient and adequate machines available?
b. Did we have the entire environment available for the team?

10. Operational Learning + Improvement areas

11. Tools and Training
a. Skill level of the people in terms of domain, technical and Agile?
b. How did we plan training in the team?
c. How did project take care of the ramp up/down plan?
Scrum-Agile - 36

d. Did we have adequate tools in the project? If we are given an option what all tools will you suggest
in the project?

12. Process
a. Methodology comfort level. Did we plan any agile training for the entire team?
b. Internal processes (CMMi + others)
c. Review Process

Scrum-Agile - 37

Product Development Vs Project Development

I have been working in a service IT company for more than 10 years. All these times I was working on
some kind of projects. In my last assignment, I got an opportunity to work on a product development.
This is a different mind-set all together. In 2010, I faced one interview with adobe. There were around 3-
4 rounds and I was able to crack all of them. But in last interview, interviewer asked me on question
related to the quality of the product. As per my knowledge and experience of service industry, I tried my
level best but unfortunately. I could not clear that interview. But today, after working for 2 years in a
product based company. If I look back and remember that question. I did not answer that question in
the way a product company was expecting it to be. Answer was correct as per the project based
company.

Now when, I have worked in both kinds of companies. I thought to write down my thinking about the
product development and project management. Ultimately in both the cases, we are developing
software. Primarily the difference lies in the peoples mind-set. Otherwise most of the things are
common.



Product Development
Product is developed for generating revenue and profit for some general functionality to serve to a
larger audience. But initially this is an investment. End users come into the picture once there is a sale of
the product into the market.
Product development keeps the SME (specialist) from almost all the fields. Highly paid people will be
working on the product.
Domain is given high priority. People are supposed to have a good amount of domain understanding.
Product Manager/Owner is the key person. He has to keep an eye on the competitors product
functionality, UI, revenue, deals etc.
If there is no end user for the product during the development. Product owner has to collect some
information/feedback from early adopter or end user in some forum. One of the examples is to arrange
a summit in the market and call all the possible end customers and give them a high level demo of the
critical features and functionality. Take their feedback for the product improvement.
Quality is the most important thing. There will be large testing team allocated to the product
development. Most of the time, automated testing should also be in place. Quality, look and feel, user
experience should be superior to the competitors product.
Delivery Excellence continuous improvement on the quality, productivity etc.
Product owner collaboration is required all the time. However, in project development they just give the
requirements. High collaboration is not required in project development.
Scrum-Agile - 38

More freedom in the team member in the product development. There are no rules in the product
development. You just have to develop a much better product with highly motivated team. However, in
project development team has to stick to the required quality standards and team is supposed to
whatever is written in the plan.
People are given more priority because this is long term assignment. People stay in the project for
longer duration than projects. Projects are created by developing a product. So they have a finite life.
How can team give more value to the end customers is the focus all the time. This product will serve at
more than one customer. However, project is usually for just one customer.
Most of the product development happens in house. Product development usually are not outsourced.


Project Development
In project development, project manager has to finish the project based on the given requirements.
However, in product development, product manager has to complete the requirements better than the
competitor products. Time is also very important in the product development. Sooner you reach the
market better will be the revenue and margin. It is all about competition.
Project manager wants to finish the project as soon as possible and would like to start the new one.
However, product development usually goes for a longer duration.
People do not have that much importance, especially from the service oriented company; they deploy
the people whoever is available on the bench. Skills do not matter that much. People are not specialist
but they are generalist.
Project development is outsourced most of the times.
Project is developed particularly for one customer only.
Project development exist usually because of the some problem that customer is facing at the moment
and it is usually for some in house operations
Project managers are responsible for successful delivery of the project with limited resources like scope,
schedule and money. They just have to complete the project by all permutation and combination.
Scope for the project is limited. However, scope for the product development is modified on the real
time basis according the market conditions. So the market conditions, competitors are the most
important factors in the product development.

Scrum-Agile - 39

7 Steps to meet the milestone in Agile Project!!

No matter what development methodology you implement in the project, you will find yourself
multiple times in situations where you will be missing deadline/milestone. As a project manager you
should be on your toes all the times. This article is primarily written by keeping agile in the mind.
However, these are the best practices, which can also be applied in waterfall projects also.

I have also been into that situation in one of my previous projects. We missed one important
milestone. Why did we miss that? It was a different story all together, team was not even aware of
the milestone from the product owner side. Certain features of a product had to be completed by
certain time. Team was not able to complete it because they did not know what to complete by what
time. I was leading this product development. I decided that time that I should write something on
this for my blog.
Before jumping directly to the solution, let us try to find out some of the reasons for not meeting the
milestones:
Absence of the vision from product owner
Frequent requirement changes
Technical and domain complexity
Quality of the deliverable is not up to the required standard
Dependency
Sudden absence of the key people in the sprint

Achieving the milestone and a certain amount of the functionality volume is the most important thing
for a project/product development from the business point of view. I thought that the following review
models will ensure that project team will be able to achieve the target milestones:

This is a top down approach. I am starting with the top and then going down level one by one.

1. Product Level Review
It was a missing part in my case. Had the product owner communicated the milestone map to the
team, team would have been able to achieve the goal.
Product owners clearly communicate the project and milestone goals to the entire team. Product
owner takes the team agreement on the milestone. Define success criteria for the
Scrum-Agile - 40

sprint/milestone/project with the help of the Definition of Done (DoD). Identify all the pre-requisite of
the sprint backlog during the planning/pre-planning meeting. This will also increase the chances of
the sprint success as well as the milestone success.

2. Milestone Level Review
Product owner and team along with the senior management should have regular milestone status
meetings after every milestone. This status will report the progress against the end date of the
milestone on the basis of schedule, cost and quality to avoid the last minutes surprises.

3. Sprint Management Review
Project should provide a regular senior management review status to the management after every
sprint. This sprint review meeting will contain the outcome of the sprint that will include the velocity
(committed, completed and accepted user stories), Risks, Challenges and Issues faced in the
current sprint, quality status, defect management, agreed metrics, retrospective notes (top 3 from
each team) from the sprint etc.

4. Quality Management Review
There should be a monthly independent quality review based on the CMMi quality standards and
guidelines. Outcome of the review will be shared with all the stakeholders to ensure that everybody
is on the same page.

5. Regular measurement of the project health
Meta scrum master and scrum master should closely control & monitor the project. SM should
measure of the project health regularly from the initiation sprints onwards. Following metrics could
be considered during the development for measuring the progress after every sprint.
a. Burn Down Chart on a daily basis
b. Change log
c. Weekly deployment plan from dev & QA
d. Risk and issues
e. Velocity (committed, completed and accepted)
f. Quality Status (defect density, defect leakage (functional + regression) etc)
g. Leave details
Scrum-Agile - 41

h. Utilization etc
6. Weekly Deployment Report
Scrum Master will share a weekly deployment goal status report to meta scrum master with the
weekly deployment targets. Weekly targets are very important in order meet the sprint goals.
Appropriate preventive and corrective action items can be taken by the scrum master if needed
based on the weekly target to meet the milestone.
7. Daily Sprint Review
Product owner, Scrum Master and the team will discuss the progress on a daily basis in the daily
scrum meetings. This activity itself is a major contributor in the milestone and project success.
Various meetings, like daily scrum, sprint demo, sprint retrospective, sprint review meeting and
milestone review meeting, will be scheduled for better tracking.

Better Execution from scrum master perspective:


You have to focus on the critical path all the time
You need to plan at the beginning of the sprint including schedule. One of the way is to have a
weekly deployment plan.
Entire project team should attend the release planning meeting

These are just the highlighters what you can plan in the project. However, there will be customized
solution depending on the problem in the project sprint by sprint. So you will have to keep investing
time to find better ways of project management by discussing new innovative ideas with the team.
Sometimes, there will be such incidents in the project where in you might have to work extra to meet
the milestone. But that is something which I personally do not like. But sometimes you do not have
an option. These are some of them which I have practiced. Please let me know more ways by which
we can make this content better

Scrum-Agile - 42

How to transition from waterfall to Agile?

This is a big dream. Right! This is not an engineering project, where we can train people and start
producing the software from the first day itself. This is a philosophy. This is an art. This is a change
of mind set of the people who will be adopting agile. Before changing the companys vision, we need
to think about the people working in the company. Their buy-in is more important than anything else.
If we follow certain steps and have patience, I am sure everyone around you will have a smile on
their face. Lets talk about some of the steps that a company can follow while transitioning into an
agile organization.

1. Vision/Roadmap
Vision, mission and objective from the management is the first thing. Why does management want to
go for agile? What are the short term and long term benefits/goal they have in their mind? We all
know about the agile benefits. But let me write them once again at a higher level; higher productivity,
better quality software, early feedback about the product/project, working software after every
release/sprint, transparency between development team and end users etc.

2. Make a Transition Plan
Make a transitioning Plan after having a proper brainstorming. Now this plan will talk about the how
part of the transition. Management need to identify the transition approach. My suggestion is to
follow the progressive and elaboration approach. Lets become agile in an agile way. Let move
towards agile organization by continuous learning through retrospective from each iteration.

3. Training
Entire organization has to attend the agile training. I would suggest starting the training from the top.
As per my understanding, this initiative will be a successful one if the top management understands
the agile. Middle managers should go for agile certification. Developers and testers can attend at
least 8 hours of agile training to start with. Remember this is just to start.

Otherwise, agile is not that easy to learn in 8 or 16 hours. Every person will need to read a lot before
practicing at the floor. Give them their own time to learn the agile. They will take time to wear the
new skin of the agile development. Remember people will always resist any new change. People are
happy with their comfort zone. So let them take some time to realize that they will not have any
choice but to uncover the new ways of the development.

4. Revisit Existing Roles and their responsibility
Scrum-Agile - 43

You also need to work on the modification of the job description of the different roles we are planning
to transition. Project Manager will no more work as a project manager; he might be working as a
scrum master. Lead will work as a Sr. developer and will work in a kind of flat hierarchy.

5. Buy Agile Books
When Hubert Smits joined my project as a program director, he immediately asked us to buy agile
book and ask us to circulate in the team. This is important because you are creating that
environment to foster agile in your organization.

6. Paste Agile Poster All Around
Another thing what Hubert did is to paste the big agile poster all around the floor. People can see
them, read them even while walking. People behavior changes accordingly.

7. Agile PMP/COE
Make a group of expert people who will provide the rules and regulations, policies, guidelines for the
project. You can call this group anything. Traditional companies call them Agile PMO or Agile COE
etc. Remember these people need to be expert. If any company does not have these people then
hire them. These people will be pillars in this initiative.

8. Identify Pilot Projects
Identify projects those will be treated as pilot projects.

9. Decide Sprint Cycle
Start with the 4 weeks sprint cycle. As per my experience, developers and testers prefer the longer
duration. They would prefer 4 weeks sprint, which is also quite good.

10. Initially, people will hesitate to give their daily status in the scrum call. So you need to make them
understand the importance of the daily scrum. According to me, this is one of the most challenging
parts. But we need to trust them.

11. PMO need to identify the basic path of execution the pilot projects. Some of the basic questions
can be:
Scrum-Agile - 44

a. What will be team size?
b. What could be the sprint cycle?
c. Working hours to maximize the collaboration hours?
d. Basic project monitoring techniques like metrics, reporting cycle, SMR etc
e. Various templates and guidelines for the project use.
f. What kind of companys baseline for various CMMis parameter are they going to use?
12. These pilot projects will construct a road for other projects to drive smoothly towards agile
roadmap.

Scrum-Agile - 45

Agile Change Management

What is a change?
Any activity (new story, defects, scope change in the existing story etc) that is impacting teams goal
or commitment should be treated as a change for the team. In agile, once team enters into the sprint
after that whatever changes coming into the sprint backlog should be treated as a new requirement.

Agile Change Management
Agile development welcome changes as far as they add value to the development. Agile software
development teams embrace change, accepting the idea that requirements will evolve throughout a
project.

Product owner is the responsible for ROI and is the owner of the backlog. It is POs responsibility to
assign work to the team. Team has the visibility of just one milestone. So it is absolutely fine if PO
changes the requirement priority before the sprint starts. But discourage the requirement changes
during the sprint.

One of the 12 agile principles says Welcome changing requirements, even late in development.
Agile processes harness change for the customer's competitive advantage. But Scrum suggests
that we should freeze the requirements after the planning session as soon as team gives its
commitment for the current sprint. After that any change coming should be treated as a new
requirement and should follow the change management process.

In Agile, requirements are discovered and evolved during the development. Change control
comprises the procedures used to ensure that changes are introduced in a controlled and
coordinated manner. Every change has a cost attached to it. Should we accept all the changes
coming from product owner? I dont think so. So when cost is attached then as per the triple
constraint other parameter schedule and scope has also some impact. So this is quite important that
we give it the adequate attention all the time.

Agile Change Control Board (CCB)

We all know that change management (of the product backlog) is inbuilt into the agile framework and
does not warrant any special process. Till now, as per agile we know that the product owner is the
Scrum-Agile - 46

owner of the product backlog and he is sole responsible of the backlog priority. Then why am I
talking about a change control board in Agile?

Well, based on my experience and understanding, I would never give all decision authority to a
single person. No one in this world would always take right decisions. Even a single decision can kill
the dreams of many people, who had a vision of some product or service. Then why not to form a
change control board, a set of people, who will take the decisions together whenever product owner
wants a major change in the product backlog. They will meet regularly to discuss the changes. I
would suggest to include Product Owner, Scrum Master, Meta Scrum Master (if exist), Team Lead to
be part of the CCB. On top of that, product/project sponsor should also attend the meeting whenever
he gets a chance.

Now when I am talking about a major change, we can draw a line between major and minor change
based on the efforts, cost, prority and business value of the change. Minor changes can be
implemented without CCB meeting and SM and lead can take a decision on that. But change
process listed below has to be followed in all the cases.

Change control comprises the procedures used to ensure that changes are introduced in a
controlled and coordinated manner. Every change has a cost attached to it. Should we accept all the
changes coming from product owner? So when cost is attached to it then as per the triple constraint
other parameter schedule and scope has also some impact.

Normal Conditions
All Scrum teams work on a product backlog which is owned by the Product Owner. The user stories
are prioritized in the decreasing order of priority. So at any point of time the scrum team is always
working on the highest priority item. The priority of an item is based on multiple factors including
ROI, Business priority, technical dependency, risks associated with the story etc.
Change Triggering Points
If there is a new story, of high priority, added during the execution of a sprint, change control board
members will sit together and work on the updated product backlog to decide the user stories which
are planned for the next sprint. Similarly if during sprint review, the Product Owner feels that a story
needs to be re-worked or changed due to inputs from stakeholders or market conditions, that
particular story needs to be given a higher priority and the team picks up that story as a part of the
next sprint depending on the available team capacity.
Steps taken in the change implementation
o Product owner raises a request to add/modify a requirement/story in the sprint backlog
Scrum-Agile - 47

o Impact Analysis of the change by the team
o Estimation by the team
o Decision by the CCB to accept or reject the request
o Look at the available capacity and resource utilization
o If there is no capacity available then some other user story should be dropped from the product
backlog; best practice is to remove the user story that is not yet started by any of the team member.
I would also suggest maintaining a change log at scrum master level per sprint. This change log
should also be reported in the sprint status meeting after the sprint. And off course this is an item in
the retrospective meeting.

Scrum-Agile - 48

Challenges in Distributed Agile

Distributed agile is a need of the market at the moment. But it is not that easy to implement. Distributed
agile brings certain challenges along with it. But if we execute project in distributed fashion, we have more
reasons to smile. Before we talk about these challenge, let's have a look at the following benefits of the
distributed agile:
Reduced cost at off-shore or near-shore
Quick time to market because of the time zone difference between offshore and onshore
Better productivity with off-course better quality
Improved operational efficiency because of the competitor pressure

Co-location and coordination are the most important aspect of the agile. We need to be in touch with the
basics and should try to implement the agile with the help of the principles written in the Agile books. I
have worked with Hubert Smits, who is one of the agile guru, in my previous project. Hubert helped me to
learn agile and gave me the term "Agile by Book". And since then I am implementing agile as per the
books. Well coming back to the distributed agile.

Thanks to the available tools and technologies because of which Agile no longer requires a co-location in
the physical form. With the help of the available latest technologies and tools, we can create a virtual co-
location rooms that will work absolutely fine. Having said that I am not saying that I am moving away from
the Agile manifesto written in 2001 on co-location. Communication and collaboration can be achieved
with the help of latest technology and tools. It does not matter where they are physically located? And
today in 2012, we have many success stories in almost every company in the
distributed Agile environment.

Challenges in distributed agile model:
1. Working in a Shift: One of the core principles of Agile is the collaboration. This is one of the most
challenging tasks, which we face while executing the distributed agile environment. Some of the team
members like product owners, scrum master and application architect would be sitting at onsite and team
members (Dev and QA) will be sitting at another location. One of the options are offshore/near-shore
team work in shift that gives maximum overlap time to interact with onsite team.

Solution: Try to find out a collaboration hours that have at least 2-3 hours of overlap. This overlap time
will be utilized by the team to interact with each other and to resolve the dependency they have between
each other. Team can utilize this overlap time for daily scrum, question-answer session, planning
meeting, review meeting, retrospective meeting etc.
Scrum-Agile - 49


2. Communication gap/breakage within the different team: Roles like Product Owner, Scrum Master and
Application Architect along with some core team like architecture team, data model team might be sitting
at onsite. Communication between these team members are critical success faction for the
product/application, you are developing. Better is the communication better will the product quality?
Communication between development teams and these onsite teams will also be a challenge during
execution because there will be a delay in the communication response during the day time at offshore.

Solution: As far as Product owner is concern, we can have a proxy product owner at offshore to help
offshore development during the day time for any query related to the domain or product functionality.

Well we do not have any direct mitigation or solution of this challenge. Only thing is that we can raise the
Risk in the begin of the sprint so that team have some backup plan if offshore team need something
during their day time then team can continue with their backup plan.

3. Missing of Critical roles like Scrum Master and Product owner at either of the place.
Solution: I propose to have both of these roles at offshore. How? Keep a full time scrum master
dedicated to the team at offshore. Keeping product owner at offshore might not be a good idea. As I have
written in point number 2 above, we have a solution of this challenge and that is to keep a Proxy Product
Owner at offshore.

4. Lack of the agile knowledge. It is highly critical for team to have understanding of the Agile concepts.
Team can be trained on agile but team takes its own time to learn the Agile concepts. As per my
experience, team usually takes around 6 months to get into the Agile philosophy.

Solution: Start from at least 8 hours of Agile training for the entire team to start with. Then I would also
recommend some certified scrum masters in the team. What I had also done in my previous project is to
post the big Agile banners all around the floor where team was sitting. I had got some very positive
feedback from pasting the banners.

5. Process compliance as per the CMMi guidelines. This is one of the most challenging parts from the
offshore project manager. He will always keep on struggling with the quality group on the process
implementation.

Scrum-Agile - 50

Solution: This is the most difficult part if you are working in a traditional company where Agile processes
are not pre-defined. I had a struggled the most on this part but at the end of the around one year, I had
some maturity in the CMMi process implementation.

6. Attrition: we should be ready to face higher attrition in the agile team. Some of you might not agree to
this but this is a fact.

Best practices in distributed Agile:
Work in the One team concept. Despite the team location, scrum team should be treated as
One Team. It will solve so many problems in the long run.
Having Proxy Product owner at offshore/near-shore is quite useful for the team members to get
their query answered immediately during the day time
Scrum master at offshore/near-shore: Scrum master is the shield of the team so he/she should stay
with the team at offshore if team is at offshore. Teams need a leader whenever there is some breakdown
or issue arises. If SM is there with the team, we will have a better productivity from the highly motivated
team. Trust me!
Apart from having scrum master per team. I would also suggest allocating a dedicated project manager
or Meta scrum master at offshore who can handle regular project management activities from the higher
site.
Having Scrum of Scrum (SoS) during the collaboration hours. If you are working in multiple scrum
teams to discuss the status, dependency, impediments, issues, risks etc. across locations.
Integrated Environment; it doesnt matter where team is sitting. Integrated environment is the essential
part of the software development nowadays.
Regular travel of some team members from both side to overcome the cultural challenges.
Dedicated and fixed collaboration hours between the 2 locations. Every day after the scrum team can
have around 1-2 hours of meeting, in which team can discuss their progress, questions, required support
from other team etc.
Tools and Technologies
o Wiki, if anyone is making any change, entire population is intimated by the mail automatically. All the
common documents are also uploaded here.
o Tools for code review (code collaborator), configuration management (clearcase) etc. are very
important for distributed team
o Good internet speed for audio or video communication
o Agile project management tool like JIRA, Rally, Assembla
o Screen sharing tools like Mikogo,WebEx
o Instant communication tools like msn, skype etc
Co-location is a must! Does not matter if it is with the help of the virtual rooms and the tools mentioned in
the above point.
Similar hardware & software setups
Crisp, clear and continuous Communication. Face to face communication is considered to the best
communication method in Agile. So you can use video chat either daily or weekly depending on the
project situation.
Scrum-Agile - 51

Tech Lead Roles & Responsibility
I was doing an engineering gap analysis of one of my projects. During the analysis, I got to know
one critical gap i.e. technical lead roles and responsibility (R&R) in the project. Though, R&R was
already in place under the project plan but it was not a detailed one and leads were not referring to
what was written in the project plan document. I thought to make a list of activities where leads were
involved in their day to day work. But what next, I thought to make it a detailed one, something like a
reference point for the leads. I started Googling, and found that this is one of the interesting topics to
discuss online. I got a new topic for my blog.

So, who are the technical leads? Lead programmer, senior developer who are technically way ahead
of their teams. Who can visualize the project architecture better. Ideally, he should be superior, in
terms of productivity, quality, maturity etc, than all the team members.
I have divided the R&R into 2 sections:

1. Project Responsibility
2. General Responsibility

Project Responsibility:
1. Own the Responsibility of the overall sprint or iteration outcome
2. Use projects best practices and coding standards
3. Prepare and help team to prepare the design; should have a very good understanding of the project
architecture
4. Coding and unit testing including JUnits
5. Conduct peer review and provide feedback
6. Remove the technical impediments
7. Update regular associates RAG (Red, Amber, Green) status; discuss the Red cases on the
immediate basis with the project manager to help the manager in the attrition management
8. Update sprint tracker with accurate information to identify the risk and issues proactively at the sprint
level
9. Conduct project risk identification and mitigation action planning with the PM at the project level
10. Participate in CAR and help in preparing the data
11. Conduct FIR; Process check master to make sure that his team is following all the listed
procedures
12. Constantly looking for ways to increase the teams velocity/productivity by eliminates the waste. This
should be one of the discussion points in the annual appraisal.
13. People management & Technical management
14. Help PM in the annual and mid-year appraisal process
15. Assist project manager in the project coordination/management
16. Report the status with alarms, explanations and solutions;
Promptly escalate issues to the reporting manager
Track and resolve issues
17. Target - Zero surprises; proactively react to the surprises with the detailed written explanation
18. Last but not the least, tech lead should be a reference book for your team members
Scrum-Agile - 52


General Responsibility:
1. Interface between team and management
2. Write quality code, set an example of quality in front of the team members
3. Gain the teams respect with the quality of your work and by doing what you are preaching
4. Define early on what success means for you, the team and the business
Set reasonable expectations in front of the team
5. Should be part of the design team
Should have design vision and understanding
6. Be firm but fair
7. Admit your mistakes
8. Build and maintain high team morale
9. Should not be biased towards any individual professionally but personally you can
10. Task assignment should be fair
Tasking should be done with the team together
Match people and tasks based on their skills and their personal preference
Work the estimate with the team
11. Try to become a role model for the team
12. Take necessary measures to avoid centralization of knowledge. There should not be any
dependency in the project on anybody.
13. Mentor people; It is your job to raise the education level of your team
14. Quality with on time delivery of agreed deliverable
15. Team can approach lead any time for any functional or technical concern
Tech lead requires balancing between technical and leadership talents.
16. Lead should Motivate/encourage the team members
Especially when team is under pressure with the tight deadline
17. Lead should share the limelight with the team
18. Dont blame anybody publicly for anything
19. Work as hard or harder than anyone else in the team
20. Focus on the technologies associated with the software or application you are building. Learn those
technology thoroughly
21. Flexible enough to work under different work environments settings
22. Fun @ work
At the end, always say WE instead of I

Scrum-Agile - 53

How to Improve Projects Deliverables Quality?

Effective project management and quality management is the success parameter of any of the
project success. As a project manager, if I have to tell 1 thing that I have to take care all the time is
the QUALITY. Quality should be the success parameter of any of the project. It should be given the
at-most focus in all the phases of the project. Below are some of the ways to manage, control, and
improve the quality of the software development.










Scrum-Agile - 54























Human Factor
Project Atmosphere: As a project manager, we are responsible for fostering a positive environment
so that every associate foster for the better quality deliverables day by day to the customers. Try to
sense the stress of the associates, if you find that associates need a break, give them a break. This
is important because this can lead to frustration, low morale and reduced quality output.
Try to engage associates in the overall improvement. Seek feedback from them to make the
atmosphere better and their commitment towards quality deliverables.
Training: Invest in the associates training. This is an investment for the long term. I have identified
one training coordinator at project level who directly works with the training department. We have a
monthly goal on the training.
Engineering Processes
Pre-planning and Planning meeting is the base of the functionality that the team is going to deliver
in next 4 weeks cycle in case of the scrum based project. Team member should attend the planning
with complete details. Adequate timing for the planning is important, 4 weeks sprint usually have a 4
hours of planning meeting.
All the pre-conditions, pre-requisite should be identified during the planning meeting and should be
clearly circulating to the concern person. Team should try to avoid picking up the user stories those
have some dependency on other tasks.
Scrum-Agile - 55

Estimation: Proper estimation is the key of the good quality of the deliverables. As per Agile
methodology, estimation should be done by the team together by some standard methodology like
planning poker. If estimation is correct then team will develop good quality software and they will
take the required time as per the planning and estimation.
Standard WBS/Tasking: While doing the tasking, each and every team member should use
common WBS codesin the project management tool. Common codes will help to bring uniformity at
the project level. It will also help to extract a report, which will have the % of efforts that your team is
spending against each activity for your future corrective or preventive action.
Acceptance Criteria: First and the foremost thing, is to have the Acceptance Criteria or the
Definition of Done (DoD) defined clearly. Every team member should have the understanding and
visibility of the DoD all the time. This will help team members to see their daily goal as per the
deliverables. Their behavior will change accordingly when they will come to see the final goal of the
product all the time at their desk.
Test Cases/Acceptance Scenarios: Test cases should be reviewed by the product owner because
these test cases are the acceptance test scenarios against which PO will accept the user story.
These test cases should be detailed enough to cover all the critical scenarios. During the
development, if dev or QA comes with the new scenario that is not written in the test cases, it should
be immediately bring into the PO notice.
Analysis & Design Document: Agile says we should have minimal documentation and we should
give more important to the working software rather than having detailed documentation. Analysis
and Design is one of the artifacts that should exist for each and every user story. It does not matter
in what form do you create the artifact? It might be a simple thought or an approach that you are
applying in this particular requirement but it should be documented against the user story. What I am
doing in my project is to write simple notes in project management tool for simpler user stories and
proper design document in case of a complex user stories.
Code Review: Code review should happen at 2 levels. One is the peer code review at developers
level and another one is at application architect level. It is mandatory to have a common and
standard coding guidelines and checklist for each developer and tester. All the code review defects
should be logged and should be reported at sprint level.
Testing
Unit Testing: JUnit or NUnit are important or rather I should say is the most important thing. Unit
testing should be done diligently. As Unit testing is the first level of testing, we should try to identify
all the defects at this stage itself. Cost of the quality at level is lowest in the software development
life cycle. JUnit should be reviewed by the application architect.
Functional Testing: QA role starts from here. QA is not only the tester but also a developer in Agile
projects. He/She has to develop the automation script code. All the functional defects should be
logged into the defect management tool.
There should be review process in place for QA code also. Whatever code QA is developing, that
should be reviewed by the QA lead.
Scrum-Agile - 56

Integration Testing: This is done by the regression suite all the time. Regression suite should be
given the highest priority in the Agile projects. There should be a dedicated team that should work
primarily on the regression suite. Adding more automation scenario, refactoring, execution of the
regression and sanity suite, logging and tracking of the defects should be the prime responsibility of
this team.
If there are more defects that are coming by the regression suite than meta scrum master and scrum
master should take some action on it. As I said earlier, it should be given highest priority. If you are
developing software that is not working software that means the whole objective of the project is lost.
Testing Coverage: Quality of the product is also dependent on the testing coverage. Higher
management need to have a vision and goal of the testing coverage. Developer and tester should
keep this in mind and should always create JUnit or NUnit and tester should try to cover more and
more acceptance scenario to have a better and better testing coverage. Unit testing can be
measured by a tool like EMMA.
Sprint Review Demo: As per the Agile process, team gives demo to the product owner at the end
of the sprint. But intermediate demos are quite helpful to build the final product. It will also help to
reduce the rework if team will continue showing the in-progress user stories to the product owner.
Build Process: Before deploying to the main environment, developer should make sure that the
newly created build is working properly. It is going to reduce the idle time in the project.

Quality Management
Completing Quality Processes:
o Regular project audits from your SQA and external SQA
o Regular team meeting to discuss the overall improvement points
o Peer Code Review
o Code Review
o Defect Logging Process
o FIR or all the processes related to the Definition of Done
o Metrics after every sprint
o DAR Process
o CAR process
Defect Management
Logging Internal Defects
Scrum-Agile - 57

o Introducing 1 defect sprints per quarter
o Keeping some capacity available for defect fixing
Logging and tracking the External defects

Anda mungkin juga menyukai