# 11 Implementing Agile

Sprint planning meeting agenda

Total hours : 8

Sprint start date : ?????? End Date : ??????

Objective of the meeting

• To agree and commit to a set of features that will be 'done' during the sprint
• To agree on the demo date, time, participants and the acceptance criteria
• To estimate the story points for the features agreed upon
• To estimate the activity level effort requirements to complete the agreed upon features
• To agree on the daily scrum (stand up) meeting place and time
• To set the tracking board
  
  First half
  
  1) The scrum master explains the agenda for the meeting
  
  2) The product owner shares the 'theme' of the sprint to the team
  
  3) The product owner shares his/her priority of the features with the team
  
  4) Discussion time on the features (reference material - user stories)
  
  5) Derive the points for the features
  
  6) Lock in the features for the sprint
  
  Second half
  
  1) Decompose the features into activities
  
  2) Estimate the approximate effort required to complete the tasks
  
  3) Set the tracking board for the sprint
  
  4) Decide the daily stand up (scrum) meeting time and place
  
  5) Decide the demo date

#10 Implementing Agile

Reality Check - Sprint-0

The team is selected, the scrum master is identified, scrum training is provided to the team, product owner has explained the 'product vision' to the team and every one is ready to get into the first sprint. Are we really ready?. It is a good time to do a reality check with the team. Here is the questionnaire;

1) Do I really understand the product vision?. Do I need further clarity on this?

2) Do I understand the scrum framework?. Do I need further clarity on this?

3) Do I understand the technology to be used in the project?. Do I need any formal training?

4) Do I have the facilities and equipment to do my work properly?

5) Do I understand the definition of 'done' within this sprint?

6) Am I clear about my responsibilities within the sprint?. Do I need further clarity?

7) Can I commit to this sprint?. Will other known priorities affect my availability to this sprint?

8) If other priorities are going to affect the availability, please mention;

8.a) How many hours / day I will be available to the sprint?

8.b) Which are the hours I will be available to the sprint?

If the scrum master can get this filled up by all the team members including himself, the will be able to take care of lots of known unknowns :-)

#9 Implementing agile

Bottom up Vs top down

While the top down sponsorship is important for implementing agile, implementation has to be bottom up. Start with smaller teams with a need of change. Pick up projects which are in the start up stage, or look for projects which are almost failures, and then implement agile as a recovery strategy. The key is to look for teams with a need for agile, and create early success stories around them which will make scaling agile easier.

# 8 Implementing agile

Right team selection

"Serve food only for the hungry" - is the right approach while selecting the agile team members. Look for those guys who are really unhappy with the current way of doing things and for the habitual early adopters. Ignore those ones who are resistant to change during the early stages, till the tipping point is reached. Once the tipping point is reached, the fence sitters also will get converted.

#7 Implementing agile

Right attitude

" Obstacles are the things we see, when we take our eyes off the target "

Agile is all about risk taking, and making things happen. Making this happen in an offshore / out sourced environment is quite challenging, as the work environment is not conducive for risk taking. There is no silver bullet to achieve this. The team leader, the team and the HR should work on this together.

# 6 Implementing Agile

How elaborate the user stories should be?

While writing the user stories, one will always get into a dilema on 'How detailed, the user stories should be?". There is no silver bullet answer to this. The user stories should be estimatable. The user stories should contain enough information, so that one can estimate it. If the detailing is less, the conversations will be higher, which is actually encouraged in agile circles. This is perfectly allright, if the product owner has the details to provide, when the conversations happen. If tyhe product owner gets struck at this stage, without answers to the queries, then that can become a bottle neck for the project progress. If the degree of clarity of features is lower with the product owner, then it is a good idea to expand the user stories as detailed as possible. This will make the product owner think through and prioritize features.

In an off shored environment, it is always better to have detailed user stories for the initial sprints, till the team members and the product owner gets a hang of it. During the later sprints, once the product owner's and the team members understanding are in sync, then the user stories can become leaner.

#5 Implementing Agile

Product backlog readiness

Product backlog is the list of feature wish list, maintained by the product owner. These are all just reminders to the features to be developed. While implementing agile, some of the key questions to be addressed include;

1) How much of the product backlog should be available, before planning the first sprint?

• All the key (must have) features should be identified
• All the features, that has an impact on the architecture should be identified

#4 Implementing Agile

Team orientation

" Dont forget to orient your team to the agile values, principle and method."

#3 Implementing Agile

Cultural synchronization

Very often we get to work in teams where multiple cutures are involved, which if not understood well can lead to politics and improper teaming. There could be 'Iam Ok, You are not OK', 'I am Ok, You are Ok', 'I am not Ok, You are Ok' and 'I am not Ok, You are not OK' attitudes. This need not be at individual levels. It can exist at My culture Vs Your culture, My country Vs Your country, 'My office Vs Your office', 'My team Vs Your team' levels. To deliver as a team, all of us need to have 'I am Ok, You are Ok', 'My Culture is Ok, Your culture is Ok', 'My country is Ok, Your country is also fine' attitude. Team socializing is a must to break the ice, and it has to be a continuous process. In my view, there should be atleast one celebration during every sprint....and it has to happen naturally - not as a programmed activity. Cut loose and celebrate, whenever there is an opportunity...or rather create those opportunities to celebrate :-)

#2 Implementing agile

Like any other project management methodology, proactive stakeholder management is key to the success of all agile projects. After identifying all the stakeholders, they can be categorized into the following groups;

• High power - High interest
• High power - Low interest
• Low power - High interest
• Low power - Low interest

Once this stakeholder identification is done, then it is easy to identify the key risks. Dont think that agile project management is risk free. The political, technical, structural, process and cultural risks have to be managed proactively to implement agile project management. Everything starts with stakeholder identification, categorization and management.

#1 Implementing agile

First of all, one must start with the definition of a project; every project has a definite start and end date, are performed by people, constrained by limited resources, delivers unique products or services at the end. I took it from PMBOK, because it fits in well. In an outsourced environment, the typical project durations can be between 1 day to => 6 months. Here the million dollar question is "What is a project?".

In agile, if we have to make some meaning out of a sprint, it has to be atleast 1 week duration "5 working days". This will give some room for "project management". The definition of a project in an outsourced environment should be;

" Any meningful work (cohesive set of activities), which can deliver value and will take atleast 5 working days or more to complete by a team"

Trying to manage individual activities (cycle time 8 hours), is an over kill. If it is an exception, it can be managed by including it as an unplanned activity in the current sprint. If majority of the work comprises of discrete activities which need less than 1 day to complete, it is better to manage them using a task sheet.

Agile Chat :-)

Here is a short chat with a friend of mine on agile project management and I agree with him on this state of agile in outsorced projects. The cultural aspects coupled with the politics and insecurities (politics played by the product owners sitting in a far away country, sitting closer to the sponsor and trying to pressurize the off shore teams and some of the managers trying to be in the good books of the product owners in the process shying away from the 'right things' )compounds the whole process.

17:23 Sid hi aby... sorry i missed your messages.. i was out of town
17:24 me: ok...no probs...i was at pune then, thats why i pinged you
Sid: cool.. how are things with you.
17:25 me: where are u now?
Sid: in hyd..
me: things are fine by God's grace. Into agile consulting as well.
that keeps us going
17:26 Sid: hmmm... a very messed up word i would say.. agile.
everyone twists it to suit themselves to call it agile..
and if they cant implement.. every easily blame it on the model..
me: that is the opportunity for us :-)
17:27 Siddharth: at the end of the day.. politics wins..
me: :-)

--
Abrachan Pudussery
www.abrachan.com
Mobile : +91 9895372115
Gtalk : abrachan
http://www.linkedin.com/in/abrachan

SCRUM at John Deere, Pune

Where are you in agile? WAYINAGILE

I dont have any profound ideas of developing another agile capability maturity model, becuase I personally believe in the need for 'capability immaturity', which gives freedom to innovate and experiment, yet we need a repeatable system in place for organizations to exploit the power of agile in it's entirity. From my consulting assignments, this is the pattern I am seeing with most of the organizations, when they go for agile.

At level-0 , everything is adhoc

At level-1 , some agile practices are implemented (most popular is the stand up meetings)

At level-2, all the agile management practices are implemented (product backlog, sprint planning, daily stand ups, demo meetings, velocity calculations, lessons learned, user stories, story points)

At level-3, the focus is on adopting the engineering practices (build automation, test automation, coding standards, refactoring, code reviews, pair programming)

At level-4, the emphasis is on aligning the H.R practices with the agile values and principles

Scrum @ Zylog, Chennai

PMRI, conducted a two day workshop "Agile Project Management Using SCRUM" workshop at Chennai on the 9th and 10th of Jan,2009, which was attended by around 30 managers from Zylog and we had a gala time during the workshop. During the workshop, the participants mastered the right scrum skills.

SCRUM @ Zylog Chennai

SCRUM @ Zylog Chennai

One day SCRUM workshop at Oracle, Bangalore

PMRI conducted a one day workshop 'Agile project management using SCRUM' at Oracle, IDC, Bangalore. The focus of the workshop was to introduce the participants to the SCRUM framework and the Value system. 

Agile project management using SCRUM workshop @ Everett, Bangalore

Recently PMRI conducted a one day workshop at Everett, Bangalore. 

Agile project management using SCRUM workshop

PMRI conducted a one day workshop "Agile project management using SCRUM'  workshop at Taj Residency, Marine drive. Ten engineers attended this workshop. The objective of this workshop was to enable the participants to implement SCRUM at their workplace. The workshop is logically partitioned into three segments. The first segment focuses on explaining the scrum structure and the value systems required for implementing scrums. In the second segment, the team focuses on doing a mock project which provides hands on exposure to the scrum methodology. In the third segment, the team is given a demo of collabteam tool, with a view to facilitate scrum implementation in a distributed development  environment.