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

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