Just in Time or Just in Case?

A huge form of waste that many people don’t talk about are those things that are built “just in case” we might need them some day.

I think that those involved in building a product often times forget that everything that is built costs something.  Nothing is free.  Who’s paying for it?  The customer is.  Everything we do must deliver some kind of business value, either by reducing risk, meeting compliance, cutting costs, increasing revenue, etc.
There are certain phrases that I listen for like “it would be cool if…”, “someday we  might want to…”, etc.  Some tend to want to build to accommodate edge cases that are (many times) so ridiculous that they would never happen.  Now what gets really tricky is when there is only one SME in the product group, and no one else really knows that domain.  In those cases, God help you!  That SME has the power to make you do things that you look back on and say “WHAT HAVE WE DONE?!?!?”.  The only way to get around this is to fearlessly and relentlessly ask “why?”.  In these situations, there is typically a touch of fear that compels the team to bow down and say “yes master, whatever you wish” instead of asking probing questions.

There are some Scrum Masters (and Project Managers) that typically stay out of those kinds of details.  Yes, the team is self-organizing.  Yes, the team has to learn by making mistakes.  However, the Scrum Master has to be involved enough to not allow the “just in case” methodology from taking hold.  If it’s allowed to go on too long, you will have found out that what you have delivered in the end is not what is  valuable now.

Bringing Agile to the Organization

Almost all of the literature out there recommends the first step being finding a “pilot” project where you can use an agile methodology.  The project can’t be too complex, too simple, too large, too small, too critical, or too unimportant. 

I’m starting to wonder if we’re over-thinking this.  Why don’t we decide what to use depending on the project?  If RUP fits REALLY well, then why don’t we use that?  If Scrum fits REALLY well, then we should have the option of using that…right? 
In reality, the only thing that will ever hold back a true agile adoption on a project or an organization is the culture.  And, the other reality is that most organizations have a culture that does not support an agile framework.
But, how do we change the culture?  Do we change the process first and hope the culture changes with it?  Or, do we try to change the culture ahead of a process change?
At my current place of employment, agile methodologies are accepted, along with any methodology that makes sense.  There isn’t a “corporate” methodology.  I really like that.  Imagine if a company was by-the-book Scrum.  No other options.  Imagine having to beg for permission to “pilot” Kanban…ugh.
My point is this…maybe we should stop the notion of “piloting” Scrum, or Extreme Programming with the intention of rolling it out and making it the “approved” delivery methodology.  Maybe we should instead focus on sound principles that we know are true, universal, and also happen to be highly valued in agile and lean.  Principles such as:
  • The primary measure of progress is working software
  • Business and IT working together daily
  • Face to face communication
  • Reducing waste
  • Building quality in
  • Delivering as fast as possible
  • Delivering working software frequently
  • Self-organizing teams
  • Welcome change
  • Sustainable development
  • Technical excellence
  • Keeping it simple
  • Continuously improving the process
 As long as we let these principles drive our process, and people are empowered and allowed to make mistakes which will in turn promote learning, the process will work.

The Cross Functional Team vs. the Functional Community

An agile team consists of everyone it takes to deliver value to the customer.  The typical team consists of analysts, developers,  and testers. Of course the team is not limited to these roles.  The team could also include technical documenters, DBAs, or whoever else has a hand in creating value.

In traditional organizations, “team” is defined as a functional group.  The development “team”, the “testing” team, the “analyst” team, etc.  This makes sense in a traditional, waterfall-ish environment.

In an agile, cross-functional environment, it is not helpful to define “teams” around functions.  Okay, “maybe” its okay in a production support capacity, but that’s still pushing it as there will still need to be cross-functional work with production support.

Teams have a common, unified goal. Functional “teams” do not.  For example, a functional “team” that consists of a dozen Java programmers, with each programmer on a different project, can hardly be called a “team”.  They have no common goal, other than to adhere to the (hopefully) high development standards that have been put in place.

I propose that instead of calling these functional groups “teams”, we call them communities.  Here’s a simple definition of community that I found on dictionary.com: “A group of people having common interests“.  The Java “community” will work together to make sure that they have common standards of excellence, share knowledge and experiences, and provide each other guidance as needed.  However, these people will have different goals, depending on the project on which they have been assigned.

Up Front & Iterative Planning

You know the question…”what kind of projects are best suited for agile?”.  To me, this is the same as asking “what kind of projects are best suited for empowered teams, technical excellence, servant leadership, reducing waste?”.  Would there ever be a time when you would not want these things?  I know, that is a very smart-allec response, but I just can’t help myself.

I then ask “what’s the other option?”.  This surprisingly stumps people when I ask this.  We all know there is no such thing as “true” waterfall in software.  So, to help them along, I clarify what I “think” they are asking which is “what kinds of projects are best suited for big, upfront planning and design vs. iterative & incremental delivery?”.  People almost always agree with the restatement of the question.

I believe that everything can and must be done iteratively and incrementally in software.  However, the level of “up front” may change with the type of project.  Gutting out an old accounting system and replacing it with an Oracle or Great Plains solution will require more up-front planning and analysis than a green-field Web 2.0 social networking application.

So, fellow agilists, “up-front” is not a bad word, it has to be done.  We know this already with release planning, and even sprint planning, we just don’t call it “up-front”.  Just be careful…VERY careful.  You run the risk digressing into waterfall.  At times, there will need to be more “up-front” than other times.  Always be asking yourself, “what is the soonest we can deliver value to customer?”.

Sweet Exercise to Teach Empowerment and Self-Organization

I taught a one day agile course to a group of IS leaders. I wanted to come up with an exercise that illustrated that to be efficient, you have to reduce hand-offs, allow teams to self-organize, and leaders must be servants.

So, with my wife, we came up with “Project Pinwheel”. Below is how it works.
  • Straws
  • Paper fasteners
  • Paper copies of the pinwheel pattern to cut out
  • Scissors
  • Markers
  • Paper punch
  • Shoe-box size plastic containers (to hold the supplies at each table)
This is the process that I used. Feel free to change it to suite your needs.
At each table, there were 5-6 students. Each plastic shoe-box contained enough supplies for 20 pinwheels (would need less most likely). Also, make sure that you make samples of what the pinwheels are supposed to look like for each group.
There are two rounds. Below are the slides I showed to the class for each round.

Round 1

Your job is to create as many pinwheels as you can in 5 minutes. Take a minute, and assign the following roles at each table:

  • Cutter – owns the scissors and completes the cutting
  • Decorator/Designer – owns the markers and creates the design for the pinwheel
  • Hole Puncher & Paper Fastener – owns the hole puncher and the paper fasteners
  • Folder – does any necessary manipulation or folding of the paper during the creation of the pinwheel
  • Tester – tests the pinwheel when it has been finished. Verify that it has been decorated and that it at least moves a little when someone blows.
  • Manager – responsible for telling each team member what to do. The manager will communicate the tasks to the team members. The team members are not allowed to see the instructions.
  • At your table there is a box. Each box contains the instructions and the supplies.
  • No one is allowed to step outside their role.
  • The manager is the only one that can speak, by instructing the team members. Each team member is only allowed to speak to the manager.
  • If the pinwheel fails testing, the tester must hand the pinwheel back to who they think caused the “bug”.

At this point, the teams DO NOT see the sample. They don’t even know it exists.

Now, start the timer. After 5 minutes, they will likely create 0 pinwheels.
Round 2
[Slide for round 2]
  • Manager, you are now a servant leader. Please do whatever it takes to help the team.
  • Team members are allowed to help others out.
  • You can cross role boundaries.
  • Everyone can read the instructions. You can use the instructions as a guideline, but you can now be creative in how you create the pinwheels.
  • First, take 2 minutes to discuss how you will work together to be more efficient. Then, you will have 5 minutes to create as many pinwheels as possible.
Here, the team goes through a time-boxed planning session of 2 minutes to figure out how to best make the pinwheels before the 5 minute pin-wheel making session. Oh, I also pull out the sample pinwheel, so the team can have a collective understanding of what the “vision” is.
During my first session, each team made between 5-10 pinwheels. The ones who made less had issues with the “servant leader” thing, which made for a great discussion afterwords.
This is a bit of a pain in the butt to set up, but in the end, it is WELL worth it, and now I have the supplies for many classes to come!
Below is the instruction sheet that each team used.
Project Pinwheel Instructions
  1. Cut-out the pinwheel on the solid lines only.
  2. Decorate both sides of the paper pinwheel.

  3. Cut the dotted lines from the four corners to the center circle. Try not to cut into the center circle.
  4. Use the hole punch to poke a hole through the four tiny dark circles. Use the hole punch to poke a hole through the straw about 1/2 inch from the top.

  5. Hole punch the middle of the center circle on the paper pinwheel where the dotted lines converge.

  6. Make the holes on the four points meet at the center circle.

  7. Push the ends of the paper fastener through the holes on the pinwheel. Then push the fastener through the center circle.

  8. Place the straw on the back side of your pinwheel and push the ends of the fastener through the hole in the straw. Open-up the fastener by flattening the ends in opposite directions.

  9. Test the pinwheel to ensure it is functional. If the pinwheel is not functional, determine which step you need to send it back to in order to gain functionality. Repeat testing again until pinwheel is “complete”.

Only decorated, functional pinwheels that can at least minimally move when blown can be counted as “complete”.

Below is the image to cut-out to make the pin-wheel.  You can also find the image just by searching for “pinwheel pattern” on google.

The quest for the perfect agile tool

I’ve been searching off and on for the perfect agile tool for years. My “dream” tool would be a one stop shop for releases, stories, tasks, acceptance criteria, test cases, points, etc., etc. Oh, and by the way, it would be INTUITIVE.

When I enter a new team, I start the search over, and almost always end up back to stickies and/or spreadsheets. Currently I am using Acunote (http://www.acunote.com), and it seems to be doing the trick. It’s missing a lot of things, but it’s good enough for our purposes.

I’ve learned to not worry about tools until there is a solid foundation. The right team (technical lead, Product Owner, Scrum Master) and a product backlog must be in place first. Then, the core Scrum team can be formed because it is clear what needs to happen. Once the Scrum team is in place, ensure they are self-organizing. NOW, it’s okay to start looking at tools … as a team.

In the meantime, my quest will continue, and maybe someday that perfect agile tool will surface. But, if it doesn’t, I’ll just stick to stickies and spreadsheets and be happy!

What makes a successful waterfall project?

I recently posted a question on linked in wanting to hear from people who have either led or been a part of a successful waterfall project.

Here’s the link. There a some awesome answers. What’s interesting is that what is required for a successful waterfall project is clearly defined scope, engaged sponsors, and a great, empowered team. Sadly, I rarely see all of these occur in the wild. And, these are the primary elements of what’s necessary for an agile project, explaining why there is a higher success rate with agile projects.