Agile Stand-up Meetings

One of the salient features of agile and probably the most effective is the "Daily Stand up Meetings". Teams start their day from the daily stand ups and craft their day around the stand up. Stand up meeting enforces:
- Tranparency within the team
- Ownership of work
- Collaboration
- Risk Mitigation earlier in the cycle
- Effective communication

In my consulting experience, i have often seen people being confused about what to talk in a stand up. Taking a que from that, here is my answer:

How to conduct a standup? 

• Stand up must be practiced beside your story wall EVERY DAY
• This helps in keeping your story wall updated every day
• Stand ups are more effective if they are conducted early in the morning as a first thing before starting your work

Who should be the audience? 

• Your team
• Your PMO (they must have an equal say in the stand up just like any team member)
• Your Client (If your client is in the same location as your team then include him in the stand up)

Most people argue that having the client in the stand up may influence the teams work. But I dont agree to this, I feel the derailing can happen only if you DONT know how to conduct a stand up. Remember the stand up is just a status update from every team member, if your stand up leads into a discussion then that is definetly going to derail you and the whole purpose of having a stand up is lost in thin air.

What do you need to talk in a stand up?

• What did I do yesterday?
• What will I do today?
• Do I need any help? (Solving dependencies)

Kick Start:

• Consider a stand up token (like a pen)
• Ask any of your team member to pick up the pen
• Who ever picks it will start the stand up update first
• You then pass the pen to the next team member in a clock wise direction
• Thereby next team members gives his stand up update
• You repeat until the entire team has given an update

During the stand up make sure you update your story wall as well. 

Example: if a dev pair has completed a story then move the story on the story wall to the respective swim lane.

Key Things to Note:

• Time box your stand up (Overall stand up time must be 10 mins)
• Each team member must get a minute or two to speak
• If you find that the team is discussing rather than updating then any of the team memeber can call a "time out" asking the people discussing to take the discussion offline
• Be specific about what you update and call out dependencies or issues STRONGLY
• Dont look at your manager and give an update, remember that its the entire team that you are addressing

Agile Planning - Planning Poker

"Estimations" is a buzz word in the software world. Every one are looking at the best ways to estimate their taks/stories/features. But is there some tried and tested technique to arrive at the magic number?


Yes there is one atleast in the agile world, and as a Agile coach I have extensively used this to demostrate a more pragmatic way of arriving at estimations. Here is a sneak preview of the same:

So how to get to the magic number ?????

Prerequisites:

Stories:

• Stories have to be analyzed and approved by business (SME)
• Stories must have clear assumptions and specific acceptance criteria

Estimation numbers:

• Lets take 1, 2, 4, 8 as estimation numbers
• 1 being the least and 8 being the maximum
• If any of the story is estimated 8 then it means
• The story is so large that it  cannot be played in one single iteration/sprint
• The story must be further broken down into smaller ones

The Game:

• The facilitator picks up one story from the story bucket and reads the story details loud to the team
• The story details must be functional and NOT tilt or lead towards solution’ing
• The team then discusses the tasks that are required to meet the acceptance criteria defined in the story
• During this time the team can clarify any queries related to the story with the facilitator/BA
• Its important to promote healthy discussion within the team during this time as it yields in better estimation
• Facilitator then asks the team if they are ready for the estimation
• If Yes, on a count of 3 the team starts to estimate
• This can be done in 2 ways:
• Use poker cards, so that each team member will show one card that he/she feels is the right estimate of the story
• I like to use "Shout out loud" technique, just use your fingers to point out the estimation(1,2,4,8)
• If the entire team agrees on a number then there is consensus and the team moves to the next story
• If the estimates differ, the high and low estimators defend their estimates to the rest of the team
• A healthy debate must be encouraged but the debate must not yield into chaos
• The debate must be time boxed
• After the discussion, the story is re-estimated like earlier unless a consensus is reached
• Repeat the same for all the stories

Ingredients of a good user story

I have read and heard about people talking about what is a good story made of. Well in my point of view, a good story is one which the team defines as "Good". The whole idea of being agile, is to empower the team to differentiate what is good and what is bad. I definetly think that calling a story as "a good story" is a teams decission probably after having looked at a few bad ones :)


Nonetheless, there is no harm in knowing what people in the agile world are thinking of when they talk about the definition of a good story. Here is my take on the same - hope this helps:



Here are my 5 cents on the topic:

• Don’t elaborate be specific (Elevator-friendly)
• Size your stories well
• Prioritize them
• State the assumptions of the story and call them our clearly
• Flush out the right business value in the Acceptance criteria
• Validate story tasks against the acceptance criteria
• Avoid technical information in a functional story (Make it customer focused)
• Separate functional stories from tecnhnical stories/integration stories 
• Add additional data supporting your story  (wire frame, data, examples, etc)
• Get a analysis sign-off from the business before the team starts working on them

Agile Innovation Games - Speed boat

One of the most important facet that the agile world exposes is seeking feedback. Deriving feedback as a team for the team is the most essential element that makes the team.

Speed boat excercise is a fun way of doing a retrospective, it engages participants and also delivers value. The use of speed boat in retrospective is explained below, hope this helps :)

As an example, consider your (Speed boat) to be your iteration

Successful Iteration is the one that has completed its projected velocity (The Island)

On the post-its given to you, write down what did not go well with respect to your iteration (The Anchors)

On the post-it’s given to you, write down what could be made better in the iteration so that the iteration would have completed the projected velocity (The Engine)

Time limit is 5 minutes

Once we have the feedback, collate it remove redundancy and create themes

Then pick up each theme and prioritize it by giving it an estimate (estimate of pain – 1 being low to 3 being extreme)

Pick up the extremely painful anchors and plan to mitigate the risks around them

These painful anchors are the ones that need to be removed in order to ensure the speed boat sails swiftly and reaches the island safely

What did we learn from this?

Surface hopes and concerns

Motivate people to think

Agree as a team

Plan to mitigate hurdles (Anchors)

Where can we use this exercise?

As an exercise for discovering the depth of process adoption

In a “retrospective meeting” to discover what went right or wrong