Tuesday, January 29, 2013

Finding the value

What is the most valuable goal of  a project?  A software project is usually about getting the users features that they will enjoy and that will make them more productive, getting it out on time, and making it work well.  But what is more important:
  • making users happy
  • getting more users to use the application (but not necessarily elated)
  • hitting the deadline
  • never making a mistake
  • being able to trace and correct every single mistake on the back end
  • ... lots of other choices?
"All of the above" is never a good answer, because time and expertise are limited resources.

Sometimes an organization will have a clear preference, based on its overall culture and nature of the project.  For example, some systems are deadline-driven, such as software that supports Mother's day or Christmas sales season, systems used in elections, tax-preparation applications.  In others, being able to trace and correct an error is essential, for example, in software dealing with money.

However, in a lot of cases the project owner faces a choice, and being aware and deliberate in making that choice can make or break a project.

Tuesday, January 15, 2013

Agile steps

The teacher looked a bit glamorous and very assured of himself.   “The most important thing is steps.  We do a step forward, a step sideways, a step backward, and another sideways.”   The class tried, lots of stepping on other people’s feet ensued.  A few students missed the first bit, and found themselves off by a step, confusing their neighbors.   

A brave soul raised his hand and asked out loud: “What if people next to me are doing something else?” The teacher responded with authority: “They will know to do these steps.”

A lot of Agile learning takes their students through similar ordeal.  Steps are shown, expectations are announced, and students are told that the rest of the world will just fall in line.  With that people are sent out to their regular workplaces and teams to create beautiful new work successes with Agile. 

Class discussion is often framed differently than in the real world, and there is a lot of pressure to agree with the teacher and with the other students.  Make no mistake, a group of professionals taking an Agile training does not represent a regular workplace crowd, a typical organization, or a normal project team. Students participating in an Agile class are different in that they all agreed to learn Agile, are curious and open-minded enough to consider a different work philosophy and methodology, and are willing to challenge themselves with training.   

When the class is over, and everybody goes back to work, the students will need something other than just Agile steps or procedures to guide their every day work. If the organization is serious about switching to Agile and getting the benefits of the new approach, everybody needs to get the underlying philosophy, the ways to get into the rhythm and on the right step.  The team needs to be able to stay in sync,  while realizing that someone will inevitably drop the ball and require help.  When going through training in Agile, practitioners must learn to realize when they’re off beat, when other people are off, and how help the team to all follow the rhythm.    

Steps are necessary, but they are simple and easy to do. Agile training should be about being and doing Agile in the real world, where someone will always be off-beat, and not know the steps.    

Registration for AgileDotNet 2013 in Dallas, TX is open now - the most advanced discussion on Agile and technology in the real world.