Agile Teams & Performance Appraisal

It is that part of the year for a lot of people at various organizations where managers provide feedback and rate individuals on their performance during the previous year. I am sure we have seen the “Bell Curve” at some point in time of our work lives or may be part of school grading systems (Some schools also use the bell curve to grade students).

Through my experience in Lean & Agile I have come to believe that Lean & Agile values more:

- Cross functional Teams as against functionally silo teams.
- Self-organizing Teams as against directed teams.
- Empowered Teams as against Teams working under command and control.
- High Performing teams as against top performers.

I have always looked at the above as the Manifestos for High Performing Agile Teams.

A lot of organizations are still challenged with the superficial problem of how we fit Lean and Agile teams on “The Bell Curve”.  Ideally I would like teams to be graded rather than individuals and this should work provided team members are fine to be graded as teams.

If you have tried something similar or are already thinking about it I would like to learn from your experiences in solving this problem.

Please share your thoughts.

Agile teams are the taxi drivers on the delivery highways.

I was reading this very interesting article by Darren Smith, General Manager @ Thoughtworks about The Agile Taxi Driver.

In this article the author goes on to explain how both the customer and the teams (Taxi Driver) are both equally responsible for delivering on schedule with good quality and within the designated budget. It is a mutual responsibility both for the customer and the development teams to talk to each other and ensure course correction so that we delivery on time and budget with quality.

This story inspires me to draw an analogy on behaviors between teams and product owners where the teams are the Taxi Drivers and the Product Owners are the immediate customers. A lot of times teams tend to do just exactly what the Product Owner asks them to do and there is nothing wrong with that. What we tend to miss out is the aspect of collaboration / discussion / interaction with the Product owners regularly.

PO's are best placed to make priority calls because they have the business context from which to decide. However, it is important for teams to expose factors that the PO's might not have considered as early as possible so that the PO can make the right decision. An example of this is teams clustering related user stories. This info if available to the PO in advance could help the PO make better priority decision to include related user stories in a sprint for better flow efficiency and throughput.

The intent is not to take the decision out of the PO / customer's hands; instead to help the PO / customer make the best decision given all of the relevant information at the time.

Read @ Darren Smith, General Manager @ Thoughtworks about The Agile Taxi Driver and share your thoughts and comments.

Lean Startup: Reduce time to market time & cost.

What is a Lean Startup?

Definition from Eric Ries, Founder of Lean Startup Movement is simple and concise.

“A Human institution designed to create new products and services under conditions of extreme uncertainty. Nothing to do with size of the company, sector of the economy or industry”
                                                                                         - Eric Ries, Founder of Lean Startup Movement.

"Lean Startup" is a system for developing a business or product in the most efficient way possible to reduce the risk of failure.

It is an approach for launching businesses and products that treats all product and business ideas as assumptions (or hypotheses) that must be validated by rapid experimentation in the marketplace.  The approach relies on scientific experimentation, iterative product releases, and customer’s feedback to generate validated learning.

If you need some more info hop to http://theleanstartup.com/

So now that we have some context into Lean Startup and if you are planning to launch a new technology product or are worried about time to market on your existing products, I would like to share an interesting case study how Lean Startup helped a product launch:

- Reduce time to market by 40%
- Reduce cost by 32%.
- Improved Quality by 55%
- Improved Business value by 40%

This Webinar is a walk-through of a "Live Product" built using Lean Startup & MVP approach that proves quantitative gain in time, cost quality & business value.

Webinar - Lean Startup: Reduce 40% go-to-market time & cost on your next product launch

This Webinar is a walk-through of a "Live Product" built using Lean Startup & MVP approach that proves quantitative gain in time, cost quality & business value.

The webinar would focus on the following topics:
- Concerns while new product development & How Lean Startup addresses these questions / challenges
- What is Lean Startup
- Lean Startup vs Traditional Approach
- Innovation and speed through MVP and Continuous deployment
- Aligning Product Launch, Marketing and Sales in Lean Startup approach
- Introducing Customer Engagement in the product life cycle
- Reduce time & cost by almost 40%
- Increase product quality and business value by 50%
- Case study - showcasing Lean startup benefits
- How Lean Startup can be applied in Enterprises

Project Managers FAQ's on Agile

Project managers adapting Agile have a series of questions about Agile ways of working. This is my attempt to list and answer a few.

Can we measure earned value in Scrum ?

Earned Value (EV) is a metric which answers the question: "What did we get for the money we spent?". We could relate this in scrum as a measure of stories done vs. the original sprint commitment expressed as a percentage.

Using the EV leads to an outcome of success or failure(i.e if >75% team succeeds the sprint, less than that the team fails). This is often misused because if pushed, the team will tend to either under commit or over estimate tasks.

EV can be put to use in a scrum environment if required but we should be careful to not push the team to meet a certain percentage and ensure term "failure"  is never used.

How do I measure project progress?

Project progress is measured using a release burn down chart. A release burn down chart is a graph which visualizes total points remaining for the release at the end of each sprint.

Is there a Work Breakdown Structure(WBS) in Agile
PMBOK definition of WBS is "a deliverable-oriented hierarchical decomposition of work to be executed by the project team to accomplish the project objectives and create the required deliverables". WBS is based on all the activities required to be accomplished in the project (e.g., requirements definition document, design specification document).

In Agile all work is organized as end user functionality refereed  to as user stories. Each user story represents work to deliver the increment of functionality and add business value.

During planning, agile development is inclined to a feature breakdown structure (FBS) approach instead of the work breakdown structure (WBS). Feature breakdown structures are advantageous for a few reasons:

- Help with communication between the customer and the development team in terms both can understand.
- Allow customer to prioritize the work to be done based on business value.
- Enable work tracking against the actual business value produced.


There are a lot more question than what I have listed. I will leave this blog here and would would like to hear from readers on the questions your encountered and learn from your experiences.

Please share your experiences and comments.

Retrospective for a distributed team.

I have been conducting retrospectives for quite some time now have been always looking at exploring ways to get better at them. In this blog I would like share my experience of conducting a retrospective with a scrum team which was geographically distributed. This is my way of conducting retrospectives which has brought me some success and not necessarily the right way. Please feel free to comment and suggest areas of improvements.

My retrospectives are heavily influenced by Esther Derby & Dian Larsen's book Agile Retrospectives: Making Good Teams Great and have always followed the suggested five stage process of conducting retrospectives.

- Setting the stage.
- Date gathering.
- Decide what to do.
- Close retrospective.
- Retrospect the retrospective.

I am a strong believer in the above steps of retrospective and have experienced the importance of the steps crucial for reaping all the benefits of a retrospective.

With a team distributed geographical it is best to hold the retrospective over a video conference. If that is not a option then the alternative which can be easily put to use is have a set of high quality web cams setup at both the locations over skype or other social video chat facilities easily available. I use the video chat software's for visuals only and rely on phones for voice to keep away bandwidth related problems.

Setting the stage
One of the very obvious fears people have about retrospectives is that the ritual will become a negative blame game session. If it does then then it will not contribute to any learning. The key to a constructive retrospective is assuring that all the participants adhere to the retrospective prime directive:

"Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand."

A slide shared across sites using the prime directive seemed sufficient.

Data Gathering

- What went well ?
- What did not go well ?
- What can we improve ?

The above three questions form the crux of a retrospective. Each questions is put forth and the team then discusses, agrees and lists the events in relation to the above questions. I have used a shared excel workbook to capture the events across locations.

Apart from this I also like to capture the sprint mood:

If this sprint was human what would it feel ?
- Happy :-)
- Disappointed :-|
- Sad :-(

I use outlook voting button to capture the sprint mood just before the retrospective starts.

Decide what to do

Having captured events and ensured everyone in the team has had a chance to speak is an achievement in it self. With limited time available the next challenge is to choose items for improvement in the next sprint. I always suggest the team to 1-2 or a maximum of three items for improvement in the next sprint to avoid an overload.

How do we decide in a distributed team ?
Well voting with dots is the best way to do it in a collocated team. I case of a distributed team I would capture the votes on a excel sheet. You can allocate 5 votes for each team member, they could then use the votes as they like on the events listed. Team members have the options to place one or more votes for an event. Once every one has had the chance to vote you can then easily identify the items which need immediate attention and seek volunteer pairs to take actions on the improvement areas. I am suggesting a pair takes ownership to enable better collaboration within the team.

Close Retrospective.
I like to close retrospective with a thank you note to the team and also give an opportunity to any one in the team including PO if present to speak.

Retrospect on the retrospective.
Continuous improvement is the essence of being Agile and retrospectives also need improvement, spending a few minutes to discuss how your retrospectives can further improve will enable you to gather feedback and discuss ways to make your retrospectives better.