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.