Pages

Friday, January 26, 2007

Nice Article on Agile Contracts

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

Wednesday, January 24, 2007

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 !!)

Friday, January 19, 2007

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

Saturday, January 13, 2007

Scrum Vs Traditional Project Management

Here is a nice article comparing Scrum with Traditional Project Management

Tuesday, January 09, 2007

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.