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.

Supplies

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

Process

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

[slide 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.

[slide 2]

• 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.

Scrum Documentation

If you are on an agile team, and you are telling your team that you don't need to document because your "agile", stop it. Stop it right now!! You're making my life difficult!

There is a strong stereotype out there, and its that with agile, you don't document. Arggghhh!!! I'm sure some of you have experienced it.

Here is what I tell people when they ask about the documentation requirements on an agile project..."If the team needs it, then they will create it". Now, I'm not talking about documents that are delivered to the customer, like help documents. I'm talking about documents such as architecture diagrams, "requirements" documents (eww), process flow diagrams, diagrams, and more diagrams.

IF these kinds of documents will make the team more productive, and produce higher quality software then document! Now, the next thing I tell people is to be LOW TECH. I mean, c'mon, do you really have to transfer that diagram on the whiteboard to visio? I've seen people take 2 weeks to do that, as the rest of the team is "waiting", i.e WASTE. Why not take a picture? It's going to change anyway, right? And, we "want" it to change, if we ever want to improve.

Remember, the end customer does not value these kinds of documents. So, DON'T SPEND A LOT OF TIME ON THEM. If your company "requires" them, then take the lowest road approach possible. Ask questions. Challenge the "process". Processes were meant to change and improve, you should not be a victim to them.

Okay, to review....

• Documentation can be good, if it makes the team more productive and the customer happier because of higher quality. But, BE CAREFUL
  
• Low tech = Good
  
• The customer DOESN'T CARE about those documents, so just take it easy there partner. Only do the bare minimum that you NEED.

The Curse of Traditional Software Development Methodologies

I've realized that very few teams follow the waterfall methodology by the book. However, I think that most shops try...really, really hard. Of course we WANT to define every requirement and scenario that could possibly happen. Once that's complete, THEN we can start building. And, if there is a new scenario, or "missed" requirement (heaven forbid), then the developers can point at the requirement gatherers and say "AH - HA!!! You screwed up, and now you must suffer the consequences!".

Well, this is just silly, we all know that change happens, but yet we try to fight it every step of the way. That's what requirements change management is, right? Its to prevent change, i.e. just say NO! To remain competitive in today's marketplace, we just can't think like this anymore.

Below is a list of beliefs that we (including myself) really wish was true. If they were true, our jobs would be so easy! Of course, it wouldn't be as fun :-)

• The customer knows exactly what they want.
  
• We understand what the customer wants.
  
• We understand who the customer is.
  
• We can define everything up front.
  
• The technical team knows how to build what the customer wants.
  
• We can accurately predict how long it will take to develop what the customer wants.
  
• There won't be any problems (or very few).
  
• Documentation is a true measure of progress.
  
• Nothing should change. If it does, it's [fill in the blank] fault.
  
• Hours worked is infinitely directly proportional to value delivered.
  

Okay, so none of these things are really true. Since we all like to pretend, we have failed over, and over, and over again. I believe that this failure in traditional projects has caused stereotypes to evolve, including:

• The technical team is arrogant and lazy.
  
• The technical team doesn't care about the customer.
  
• The technical team is lying. It can't be as hard as they say.
  
• The customer doesn't respect the amount of work necessary to deliver what they want.
  
• The customer is stupid.
  

This failure has also caused some pretty weird behaviors to spring up.

• A tendency to over-specialize and divide ourselves into silos.
  
• The desire to control and direct every move made by every team member.
• Forgetting that development is creative and innovative and can't be treated as a commodity (this causes some real bad implementation).
• A culture of command and control.
• The desire to create a process for EVERYTHING in an attempt to control.
• A fear of sharing "too much" information with other silos...I mean other teams. If we share "too much" information, then the other teams may want "change".
• A fear of sharing too much information with the customer. Again, for a fear of change.

Please, stop the madness. Let's stop pretending that traditional development works and start working together.