Can velocity be used to measure Productivity ?

I have heard many managers in software companies trying to measure productivity based on Velocity of the team. I think it makes no sense.

Here are some of my thoughts:

1. Velocity is measure of team's capacity to deliver certain functionality within a specified interval. This definition makes it clear that, one cannot use the velocity as the stick during appraisal and performance evaluation for individual members.

2. You cannot use velocity to measure the productivity between teams also. Reason being, each team is different. Two teams with 10 developers each, cannot be compared. Each team would come from varied years of experiences, domain knowledge, maturity, support from product owners, communication skills, etc.

Toyota and moment of Zen

Here is a very good article for all who would like to improve on a daily basis. I could related many of the practices in this article to scrum meetings and retrospectives. Must read for entrepreneurs and managers to create a learning organization.

http://www.fastcompany.com/magazine/111/open_no-satisfaction.html

Velocity and more

Here is nice article from Mike Cohn about Velocity

I find that one of the most common mistakes teams make is to use the
term "velocity" to refer to both
--the number of points (or ideal days) finished in a sprint
--the amount of planned work completed in a sprint

It is far more useful to use velocity to refer to the amount of
points finished in a sprint. The amount of work planned in a sprint
will be relatively constant sprint to sprint. This is essentially the
Y (vertical) intercept of a sprint burndown chart. If you need a term
for that call it "capacity." The tough concept for some teams to get
is that capacity (# of hours of work planned into a sprint) isn't
clearly correlated to the # of hours worked in a sprint. To make it
simple, consider me a team of one doing a one-week sprint. I will
work 40 hours this week. If I'm a perfect estimator (impossible) I
can say "I'll answer email for 20 hours this week (I wish!) and spend
20 developing; let me pull in 20 hours of work during sprint
planning." However suppose I'm not perfect and that my backlog items
have some uncertainty. Over time I may find that when I see a pile of
work and say "that's 15 hours" that this is the amount that perfectly
fills up my 40 hour workweek. I may get 25 hours of time on task to
do what I called 15 or I may get the 15 done in 12. It won't matter.
What matters is that what I call 15 fills up my week. That's how to
plan sprints and to work with capacity.

Pros and Cons of conducting retrospectives

Here is a nice article about retrospectives

Retrospectives

Written by willem

Tuesday, 14 February 2006

After an event or project, all the stakeholders come together to celebrate the successes of the project, and learn from failure in a constructive manner without finger-pointing. After a retrospective participants have concrete actions for the next event or project, and can contain broader organisational change. Retrospective benefits: Closure Learning from our own mistakes Learning from someone else's mistakes Acknowledging aligned practices and accomplishments Rewriting organizational stories Learning a healthy ritual Discovering strengths of the organization Clarifying aligned roles for players Allowing to connect emotionally Challenging each others assumptions Providing an overview of what's actually happening in the organization Building trust across boundaries Clear results, that lead to realistic commitments Retrospective risks: Emotional upset Unrealized expectations Lack of follow up leading to frustration and distrust Last minute sabotage Repercussions and retaliations Loss of control at the top Increase in awareness of personal responsibilities and accountability And of the chasm between responsibilities and accountability Can be a life style changing event Discovering that you waited too long to do aretrospective Discovering some of your assumptions are invalid Risks of not doing retrospectives: Emotional upset piles up Repeating mistakes over and over again Carrying forward unhealthy relationships Not using an opportunity for sustaining and reinforcing best practices Lack of adaptivity Less access to hidden wisdom Not having your assumptions challenged Would have could have should have thinking Learning organization is not learning Getting stuck in causality loops Less access to hidden resources Retrospectives can provide lessons on architecture, planning, communication, product information flow and possible early intervention points.

Tips on Iteration Planning

Stumbled upon the 17 tips to iteration planning . Even though there are more to it, one can add, but definitely these are the ones to start off with !!

Dos and Donts during Planning Poker

Here are some of the tips that could help during planning poker estimation sessions

1. Ensure that all developers show the estimation cards in one shot. If the cards are shown serially chances that it could lead to "estimation influence" factor.

2. Don't sit in crumpled space during this session. Try to use a large room, and people sitting in such a way that they can see each other

3. People who have no idea of use case or requirements can opt out of the session. They need not be forced to be present.

4. Have a spreadsheet open and the computer connected to a projector ready. This would help all the team members to see the requirements clearly.

Please note that, Planning poker estimation, even though more light weight and accurate than other estimation techniques, it could lead to in accuracies. The inaccuracies results from inadequate estimations in the technology or domain that they are working on.

Pair Programming benifit in a short sentence

Pairing takes about 15% more effort than one individual working alone, but produces results more quickly and with 15% fewer defects [Cockburn & Williams]. Fixing defects costs more than initial programming [Boehm], so pair programming is a net win. -- Jim Shore

Relation between Sales men, Process and project delivery

Is there any relation among sales men, Process and project delivery. Whether you agree it or not, I strongly see a relation here. Consider a scenario where, the sales person bids a project for a software organization, and gets the project. Now, the job of the salesperson is over, and the next step is for the delivery team to take responsibility and deliver the project on time to the customer.
As we are aware, project delivery is controlled by the scope, time and cost. Any change happening to one or more of the parameters has impact on others. If the time is committed to the customer as in fixed bid fixed time project, then we need to ensure that scope and cost are also in line. If the sales person has gone and committed a particular time line to the customer making assumptions on estimations, it is going to directly impact the delivery and the developers have to go through terrible stress (assuming he is over committed) during implementation.

Let us talk about the impact of above two parameters onto process. Let us take the project following agile methodology. Estimation in agile projects is done using IEH(Ideal Engineering Hours). In the projects I have seen, IEH is anywhere from 6-61/2 hrs per day.
What if sales person is not aware of the IEH and sells the project with 8 Hours per day in mind ? Who will work that extra 1 1/2 hours committed by the sales person ? How do you compensate for this ? I know that you know the answers to above questions !!!!

Eye contacts in Scrum Meetings

I found this nice article by a blogger Abrachan:

When a team is transitioning from the conventional predictive project management to the adaptive style based on SCRUM method - very often it is like releasing a parrot under captivity. Suddenly the parrot gets absolute freedom and at the same time it is not conditioned to enjoy the new found freedom. It still thinks that it is under captivity. It has to strengthen the muscles required to fly in a world of unlimited freedom and opportunities to excellence.

When the daily scrum meetings happen, most of the members - if they are new to the team, still follow the reporting attitude - and keep reporting what I am supposed to do, What I did and the problems I faced - to the SCRUM master only, without any eye contact with the rest of the team. Even if the SCRUM master do not want to be seen as a command and control freak, the rest of the team still see him as a command and control freak - which is hang over from the previous predictive project management styles he/she was practising. One of the very effective tactic (fix) to de-promote this behavior by the rest of the team is to avoid the eye contact with the person who is `talking to you' in a SCRUM meeting, thus forcing him/her to look at the rest of the team members - contributing to the 'self directed team' spirit. :-)

Agile Offshore Development tip 3: 3 Key tools in Offshore development

From my experience, I found that the 3 key tools that are contributing towards improved communication in offshore development using Agile methods are:

1. Wiki (Any wiki should be fine, and we use Confluence by for the best wiki I have seen so far)

2. IMs (Skype, Yahoo, MSN)

3. IP phones (We use Cisco IP phones)

Does Agility improve design of the product ?

Like Waterfall model, Agile methods are also grouped under "process" umbrella. In fact, Agile methods are much more than this. Waterfall model provides a set of steps and guidelines on how to do software development and it has no impact on what technologies you use, and how you design or architect the software. But, Agile methods in turn has a huge impact on how you design and architect software.

In agile methods, Features are built incrementally in iterations and it is expected that the components are also built incrementally. This in turn forces the designer and architects to make conscious decisions for building modular and cohesive systems. At the same time, the less experienced designers would get entangled in their own web of coupled components and have to struggle to refactor for a longer period of time. They have no escape route !! At the same time, Big Upfront design is not the answer.

Good quote by Guru from Google

Here is a nice quote by Ram Shriram on hiring:

Hire only A people, and they’ll hire other A people. If you hire the B person, they’ll hire C or D people. Someone asked a good question: How did Shriram decide who are so-called “A” people? Grooming is a part of it. “I try to find out who their mothers are,” he said. If they are raised well, they’re more likely to make good citizens, employees and entrepreneurs.

History of Scrum

I was preparing the presentation for the new comers in my company, and thought of doing some research on history of Scrum. I found some interesting information:

1. Scrum is a variation of Sashimi

2. Sashimi originated with the Japanese and their experience with the waterfall model

3. Scrum was named as a project management style in auto and consumer product manufacturing companies by Takeuchi and Nonaka in "The new new product development game" (Harvard Business Review, Jan-Feb 1986)

4. First Documented in 1993 by Jeff Sutherland, John Scumniotales and Jeff McKenna

5. 1995: Ken Schwabber Formalized the rules for Scrum.

How XP(Xtreme Programming) got its name

I found this nice information on devx explaining how XP got its name:

XP got its name when its founders asked the question, "what would happen if we took each technique/practice and performed it to the extreme? How would that affect the software process?" An example of this is the practice of code reviews. If code reviews are good, then doing constant code reviews would be extreme; but would it be better? This led to practices such as pair programming and refactoring, which encourage the development of simple, effective designs, oriented in a way that optimizes business value.

80% of the requirements are clear, do you still need agile ?

Here is a project where the product owner has given a huge set of requirements. Let us say, X, Y and Z. He has given a time limit to the development team saying, you do whatever it takes but I want to see X,Y,Z at the end of one year. The team that has been following traditional waterfall model, decides to move towards agile methods. Inspite of knowing that the requirements wont change much, is it really necessary to follow Agile method ? Or just do whatever it takes to reach the goal ?

Before putting my thoughts on solutions, let me tell you that, this kind of model is mostly seen in product development companies, who already have an existing product and they are looking at enhancing them over a period of time with new versions.

Coming back to solutions:
1. First and foremost ensure that the estimations are in synch with the reality. It should not be that X,Y,Z takes 2 years to do it, and the product owner has given a deadline of 1 year. No matter what process you follow, this product would be a failure

2. Since, Product owner is not available for clarifications and collaboration on a day to day basis, one needs to identify a proxy who can make decisions on behalf of product owner

3. This sample case of product development can never follow all the values and principles of agile. But, they can certainly practice some of the core agile practices.

1. Daily Scrum meetings
2. Scrum of Scrums
3. Product Backlog --> Created initially by the product owner
4. Iteration Backlog --> Proxy making decisions during each iteration
5. Daily builds
6. Continuous integration
7. Usage of information radiators
8. Test Driven Development
9. Feature teams
10. Cross Functional teams
11. Team can work on Self organization
12. They even can have a scrum master
13. Pair programming
14. Usage of dual monitors
15. Velocity based estimation and/or any other estimation techniques

But remember, don't blame agile if you don't succeed in this kind of project environment, as agile methods needs customer collaboration. Without buy in from customers and stakeholders, don't expect agile methods to succeed.

Agile Offshore Development Tip 2: Keep translation time in mind during estimation

If you are working on a distributed development project with teams in countries speaking the same language(For example English, between India and US), you won't face much of problem. But if you are working in a different environment otherwise (Say, between India and Germany OR India and France, etc where they don't speak the same language), you would need to keep the language barrier in mind during estimation. (This sentence is really mouthful !!!)

For example, you might receive a requirement document in German. The customer in Germany assumes that you would do the translation to English before writing the test cases or whatever. The problem here is, the same customer also assumes that as soon as you receive the requirement document you would start the work. Which is not really so.

This is how it works: Let us say the customer hands off the requirement document on Monday, and it takes nearly 3 days to translate the same to English(or local language). (Assuming that you have an inhouse translator). Then ensure that you keep this buffer in mind while doing the estimation. Not only that, if you have a poor translator it would add much more chaos.

Testing team needs to be very cautions in this situation. Sometimes, the testing team might have to struggle for days to get the actual requirement translated to their local language, before writing the test cases. This might add undue pressure on testing team during release days.

Couple of solutions:
====================
1. Try to have as many face to face interactions and conversations as possible with the customer. Try to write the test cases based on "Drop-in meeting" principle. Basically, you can keep updating the test cases in small iterative cycle after every conversation with customer.

2. Bring the culture of using acceptance testing framework like FIT into the team.

When would agile fail ?

Following are some of the situations where agile methods would fail:

1. When Development team is interested in agile methods, and the product owner and his team is not aware of anything about agile. For example, consider an offshore project where the development team is practicing waterfall model. Suddenly one day, one of the leads feels they should move towards agile. The offshore development team start practicing some of the practices bit by bit. They would try explaining the benefits of agility to the customer, but in vain. But the team continues practicing in bits and pieces without informing PO. This would lead to failure. Basically, one needs complete support from the management, PO and other stakeholders for a successful implementation of agile methods.

2. When development team is managed by "traditional" project managers. For example, consider a situation where the development team wants to practice agile methods. If the management is not aligned with it, the team would fall apart. I have heard of a story, where the development team was practicing some of the agile practices. Due to change in project management, the new project manager with a traditional/CMM/Waterfall background started demanding the team to do more work, and started giving them deadlines to finish work. The team almost fell apart.

Ensure that the management is convinced about the benefits of agile methods.

3. Don't practice without a coach. Passion is a critical aspect to implement the practices of agile methods, but one needs to be aware of the value also. One should know the dependency of some of the agile practices. For example, practicing "just" refactoring without TDD cycle would add more problems than any benefits. In such situations, coach could add lot of value to the team

4. Don't try to implement all agile practices at once. Take one practice at a time, play with it for some time before taking on the new ones.

Practice which works in one organization may not work in the other.

Agile Offshore Development Tip 1: Estimate cautiously immediately after a release

I am planning to start a series of "Tipping" session on Agile Offshore development. I work with offshore development teams practicing agile methods day in and day out, and so I keep seeing challenges in implementing some practices.

I am taking this as an opportunity to provide some solutions(what I think as right) for these recurring problems.

Tip 1: If your team is new to agile methodology, then ensure that the iteration planning for the "new" release is done cautiously. The reason being, most of the time the estimation and planning is done based on the velocity of previous iterations. But, when you release a new version of the product to the customer, you could expect some priority defects. These "unplanned" defects needs to be fixed in the upcoming iterations. These defects might have escaped the dragnet of TDD, functional testing, etc. So, consciously take such eventuality into consideration and plan it without just relaying on previous iterations velocity.

TDD Injection in legacy code

In a typical agile team, the team practicing TDD would write the test first, plug the business logic, make the test to pass and refactor the code (RED-GREEN-REFACTOR). This luxury may not be available for teams (legacy teams) who are new to agile methodology, and have a huge code base developed without TDD. This article explains some of the techniques that could help introducing TDD into legacy development teams.

TDD Injection in legacy systems
--------------------------------

1. First step is to, identify the code smells that you would like to attack. You can do this by running any of the freely available code smell/quality identification tool (Checkstyle, PMD,JCosmo, etc)

Once you have the list ready, prioritize the list for developers to refactor. For example, "reducing the lengthy methods" could be of priority than the "replacing the magic numbers with static code".

According to me, not all the code smells could be tackled by the junior developers (2-4 years of experience) alone. Some of the code smells need extensive object oriented programming and design skills. For example, replacing "inheritance by delegation", needs a careful thought. In such cases, the senior members of the team Or developers with good OOAD/P knowledge needs to be involved.

2. Next step is to, consider each of these high priority code smells within each iteration. Allocate time to fix them and in parallel, write the unit tests for those parts of the refactored code. Writing the Unit tests at this point of time and automating them ensures that, the refactored code has not broken the behavior of the system. I would like to call this as "TDD injection" technique.

The reason for "TDD Injection" technique is to not only introduce TDD in the middle of development, but specifically refactoring the legacy code.

3. Some teams specifically allocate”Cleanup iteration" just before each milestone release. This is really not a good way to do agile development, but if the project planning is poor Or in a dysfunctional team, the developers might rush delivering the code to customer without TDD. In such situations, one can reserve a day or two “or” may be an entire iteration (2 weeks, say) for clean up activities.

=== "Something is better than nothing".

Technical Debt

Here is a definition of technical debt got from KenMar's article

Technical Debt is simply deferred work not directly related to new functionality but necessary for the overall quality of the system . Examples of this include:

Some examples include:
1. Refactoring
2. Upgrading the database version
3. Upgrading any other software
4. Getting new plugins