Jeff Patton kept talking about usage of the word Requirements considered harmful during recently concluded Agile Bengaluru conference. When you listen to Jeff from his context and examples, you tend to nod your head in agreement.
Jeff has written a very nice article about the subject and I don’t want to copy/paste the article, and go ahead and read it here.
One of the most popular reports people use to showcase failure of software development is the Standish’s chaos report .
In 1994, Standish reported a shocking 16 percent project success rate, another 53 percent of the projects were challenged,and 31 percent failed outright. Even though the new reports from Standish show better numbers still they cause a lot of heartburn to software companies and investors.
However recently J. Laurenz Eveleens and Chris Verhoef have published a paper in IEEE challenging the numbers stated by Standish report. The major problems in the Standish report seems to be around the way numbers for the Successful and Challenged projects are gathered. According to Eveleens and Verhoef, these Standish figures are:
“misleading, one-sided, pervert the estimation practice,
and result in meaningless figures”
The problem seems to be coming from the way the Successful and Challenged projects are defined. The definition seems to have loop holes due to which many valid projects are not considered leading to wrong result.
You can read the entire IEEE report here 
I attended TOC and JIT session . This session was intended to teach Theory of constraints and in turn identify the bottlenecks in projects. I liked the way the session was structured.
This session also included a small hands on workshop where in the participants form small groups and would pick a project to work on. Within each group, the participants would work on identifying the bottleneck and how throughput could be increased by reducing the cycle time.
I also got a chance to listen to Jeff Patton during one of the breaks.
I had a few Aha moments while listening to Jeff. Here are some points which has put me to ponder for the next few days
1. Requirements are considered to be harmful. Read Jeff’s popular whitepaper here to understand why he says so
2. The projects would always lead to failure as long as we have the You and US mentality between the customer and the software development team.
I also got a chance to meet Bas Vodde, 
who happened to be in Bangalore and just walked in to say hi to Jeff and Dave.
Bas and Craig Larman (my Guru) have written 
various books and white papers. I highly recommend the recently released book Scaling Lean and Agile. 
Just returned home from the ASCI Agile Bengaluru 2010 session. The event was well planned and organized.
The session started with David Hussman’s Discovery and Delivery - Redesigning Agility.
I realized that every presentation by Jeff Patton and Dave revolved around discovery and Delivery.
Next session that I attended was by Jeff Patton. He is a very knowledgeable guy and I enjoyed his session on User Story mapping. More info about this technique can be found here.
Here is the gist of the session
Most of the time people relate Features to User stories, which is a big misunderstanding. People with this misunderstanding, and continuing to gather requirements in the name of user stories would end up creating bucket of features list.
One of the key point I learnt from Jeff’s session on User Story mapping was the importance of the good facilitator. During the user story mapping workshop, he was able to gather the stories by asking the right set of questions.
Don’t get bogged down by the formula
Nowadays it is increasingly becoming popular to follow the user story template
As a [role], I can [feature] so that [reason]
However, Jeff made it clear that there is no harm in using the above template however don’t get bogged down with this formula. Understand the intent behind the above template and create the stories in your way.
Jeff also touched upon the importance of Personas.
Blogger Labels: Agile,Bengaluru,ASCI,Delivery,presentation,Jeff,Patton,Dave,User,Story,info,technique,Here,gist,Most,Features,People,requirements,bucket,importance,facilitator,workshop,formula,Nowadays,template,role,Understand,PersonasCame across this new Open Source project management tool called Express. This tool seems to be still in beta development.
More details below,
Express is an Agile project management tool. The web application is written using Flex while server-side component is a Spring based Java EE application.
You can download the same from here
Following are some of the screen shots of the application
Backlog management screen
Virtual wall
Every Agile project has some impediment in one form or the other.
We could list out many more...
I came across this article which lists 100 impediments that is constantly seen on Agile projects.
This website classifies various impediments into categories.
Whenever some one makes a promise, the cost of apologizing begin to grow. Whenever one feels that promise cannot be kept, the cost of recommitment starts to grow. The cost depends on the stage at which recommitment is done. If the apology and the recommitment is done at an early stage, the cost is going to be less. If not, it is going to grow exponentially inflicting economic and emotional damages to the people involved.
Consider a situation where a Project Manager(PM) of a software company promises to deliver a component on a certain date to the customer. During the development, if something breaks down(and the remedy to this problem is beyond the control of the PM) then the PM has two options in front of him/her.
With the option 1 above, customer may or may not become happy to hear about the problem. Some customers are happy to see the PM bringing the problem to their notice at an early stage. This in turn provides them an opportunity to make alternate arrangements in the face of this problem. However, a few customers could get upset as many of them don’t like to hear about the problems.
Option 2 is typically applied when there is sufficient time for delivery. Since the customer is not aware of the problem, the PM could assume that some how he/she would take help from somewhere and would fix the problem before customer notices it. Since customer is not aware of the problem and sufficient time is left, there is no pressure to fix the problem immediately.
Option 2 mentality is typically seen in Waterfall development teams.
As per Fred Kofman, most of the teams who follow Option 2 fail in some way or the other. He continues to say that,
Unfortunately these hopes do not always become realities. The work falls further and further behind, while the creditor is in the dark, unable to hedge against a risk he knows nothing about.
Fred calls the hope of people with Option 2 thinking as Self serving rationalization.
How does this relate to Agile ?
The Agile practices are structured in such a way that, opportunities are provided on a daily basis to bring up the issues upfront. This could be either through the Scrum meetings, reviews, or retrospectives. This is nothing but exercising Option 1 mentioned above. This in turn removes any hopes fulfilling self serving rationalization and in turn reducing the cost of apologizing and recommitment.
Recently I watched this informative video by Tim Lister in which he speaks about Agile project leadership. I would highly recommend this video for all Agile practitioners.
As we know, Tim is the author of the two greatest books of this decade. They are
I made some quick notes for myself while watching this video, and thought would share the same here.
1. Process is something you do naturally. Real process is something you do when you are under pressure.
2. A Leader is someone, who by dint of words and or deeds,influences the behavior of others
3. Great Projects have emotions
4. Software development could be compared to an orchestra. Both Orchestra and Software development involves different types of people, and even if one or two don’t perform well, everything goes for a toss.
5. It is really hard to hate when you know the name
6. Cross Pollination is critical. Ex: Americans and Canadian. Even though they speak the same language, still they feel different.
7. Question: How do you keep the teams motivated ?
Tim : Teams thrive on Interesting Problems. Teams cannot be motivated by giving more salary.
(Rephrased in my own words) For ex: if some one is given 2000 USD rise, the developers won’t jump in and say that from today onwards I am going to be more productive. Maximum thing they would do is call their family and take them for dinner and forget it as though nothing has happened.
8. Every leader has to groom another great leader
9. in Hitachi, every project team has to try something different. The management rejects if the project planning is done in a way similar to others.
10. CMM is score card to rate the process
11. If you are just doing what Agile methods say, you are already at CMM level 3
12. Hockey is Un-Choreographed Ballet Dance. This could be compared to Agile. While on the field the players have to think about various situations and make dynamic decision. The coach cannot guide each and every move of the players.
The Agile Software Community of India (ASCI) is organizing the 2nd Annual Agile Conference in Bengaluru on 22nd and 23rd Jan 2010 named Agile Bengaluru 2010.
For the first time in India, we’ll have 4 Gordon Pask Award Winners at a single conference:
The conference theme this year is “Post-Modern Agile - Be done with the Dogma“. The conference is really targeted at Agile practitioners, who want to explore ideas beyond the basic Agile stuff.
Also this year, for the first time, we are hosting the World-famous Programming with the Stars contest during the conference.
After the standard proposal submission and review process we have the final conference program published - http://www.agileindia.org/agilebengaluru2010/agile-bengaluru-2010-program.htm.
If you are interested in participating in the conference, hurry up and register for the conference here: http://www.agileindia.org/agilebengaluru2010/agile-bengaluru-2010-registration.htm We have limited 125 seats total.
Also for those who cannot attend the Bengaluru conference, don’t worry. We have another conference in Mumbai. Check out: Agile Mumbai 2010 Conference.
Please use the #agile_bengaluru_2010 Twitter tag.
If you want to make enemies, try to change something - Woodrow T. Wilson
Transitioning from waterfall to Agile is not only a big change but also a change that needs to happen at an organizational level. Leaders leading such changes need to have a clear vision about the end goal and need to effectively communicate the vision to all. Lack of clarity in the vision and communication leads to creating more enemies than friends.
A CEO of an organization could command all projects to start practicing Agile immediately. Most of the employees have no choice but to follow the command. However employees who are not sold to this idea won’t be doing the work by putting their heart and soul in it. This change will die down over a period of time and such organizations will never be able to bring a new process change like Agile.
In order to effectively bring Agile into an organization, one has to identify the areas of resistance and meticulously handle them.
Always remember
Resistance creates Persistence
Here are some of the tried and tested techniques for bringing organizational changes :
Share the big picture with the employees Share the reason for the change and its benefits for the organization Trust the team implementing the change Do an incremental change rather than big bang approach Provide the necessary support for implementing change (logistics, training, etc)
Understand the groups who could resist the new changes and tackle them
Some great articles have been written by various thought leaders about bringing organizational change. Here are some of them:
Communicate, Communicate, Communicate
Leaders do mistakes while bringing process change (like Agile) into organization. This article lists the common mistakes that leaders do while implementing the change.
Summary
An organization deciding to embrace Agile shouldn’t rush with the big bang approach. One needs to have patience and use the incremental approach.
My experience in helping organizations in transitioning from waterfall to Agile says, it could take any where from couple of months to a year or two for a complete transition.
