Need for Retrospectives

Every organization and every project has some grapevine running in the inner circle. When I say Inner circle,

it is the closed group of people who trust each other.

For ex: In a typical software project,  a manager(PM) with command and control attitude, would encourage creation of inner circle with project team members, whose opinions are being ignored by the PM. This inner circle group  excludes the manager.  This group in turn talk among themselves and share their agonies without the knowledge of the manager.

Above example of team member inner circle group, can be extrapolated at an organizational level with inner circle being the employee group excluding the management of the company.

The inner circle groups mentioned in the above examples are harmful for the project and the organization. They get created as they don’t have any venue to express their bottled up emotions/thoughts/opinions. This in turn leads to a lot of negativity. This negativity needs to be conquered sooner than later. Here is a good article, which provides techniques to conquer such negativity.

One of the ways to conquer the negativity is to provide a platform for the employees to express their thoughts/opinions/emotions. In Agile projects, retrospectives provides such a venue. This in turn leads to healthier project and teams in a longer term.

Difference between Sprint and Iteration

“Iteration” is commonly used to term in all Incremental and Iterative development methods. 

However the word “Sprint”, which has similar meaning to iteration was coined in the Scrum method. Mostly the Scrum practitioners use the word Sprint. Even though many people use the word Sprint and Iteration interchangeably, there is a notable difference between the two.

Sprint as defined in pure Scrum has the duration 30 calendar days. However Iteration length could be anything as defined by the team.

Introducing new concept – Innovative way from Google

Bringing change is not easy, and people resist changes. Top ten reasons why people resist changes can be found here. Nowadays new processes and technologies keep getting invented everyday and the employees need to be up-to date with it to be competitive.

Introducing the new concepts is not easy. Thought leaders have come up with several patterns too to introduce changes in the organization.   However recently I came across this article Testing on Toilet, which talks about the innovative way being used in Google to teach their employees testing and bringing new change.  As per the author,

A regular weekly(ish) tip posted in toilet cubicles and above urinals. Short enough to be read whilst doing your business

Even though the above method looks odd and radical, trust me at the end of the day, developers would definitely learn something good and remember it for a long time.

Here is one of the actual pictures taken in the Google toilet giving some tip about testing certification

Agile Certifications

Suddenly I am seeing a spurt in activities around Agile certifications. Scrum Alliance is working seriously with various thought leaders in coming out with new certification criteria.  There is another organization World Agile Qualifications Board(WAQB) coming up new Agile certifications.

Hope all these people come together and have one certification at some point of time in the future.

Glossary of Scrum terms

Scrum being the most popular Agile methods, a lot of new Scrum users either are getting distorted definition of many Scrum terms or have total misunderstanding of the terminologies. 

To avoid such misunderstandings, Scrum Alliance has glossary of 39 key Scrum terms

Scrum FAQ

Following questions are frequently asked by the novice Scrum teams. I will keep updating these questions and answers as and when I get it.

1. Can we have single Scrum Master(SM) for multiple projects ?

Answer: It is recommended to have a dedicated Scrum Master for each project. Diluting this could also dilute the effectiveness

2. Can Scrum Master be a Product Owner ?

Answer: Scrum Master should never be a product Owner.

3. Can Scrum Master be technical and can SM help the team if they are stuck with technical issues ?

Answer: It does not matter if the SM is coming from technical background or management. However if SM is technical, he/she should be careful enough not to dilute the SMs responsibilities in the process of helping the team with technology stuff.

4. During the Scrum Meeting, my colleague talked about an impediment and I had the answer. However, can I answer it immediately and it won’t take more than 1 minute ?

Answer: Don’t diverge from the recommended rules around Scrum Meeting. Any discussion should happen outside the Scrum Meeting. Even though your answer takes only one minute, some one else could also jump in saying even he/she needs a chance to answer another question. This leads to chaos and could stretch Scrum Meeting beyond recommended limit of 15 – 20 minutes. My recommendation is to follow the rules by the book until every one gains experience.

5. I just need another 4 hours to complete my task and the iteration is coming to an end, can I stretch the Iteration/Sprint duration ?

Answer: No. Iterations are time boxed.

6. When people say Sprint duration is 30 days, is it working days ?

Answer: Sprint duration of 30 days means 30 calendar days.

7. The team has completed all the tasks before the sprint ends, what should they do now ?

Answer: The team can approach the product owner and request for additional items from the PB.

8. Is it mandatory for the team to follow the Idealized line in the burn down charts ?

Answer: Idealized(A.K.A Ideal) line provides just a point of reference.

9. Can I work on the undone tasks in the next iteration ?

Answer: Undone tasks would go back to Product Backlog and Product Owner would make a call on the set of requirements for the next iteration with due feedback from the team.

10. Should I use Iteration or Sprint ?

Answer: All sprints are iterations but not all iterations are Sprints. Sprint is the terminology coined by the Scrum co-founders to define an iteration.

========================================

P.S: If you are aware of more questions and answers, feel free to send me and I would post it here.

Getting the estimations "accurate" in one go – a vestige

A team adopting Agile method for the first time tends to do many mistakes during the initial days. One of the common mistakes is about trying to do accurate estimation. During the Iteration Planning Meeting(IPM) of the first iteration, the team does not know their velocity and tends to spend time trying to come up with “accurate” estimates or estimates with additional unscientific buffers. They tend to spend too much effort detailing out tasks and estimate them.

Agile methods discourages teams spending too much of effort on reaching perfection in one go, especially around estimations. It recommends teams to apply the empirical control model by frequently inspecting the estimations and adapting them.It recommends to go with daily re-estimation technique.

Daily re-estimation

Agile methods recommend that

• During the IPM, estimation for the requirements should be done with whatever knowledge one has at that point of time
• While doing the daily re-estimation try to steer and come up with more accurate estimates
• Use the optimistic estimates rather than the pessimistic estimates

Subsequent Iterations

Right from the first iteration, the team must track couple of key parameters, For Ex:

• Planned effort Vs actual effort
• Number of committed stories Vs actual stories delivered
• Number of new tasks discovered during the iteration
• Planned resource budget Vs actual resource budget

Once the team gets to know their velocity, the future iterations could be estimated and planned in a better way.

Conclusion

• Trying to detail out all tasks, trying to provide accurate estimations, detailed planning and analysis are the vestige coming from the waterfall model
• Agile recommends frequent delivery of working software rather than wasting time on analysis-paralysis