# 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

#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.

# 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.

#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.

Poll analysis

POLL QUESTION: Project management framework - Which of the followingstatements is correct in the context of triple constraints?

CHOICES AND RESULTS

• A project is successful, when it exceeds customer satisfaction, teamsatisfaction and management satisfaction 0.00%
• A project is successful, only when it gets completed within time, cost and has met the defined scope 86.67%
• A project is successfully completed, only when all stakeholder requirements are met 13.33%
• A project is successfully completed when it is on time and within cost budget 0.00%
  

Poll ananlysis

A project is successfully completed when a project has met it's agreed upon scope within the agreed upon time, cost.

Let us take the case of the iridium project by Motorolla. It met it's scope within the agreed upon time and cost. At the same time, this project did not deliver the business results becuase by the time this project was completed, internet became very popular and most of the functionality iridium project could deliver to the end user, internet delivered at a fraction of the cost. In this case, is the project management of this project successful?

The business case of the project is owned by the project sponsor, who has funded the project, hence in this case the primary responsibility for the project not delivering it's business objective lies with the sponsor. The project management of this project was of good quality, as the project was completed within time, cost and met it's scope. Of course the project manager could have identified it as a business risk and highlighted it during the course of the project. Still the primary responsibility of not meeting the business case lies with the project sponsor.

For more information about this group, please visithttp://groups.yahoo.com/group/consultme