A few good quotes

  I have been reading

Agile Project Management: Creating Innovative Products (2nd Edition)  and in this book, Jim not only refers to a few good quotes by other authors but also has made many impactful statements.  The book provides views on Agile Leadership, Team Management and Agile Project Management. 

A few good quotes that I liked from the initial few chapters include

 

* Traditional managers view the plan as the goal, whereas agile leaders view customer value as the goal

*

Commanders know the objective;

leaders grasp the direction.

Commanders dictate;

leaders influence.

Controllers demand;

Collaborators facilitate.

Controllers micro-manage;

Collaborators encourage

* Leadership is what crosses the frontier between what we did yesterday and what we’ll do tomorrow. We’ll argue…that the real mark of a leader is confidence with uncertainty—the ability to admit to it and deal with it.”   - Phillip Hodgson and Randall White

* Agile project leaders help their team balance at the edge of chaos—some structure, but not too much; adequate documentation, but not too much; some up-front architecture work, but not too much. Finding these balance points is the “art” of agile leadership

Does it make sense to use MS Project in Agile Projects ?

 

 

 

 

 

 

 

It is a tradition to use MS Project as a Project Management tool in Waterfall projects. However, trying to use MS Project in an Agile project makes the lives of the developers more difficult than easy. 

There are several reasons for that and a few based on my personal experiences are..

1. Adding new tasks in between as they get discovered during the sprint causes havoc while using the tool

2. Tracking  story and task completion in the context of sprint is difficult
3. Moving around the incomplete stories and tasks to different Iteration makes the project plan chaotic
4. Picturing  Product and Sprint Backlogs while using MSProject is not so easy

In addition to above reasons, Michael Dubakov has written an article explaining why MS Project sucks in iterative development projects.

Rise and Fall of Waterfall Model

 

 

 

Craig Larman’s most popular book  Agile and Iterative Development a Manager’s guide  covers the topic about how Winston Royce’s white paper was misinterpreted which lead to the birth of Waterfall Model.

 

 

Incidentally an Agile practitioner has created a video explaining the birth and death of waterfall model in a humorous way.  The video is

available on YouTube

Balancing Organizational and Project Goals

In many outsourced(near shore or offshore) services organizations, employees are expected to take part in activities that are outside the purview of their projects. These activities are intended to support organizational growth in someway or the other. A few of such activities are

Conducting interviews for hiring new employees,
Taking team out for lunch/dinner,
Arranging an offsite meeting,
Conducting trainings, events
Publishing whitepapers, attending conferences, etc

The above mentioned activities need effort, and this effort needs to be accounted some where. Naturally, one might get few questions like:
Should one track these tasks in Sprint Backlog ?
Should one keep the customer updated about these tasks ?
Should this be estimated as part of Planning meeting ?

Being Agile practitioners, it is expected that the team should practice as much transparency as possible in estimation and tracking. Keeping this in mind, one should estimate the effort being spent on such activities during each iteration and capture it as part of a task in sprint backlog. This also ensures that the customer is aware of these non-billable activities at the same time, IEH and velocity counts are captured accurately.

It is not a good idea to mask these activities and also not informing the customers. This would not only affect the credibility of the team but also forces the team to stretch themselves to compensate for the lost time.

Image: djcodrin / FreeDigitalPhotos.net

Scrum Meeting – Punishment by collecting $ is it the right way ?

One of the first rules of Scrum Meeting is to ensure that it is conducted at the same time every day at the same place. It also expects that the team members should come on time to the Scrum Meeting.

Typical practice is that, late comers to the Scrum Meetings should either wear a joker cap or pay a $ as punishment for arriving late. However many thought leaders share that these practices of punishment is bad and it is not going to improve the situation or change the behavior of the late comers. Worse, Thought Leaders proficient in Intrinsic and Extrinsic Motivation, believe that, over a period of time the extrinsic motivators(reward or punishment) actually reduces the intrinsic motivation.

* So, what should we do in this situation ?
* How do we handle the late comers ?
* Should we ignore them ?
* How do we make the late comers for the Scrum meeting to come on time ?

The answer seems to be not easy. Researchers believe that there is no one formula that could be used to motivate every one. If some one is not coming on time to the Scrum meeting means either he/she is not interested or does not believe in these meetings and could be something else. One needs to identify the root cause of lack of intrinsic motivation and work on an individual basis rather than applying the same reward/punishment formula.

Cognitive Evaluation Theory and FLOW seem to provide some insights to improve the Intrinsic motivation.

Retrospectives in Agile Multi Site Development

Unlike other Agile practices, Retrospective sessions involves a lot of
emotions. Emotions could be easily understood(also handled) by looking at the body language of the people around us. However, in a distributed development projects, teams are scattered across various locations and this in turn makes it hard to understand the body language. This is one of the reasons why it takes more time for the scattered teams to bond with each other and thus reducing the efficacy.

Even though no tool or technique can replace the experience
emanating in a collocated team, there are a few that could

be practiced to improve the effectiveness of distributed retrospectives.

From the logistics perspective, one or more of following tools
could be used

Tool Name	Effectiveness
Voice chat through Wired phones, typically what is termed landlines or using popular tools like Skype, Yahoo Messengers, etc   without  Web cams	Low
GoogleDocs, Wikis in addition to voice chat and no web cams. Download the GoogleDocs Retrospective template from here	Low
Web cameras connected to tools like Skype or Office Communicators in addition to use of Google docs, Wikis,etc	Medium
http://www.CardMeeting.com Using this in addition to voice/video tools increases effectiveness	Medium
http://www.Dabbleboards.com Using this in addition to voice/video tools increases effectiveness	Medium
http://www.IdeaBoardz.com Using this in addition to voice/video tools increases effectiveness	Medium
http://www.IdeaScale.com Using this in addition to voice/video tools increases effectiveness	Medium
http://www.mindmeister.com Using this in addition to voice/video tools increases effectiveness	Medium
http://www.etherpad.com Using this in addition to voice/video tools increases effectiveness	Medium
http://en.linoit.com Using this in addition to voice/video tools increases effectiveness	Medium
Telepresence and Video Conferencing kind of tools  in addition to one or more of above mentioned tools	High

 

Note: Some of the above mentioned online tools could also be used for other Agile practices like Requirement gathering, brain storming, design discussions in distributed mode.

 

Patterns

Two popular patterns of distributed retrospectives include
1. All hands Retrospective
2. Location Specific Retrospective

In case of All hands Retrospective, all teams participate together
using one or more of above logistics. This pattern works well if teams
are located in same or closer time zones. May not be a good idea to apply this for larger teams . 

Location Specific Retrospective, In this pattern, location specific
teams conduct retrospectives and then the leads from each of these
location conduct “Retrospective of retrospectives” synching
Sad/Mad/Glad data. Larger teams (>15) can apply this pattern.

Test Driven Development for Embedded C++ Programmers

 

Src:blog.briandicroce.com/2008/03/

A lot of articles are available explaining TDD for Java and .NET. However I rarely find “good” TDD articles for C++ and C. 

James Grenning explains TDD for embedded C++ programmers in a step by step approach in this article

Comparison of Heavy and Lightweight methodologies

 

Several articles have been written comparing the heavyweight and the lightweight methods. 

However, I found this document to be very comprehensive in comparison.

 

 

The document compares the Heavy Weight methods like
Waterfall, UP and Spiral Model  with the Light weight methods like

  XP, Scrum, FDD, DFDM,etc. 

Building Generalized Specialists

The topic of  Generalists Vs Specialists is another eternal debate in the Agile community. Every one in the community has their own opinions.  I too have my personal opinion about this topic. 


Let me start this discussion with a few definitions.

Put it in a simple way,

 

A Specialist is some one who knows a “bit more” about something. In the context of the software world, this something could be Architecture, User Interface Design, Testing, Coding, Business Analysis, etc

A Generalist is some one who knows a bit about many things

The question arises, should we have specialists in the team or generalists in the team.   Each of these techniques has its own pros and cons as explained in this article.

My opinion is that, every individual is passionate about something. Some times they get to express it and get opportunity to pursue the same, and many won’t get this chance. People pursuing their passion end up becoming true specialists. However at the end of the day, every one in the software company gets a designation whether they like it or not, and end up becoming specialists.

Is there a problem being a specialist ?

Many Agile evangelists say specialists are not good. However what they mean is bottlenecks created due to specialization is not good. Bottleneck arises due to demand and supply issue in the organization/project.

Let me give you an example, most of the software companies (that I have seen so far)  have limited number of  Architects and Database administrators and mostly these roles are shared among various projects. Consider a situation when the Oracle DB admin who is currently been assigned to a new project is at the client site gathering requirements. At the same time, a critical bug was detected in one of the DB modules that he worked on an earlier project and this is a show stopper.  This is a challenging situation right ?  How can we make use of the DB admin in handing this situation as he is the only one available.

Let us review couple of options on hand

 

 Option 1:

Pull the DB admin for a few weeks from his current assignment and reassign him to the defect until it is fixed.  But doing so might make the current client unhappy

 Option 2:After completing the current assignment, go back to earlier project, understand the defect and fix it.  This may not be possible as the defect is critical and needs immediate attention
 Option 3:Split time between the current requirement gathering work and fixing the defect.  It has been proven that  multi tasking reduces efficiency and productivity.      

Situations like the one mentioned above where the specialists have become bottlenecks have made the Agile thought leaders to encourage generalized specialists.

How to build Generalized Specialists ?

While I coach teams, I observe that if specialists are going to be shared across projects and by this I know that in the future they would end up becoming bottlenecks.In such instances,  I apply what is called “Backup Pattern”. This pattern name is my own invention. While applying this pattern, I start analyzing the skills and passion of various team members and start making each one back up for the other.  This provides an opportunity to have backups(in knowledge and skill) and over a period of time, these backups will be in a position to handle most of the specialists tasks.  However the same backup personnel  would continue to have their own specialization. The team members could volunteer to be backups.

Here is an example of a table showing my backup pattern technique

 

Module Name	Skills/technology	Primary	Backups
Billing	JSP, Java, Hibernate	Rashmi	Rohit, Chandru
Dynamic IP Generation	Java, C++, Tcp/Ip	Jim	Chandru, Rashmi
CMTS configuration	WAS, TCP/IP, REST, XML	Chandru	Jim, Rohit

Above technique has helped me in tackling the issues of specialization. This is not a quick fix, and it takes any where from couple of weeks to months to build a generalized team.

Conclusion

Having an extreme form of  all Specialists or Generalists is not healthy for any project.  There should be balance between these two types  and decision to have generalists or specialists should be based on specific context.  

Requirements considered harmful

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.

The Rise and Fall of the chaos report

 

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 

Day 2 of Agile Bengaluru 2010

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.

Day 1 of Agile Bengaluru 2010

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,Personas

An open source Agile Project Management tool - Express

Came 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

100 Impediments while implementing Agile methods

Every Agile project has some impediment in one form or the other.

• It could be the organizational policy like individual appraisals and rating encouraging competition among the team members killing the team unity
• People related issues, like the command and control Scrum Master not letting the team to make decisions
• Tools and environment issues like the lack of automation and lack of skills in using tools,etc

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.

Recommitment cost - Waterfall Vs Agile

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.

1. Option 1: Inform the customer immediately and face the consequence
2. Option 2: Don’t inform the customer and try your best to fix the problem over a period of time.

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.

Tim Lister on Agile Leadership

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.

Agile Bengaluru 2010

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:

• David Hussman
• Jeff Patton
• J. B. Rainsberger
• Naresh Jain

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.

Moving from Waterfall to Agile – Some tips

 

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
    Managing Change
    Organized Change
    12 Important elements of change management

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.