Nice Article on Agile Contracts

Here is a nice link on various types of Agile Contracts (Fixed Price, T&M, etc)

Software Development Vs Construction of the house

A house is being newly constructed in front of my house. I have been watching this from the last few weeks. One day, I saw the owner with the architect at the site discussing about something for a long time. I am assuming the owner was trying to explain his requirement to the architect. After few days, I could see the plan with the architect and he discussing the same with owner and making corrections. After a while, I could see some construction workers starting their work by digging the foundation, building the house wall by wall. I know that this is pretty much the same process everywhere no matter where you are. Most of the time, the house gets constructed within the budget and within the time.

I was wondering, why can't we follow a similar process in Software development. In software too, we have the product owner, architects, etc. Why can't we deliver the software within the budget and on time (atleast 50% of the time).

I know we can't in software, here are some of my thoughts:

1. During house construction, there is mostly freezing of requirements during the initial stages

2. In waterfall model, freezing of requirements was tried and we know it was a failure. In agile methods, we tend to keep this open and ask the customer to prioritize and give the requirements.

3. Advantage in software development is, the customer can change his requirement at any time. So, there is a huge responsibility on the software architect to have a flexible architecture.

4. During house construction, since the requirements are frozen, there is a little room for the owner to change his requirement once the foundation is laid. It does not mean that the customer should not Or cannot change. But the key point to note here is "Cost of change" in house construction is more than in software development (assuming robust architecture is in place !!)

Good Books on Agile

Here is the list of some of the good books on Agile software development and related areas. I am hoping to keep this list updated:

1. Agile and Iterative Development by Craig Larman
2. Agile estimation and planning by Mike Cohn
3. Extreme Programming Explained
4. Test Driven Development by Example
5. Pair Programming Illuminated
6. Agile Project Management with Scrum by Ken Shwabber
7. Agile Project Management by Jim Highsmith
8. User Stories Applied by Mike Cohn
9. Rapid Development
10. Crystal Clear
11. Goal
12. Critical Chain

Scrum Vs Traditional Project Management

Here is a nice article comparing Scrum with Traditional Project Management

Traditional PM Vs Scrum Master

When agile methodology(specifically Scrum) is introduced into an organization, first question that is discussed is about the scrum roles. Many of the Project Managers(PM) get worked up about their new role as Scrum Master(SM) and lack of clarity around this new role(SM).

There are a lot of misconceptions and misunderstanding about role of SM. Most of the questions comes from the statement that "Scrum Master has no authority". It is the inherent nature of human beings to "Control" things around them. PMs start connecting that "No authority" means "No control". They feel powerless.

Some of the common functions executed by traditional PM include:

1. Assigning tasks to the development team
2. Estimating the features and tasks(by sitting with architect or tech leads)
3. Resolving conflicts among team members
4. status update on behalf of team members with the customer
5. Time sheet management
6. Resource management
7. Change request management
8. Single point of contact for the management for anything related to project
9. Single point of contact for the on site team for anything related to project
10. Leave approval

and many more...

Responsibilities of Scrum Master include

1. Ensuring that everyone follows the scrum rules
2. Bringing the scrum team and product owner together
3. Removing the impediments from the project
4. Helping the team to move towards self organization
5. Servant Leader
   

If you compare the roles of PM with SM, you could see that many tasks are missing in SM. Who would do those tasks ? Everything lies with the team. This is exactly the reason why self organizing team is critical for success of projects practicing Scrum.

It is critical that traditional PM is convinced and has understood the roles of SM properly. Any misunderstanding leads not only failure of the project but also, failure of the entire team in implementing agile. Traditional PMs with half baked knowledge of Scrum Master role would be causing more harm than anything else.

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.