Key 14 - Radiate: Michigan Agile Philosophy (MAP) Project Key

14. Radiate

Humans have been radiating information for a long time. I mean, who really knows what some of those cave man drawings really mean. It could be that Mrs. Cave Man/Woman had a shopping or honey-do list scrawled on the wall. When Mr. Cave Woman/Man finished an item he/she scratched it off with the tooth of a saber toothed tiger. The whole family including Baby Cave Girl or Boy knew exactly what was done and what still needed to be done. I’m sure it happened just like that.

First, Radiate is just a fancy way of saying display. Show. Keep out in the open. Make transparent. We want teams to make their work visible. Why? Well, there are a couple reasons. For one, it helps the team. When people on your team know what you’re working on, they can plan their work better. They can make sure they can budget time to help others if they are working on stories that they can pair on. It helps the team get a sense of what work is left. They can see a list of stories, see stuff get moved and see progress.

By Radiating your work you get the added benefit of team members sharing experiences. For example, imagine you are at your stand up meeting one morning. Each person on the team walks over to the board/wall/TV/monitor or wherever you are radiating your project information. One by one the team members point to the story they worked on last, the story they are going to work on, and if there are any impediments/blockers that are keeping them from getting their work done. After “Brock” gives his update, “Lee” notices that the story Brock is going to work on is similar to a story he had done the previous week. “Brock,” Lee says, “I can help you with that story if you want. I have a configuration file that will make it easy to complete your story.”

Another advantage of Radiating the team’s work is it gives the Product Owner a visual representation of how much work is left and the order the work will be completed according to their priorities. By seeing the work it helps them plan. If the Product Owner needs to change a priority, they can see the work in one place and make adjustments. If nothing else, by radiating the work, it invites discussions that may not have happened naturally.

Finally, by radiating information such as a burn up or burn down chart, management can get a sense of when the work is going to be completed so that they can plan the next project for the team. Radiating work is not about “Big Brother” keeping an eye on employees. It’s not about using it as a weapon to beat people down. It’s not a tool for managers to crack the whip so that the team moves “faster.” In fact, it can be helpful to limit the pile of work. How many times have you had a manager come up to you and say I need you to do X? When your work is transparent you can point to the work you have in your backlog and say, I could do X, but this is the work that I currently have and it will affect what the team has committed to complete. That usually works.

Radiating information isn’t about a tool. You can use cards on a wall, a white board, google spreadsheets, or another online tool. Any way where you can show your work. Crayons and paper could work. It’s really just about sharing information.

Key 13 - Iterate: Michigan Agile Philosophy (MAP) Project Key

13. Iterate

We’re more than half way through our 18 project keys now and we come to a really important one.

This topic is really about short feedback cycles. You want to learn stuff as quickly as possible, try something, decide if it worked, and go again. Lean describes something called the Plan Do Check Act or PDCA cycle. Dr. Deming made it popular, but it is really just an extension of the Scientific Method. In the Scientific Method you hypothesize, experiment, and evaluate.

We go through this cycle each iteration. For us an iteration is typically a week, but it can really be any short period of time. I have done 1 month, 2 week, and 1 week iterations. 1 month was a bit longer than I recommend, but depending on the project, it may be the right length.

A team will plan their work for the iteration, do the work, check the work (Deming switched to Study instead of check after a while), and finally take action based on what we learned in the check step. In terms we use, we have planning, then the work starts, we have a retrospective to learn what went well, what didn’t go well, and what we want to try, and then finally we make changes that we think will make improvements. Then we repeat.

The idea is we are always learning. Always improving.

We do these PDCA cycles without even thinking of it. We do it when we drive. You plan a route, start driving, decide if the route is the best for getting to the destination, and make changes if needed. We do it when we write. We do an outline, start writing, assess and make changes, and iterate. Think about it. We do this kind of thing a lot. We tend to have very short cycles in our iterations when they have to do with personal things. It happens naturally when practicing an instrument, when having discussions, and even when writing a blog. Researchers use these methods and they have been seen in manufacturing, hospitals, and construction. It’s not new and it shouldn’t seem foreign to us.

Whether your iteration is a day, week, or 6.5 hours, the important part is that you’re allowing for short feedback loops where you are looking at the work, deciding what to do, complete the work, study how it went, and then make improvements. If you get used to this routine, your work will naturally begin to add quality, innovation, and you will be able to respond to the needs of the business much more quickly.

Key 12 - External Dependencies/Deadlines: Michigan Agile Philosophy (MAP) Project Key

12. External Dependencies/Deadlines

I realize my mind is a little strange. I’m going to pretend this is a good thing. When I was thinking about dependencies, my mind began thinking about things like Penn and Teller, dominos, then Rube Goldberg machines and finally…the game Mouse Trap.

For those of you who have played that blasted game you know it can be a love/hate thing. I wanted that game so badly. Once I got it and found out that it only worked one out of every ten times I was furious.

Usually it would go a little something like this:

I would turn the crank. Some of the time the boot would kick over the bucket and dump the marble down the zig zag stairs. If it didn’t get stuck or fall off the track it would go in the chute. YES! Now we’re cookin’! It was going to work this time. It would hit the pole. Sometimes the ball would fall into the bathtub…sometimes not so much. If it didn’t drop, I wouldn’t panic, I would simply drop it in the bathtub. If I was lucky it would trickle through and hit the seesaw. Often it did not. From there I would drop the diver into the tub and eureka! The mouse cage would drop…one notch. I would push it and it would go another couple. I’d flick it and it would go further. This is about the point where I would dump the whole board over and start over.

In the game of mousetrap each stage is dependent on the one before it. If one fails, well everything else gets jacked as well. Sometimes our projects have similar dependencies. Our piece of the project is often dependent on pieces that another group is working on. It could be that another project is dependent on something we are doing. Sometimes it is another product.

These aren’t necessarily bad things, they are just things to keep an eye on. They can be risks if they are not monitored. I remember an app I created that used Wikipedia’s API (Application Programming Interface) to get data and display it in my own format. Worked great. People loved it. Then one day, Wikipedia changed their interface. That meant the feature in my app would now be broken. I had an External Dependency on Wikipedia. It’s good to know where those dependencies live so that those risks can be monitored. This way your customer isn’t the first to find out.

Deadlines can be good things. On the psychological level they push us to move forward. On the project level they give us a constraint that is often unmovable. The fact that the project is constrained helps us to make decisions about which features should be added, which ones shouldn’t, and what staffing we need to deliver the feature set by the deadline.

It’s important to know when another project is dependent on work you are doing, especially if they have a deadline. At the end of the day there is only so much work that can get done. Understanding deadlines will help prioritize the most valuable chunks of work and to get them done first. Identifying the places where dependencies exist and then communicating with those that are affected is critical to the success of all projects.

In your project you should identify External Dependencies and Deadlines. Maybe stick them on a card and put them up on the wall in your team room. You can always talk about them at your planning meetings as well. Just don’t lose sight of them. The last thing you want is to end up with a Mouse Trap game for a project.

Balance.

With meager inspiration from one of today's inbox articles I thought it worthwhile to outline expectations about work when you're not at work.

There is a covert and assumed expectation that when you are at home, training, on vacation, sick or otherwise not physically at work that you are to be in contact and responding to everything that goes on back here at MSIS. I am sure there are many individual and shared reasons for that behavior, but it is important that is cease. It ain't healthy, it ain't smart, and it ain't reasonable.

Certainly there is an anxiety about work backing up or dependencies others may have on you, but when you feel that tickle to answer emails on the weekend or feel like there is an expectation that you answer every email or text within moments of it appearing just remember that your time away from work is your time.  The sun will rise on the University again regardless of if you answer that email about a project update or incident.

Balancing your focus on what is important and when it is important helps both your work life and your home life.

When in doubt or in conflict about balance or priorities it is reasonable and expected that you raise that concern until it is addressed. If for any reason you feel it is not being addressed, please let me know and I will resolve it.

We all have more work to accomplish than what is possible in any given day and that forces the conversation around limiting our work in progress and clearly identifying priorities. That behavior is a skillset that has to be learned and practiced for it to be effective. We have some workflow to help facilitate it, but it is incumbent on each of us to determine our personal actions to stay somewhat sane.

UM does have some HRD sessions and classes on related topics. There is an abundance to literature both digitally and in print that you may wish to try. I am happy to fund both within reason as it is just as much a skillset as any technical talents I look to professionally develop.

Focus, breath and take it one step at a time. We don't need heroes to be successful, we need consistent and predictable delivery.

Let's go exploring - The Electronic Visualization Laboratory@UIC

I recently had the opportunity to visit the Electronic Visualization Laboratory at UIC with Erik Hofer. It was an especially enjoyable experience that highlighted for me and is the point of this post that it is reasonable and rewarding to explore outside your typical domain boundaries. You should go find interesting perspectives and possibilities to how you may seed creative solutions in your life and your work. Short of that, it is also good to remember that you work at one of the most impressive academic institutions in the world and we have access to so much around us that we often overlook those resources just down the hall or street from where you sit everyday. This is a privileged access we all share but so few of us take advantage. 

The history of the EVL is available on their site, but notable is that this is the facility that helped create one of the first computer aided effects in cinema with the above representation of the Death Star in Star Wars Episode 3 (the first of the illustrious series of 3 episodes of which no prequel exists)

It is also home to the Cave2 which is an impressive immersive environment that should be experienced to understand. In this photo you see the driver navigating the bridge of NCC-1701 but it also has potentially extensive possibilities in medical research and education. We also cruised around Mars using NASA data sets, looked inside of protein folds and molecular models with a brief detour to Luxor Egypt. 

Imagine if you will a mixture of this technology along side some of our virtual microscope or simulation needs in the learning space or perhaps being able to utilize this with our crystallographers modelling. Aside from the wizzbangery of it all, there is a potential and demonstrable value that these types of resources bring to our customers and that is worth considering. 

Agile Coffee (coffee not included)

(note the lack of provided coffee in this Agile Coffee cup)

The happy return of MSIS Agile Coffee is at hand. After being on hiatus for a couple months, we are looking forward to the reinstitution of this klatch under the direction of Andy Brown. It will be held monthly on the third Wednesday of every month in NCRC Bldg 520-1122  from 3:30-4:30pm and is an open to those of all Agile experience levels interested in the practices in use in Medical School Information Services. However please note that the initial kickoff meeting will be held  this Wednesday March 19th at 3:30pm in bldg 300 rm 376

The format is changing slightly with each meeting starting off with a 10-15 minute presentation on a relevant topic. 

MSIS Agile Coffee loosely follows the "Lean Coffee" method. Review that site and we look forward to seeing you soon. 

Join the Agile Coffee Mcommunity group to stay abreast of activities.  https://mcommunity.umich.edu/#group:Agile%20Coffee

Key 11 - Status: Michigan Agile Philosophy (MAP) Project Key

11. Status

Married? Single? Parent? Citizen? What’s your status? We have lots of ways of using status in “real life.” When it comes to project status, it can be useful IF it is used to help make decisions…if not, it’s really just a waste of time.
As far as a project is concerned, what are we really looking for? Well, in most cases it is the health of the project. How are we doing? Are we learning some stuff that is going to change estimates? Have we figured out that we can deliver less features and still achieve the objective? How are we doing with respect to the budget? Has the project even started yet?
We have several touch points in the Michigan Agile Philosophy (MAP) that give us opportunities to share project status frequently. Consider stand-ups (scrums), Planning and Prioritization meetings, Show and Tells, and Retrospectives. Each of these give us an opportunity to share the health of the project from the macro level to the micro, story level.
Some statuses we use:

• Intake: The MSIS Project intake form has been submitted. This means that the request will be evaluated in MSIS Governance.
• Inception Deck: The Project has passed Intake and is either approved to begin or at least approved to find out more information. You can read more about the Inception deck in Key 10: What does done look like?
• In Progress: The Project is ongoing.
  • Sprint 0: We are in the initial phases of building a backlog and estimating the project.
  • On Track: According to our burn up charts, we are on track to meet the deadline with the existing feature set.
  • Behind Schedule: According to our burn up charts, it looks like we are not going to meet the deadline with the existing feature set.
• Blocked: There is a dependency or an issue that is keeping us from moving forward.
• On Hold: For some reason, maybe budget, compliance, security, personnel, or something else, the project is on hold.
• Terminated: We are no longer doing the project. It has been terminated. [to T-X] Terminator: You are terminated.
• Done: The project has been completed.

These above aren’t set in stone, they are merely a sampling of most of the statuses we hear. The point is that the PM and most likely the team should be able to explain the health and therefore the status of the project in a language that everyone can easily understand.

Key 10 - What does done look like?: Michigan Agile Philosophy (MAP) Project Key

10.  What does done look like?

Grilling.  I love it.  I suck at it.  I may be the one guy on the planet that didn’t get the grilling gene.  The concept is simple, the act of grilling that is, but alas I just don’t get it.  Chicken either ends up completely charred or soggy in the middle.  Burgers bloody or over cooked.  Steaks rubbery or tough.  I just can’t seem to get it right.  On the occasion I do get it right, it usually involves me checking every 20 seconds by slicing a chunk out of whatever I’m cooking to see if it is done.  By the end, the item vaguely resembles what it is supposed to look like.  This is ok if I’m going to cut it into smallish pieces for a salad…not so ok if it will be served at one of our little outdoor gatherings.  It’s all about knowing when it’s done.  See what I did there?

Projects are a little like grilling.  If you leave them going too long they get tough and add little value.  If you take them off too soon you get salmonella.  Ok, so that was a stretch, but like grilling you need to know what you’re going toward.  If you know you like your burgers medium then you want to get them off the grill when there is still a little pink in the middle.  If you are shooting for well done, you want to make sure all the pink is gone, but that you haven’t achieved the black shell I often get.  The point is that you know what you are driving toward.  This is what done looks like for a project.

You should understand conceptually what you are going to see when the project is done.  What are the things you will be able to do?  How will the system react?  There are many techniques to visualize what the project will look like when it is done.

Story Mapping
Story mapping is a great one.  David Hussman has a great video on Story Mapping on his site if you’re interested in learning the particulars.  http://www.devjam.com/coaching/cutting-an-agile-groove/

Inception Deck
Inception Decks are something we use at MSIS a lot.  It’s somewhere around 20 slides that helps you navigate most of the questions you need to think about to loosely define the scope of the project without being so rigid as to not give you some flexibility.  If you work for the University of Michigan, you can check out our Inception Deck template here:  MAP Inception Template.  If you’re not an employee, you can see the inspiration for ours here:  agile warrior.  We added some items that work for us like Transition to Operations, and Non-functional type requirements.

When we are working on the Inception Deck we do our best to break the project up into logical chunks and estimate them at a very high level based on previous experience.  This gives us our target.

A3
A3s, known for the larger paper size, were borne out of Toyota.  The idea is to write down the problem, an analysis of the problem, proposed corrective actions and a plan of action written on one A3 sized sheet of paper.  A3s are common in Lean communities.

There are many other ways of understanding what the end state of the project is, but the one thing all of the techniques above have is that they foster communication.  In Agile, there are many practices that foster collaboration and further discussions.  Story Mapping involves the team standing around a table, mapping out thin slices of functionality.  The Inception Deck requires that the team work with the Product Owner to understand what is really needed.  An A3 gets completed by a team talking about what the real problem is, possible solutions, and then creating some actions.  The most important part of any of these is to have discussions, to understand each other, and then to plan the next steps.  Our technique of choice is the Inception Deck.

If we don’t have a concept of what done looks like, the burn up charts we talked about for Keys 7 and 8 become meaningless.  Even worse, if we don’t know what done looks like the project will often labor on and on and on and on…dumping money and features into the Island of Misfit Projects Black Hole.

At some point we have to translate done into a certain amount of features or stories.  If we have a complete backlog it’s easy to see when done will be achieved.  You don’t typically start off a project with a complete backlog though so there is a period where the backlog grows based on what you’re learning.  It often takes several iterations until you have the main features described in the backlog as stories or epics (a collection of stories that are related).  Many Scrum teams will use the concept of an Iteration 0 to help flesh some of these things out.

We’re going to leave this subject for a bit and return to it when we talk about stories.  In that case we will be looking at “done” at a different, equally important level.

For the record, I’ll have my steak medium.

Key 9 - Team: Michigan Agile Philosophy (MAP) Project Key

9.  Team

Ok, strap in for a good one.  There’s a lot here, but I think it is important that we take a step back so that we understand why we are focusing on teams.  I won’t be able to address everything related to the topic, but I’m hoping you will get enough to whet your appetite and understand what we are trying to do.

For every complex problem there is an answer that is clear, simple, and wrong.

—H.L. Mencken, journalist, writer (1880–1956)

Before we talk about the Team as it relates to the project key, let’s look at the theory behind teams.  Our work is complex.  By complex I mean, it is predictable with a lot of surprises.  We will look to Complexity Science for some answers.

I believe we have three main goals with our work:

• Deliver value
• Innovate where possible
• Delight our customers

The problem is that it is difficult to do any of them unless we are in a safe environment with all the resources needed to accomplish the work.  

Management 3.0 guru Jurgen Appelo says this about how we deal with complexity:

“Our minds are wired to favor what I call “linear thinking” (assuming predictability in cause and effect) over “nonlinear thinking” (assuming things are more complex than that.) We are accustomed to stories being told linearly, from start to finish. School taught us linear equations and largely ignored the much more ubiquitous nonlinear equations simply because they’re too hard to solve.”

So even though we know that our work is complex, we want to simplify it and pretend that it is predictable.  The truth is that it is not completely predictable.  If it was, machines would be doing all our jobs.  So what do we do?  How do we handle complexity?  You use complexity to fend off complexity.  Put by another smart guy named William Ross Ashby, “Only variety can absorb variety.”

So the trick is using complexity to deal with the unpredictability that is inherent in the work we do.  How do we do that though?  Complexity theory suggests it is with a Complex Adaptive System (CAS).  Stick with me here…I promise not to nerd out too much.  A CAS is a complex, self-similar collection of interacting adaptive agents.  CASs are made up of parts that make up a system that show complex behavior while adapting to a changing environment.   More info from Michael J. Mauboussin (full article here:  http://hbr.org/2011/09/embracing-complexity/ar/1):

A canonical example of a complex adaptive system is an ant colony. Each individual ant has a decision role: Am I foraging? Am I doing midden work? Each one also interacts with the other ants. A lot of that is local interaction. What emerges from their behavior is an ant colony.

If you examine the colony on the colony level, forgetting about the individual ants, it appears to have the characteristics of an organism. It’s robust. It’s adaptive. It has a life cycle. But the individual ant is working with local information and local interaction. It has no sense of the global system. And you can’t understand the system by looking at the behavior of individual ants. That’s the essence of a complex adaptive system—and the thing that’s so vexing. Emergence disguises cause and effect. We don’t really know what’s going on.

Why is an ant colony the first example you think of?

Complex adaptive systems are one of nature’s big solutions, so biology is full of great examples. Ant colonies are solving very complicated, very challenging problems with no leadership, no strategic plan, no Congress.

Once you’re aware of how the structure works, though, you’ll see these systems everywhere—the city of Boston, the neurons in your brain, the cells in your immune system, the stock market. The basic features—heterogeneous agents, interaction, and an emergent global system—are consistent across domains.

Hmmm…what construct do we have in MSIS that is made up of variety of parts making up a system that shows complex behavior while adapting to a changing environment.  I submit to you that the Team does all of those things.   You are fighting complexity with complexity with people/brains (heterogeneous agents), making decisions (adapting), and where decisions evolve over time as more is learned (emerging).  The Team.

Hopefully you’re still with me.  Let’s move on to roles.

Roles on a Team

“First and foremost, Agile recognizes that people are unique individuals instead of replaceable resources and that their highest value is not in their heads but in their interactions and collaboration. Agile calls for small teams where different roles (developers, designers, testers, and so on) form cross-functional units, preferably colocated (located in the same room). These teams are then required to self-organize, meaning that no method or process is imposed on them. They are trusted to get the work done in ways that they think are best, assuming that they know how to do that, with accountability for their results.”

Jurgen Appelo

We have chosen the word Team very carefully here.  Think about teams in the sense that most of us think of teams…sports.  Start with football.  What is the makeup of the team?  Besides the obvious offensive and defensive players, you have people that have domain expertise.  On the offensive side you have guys that are supposed to be fast, run crisp routes, and catch anything they can touch.  You have offensive linemen who learn to block in many different ways to protect the quarterback.  They are usually monsters in size as compared to the wide receiver.  Running backs and full backs are usually not the tallest guys on the field.  They have tree trunks for legs and either bulldoze ahead looking for openings the offensive line makes for them or they dart left and right looking for open daylight.  Different functions all working together to move the ball down the field.  Let’s look at basketball.

We have a Center who is usually the tallest on the team.  They hang out under or near the basket looking for rebounds or they get fed the ball for close shots.  You have guards who are usually the shortest on the court.  They have the best dribbling skills and move the ball around well.  They typically can shoot well too.  Forwards have a mix of skills, can shoot, pass, and dribble well.  Again, different strengths all working together to get the job done.

Hockey, volleyball, water polo, baseball, and so on have the similar ideas.  There are people that have more knowledge/skill in certain areas, but collectively they have what the team needs to do the work.

This isn’t just for sports teams.  Quiz Bowl teams would be lousy if they just had people that were good at history.  Cheer teams would collapse if you didn’t have a couple burly cheerleaders to form the base of the pyramid.  

In the military, squads are broken up into “teams” of people with expertise that is needed to accomplish the mission.  

From wikipedia:  The creation of effective fireteams is seen as essential for creating an effective professional military as they serve as a primary group.  Psychological studies by the United States Army have indicated that the willingness to fight is more heavily influenced by the desire to avoid failing to support other members of the fireteam than by abstract concepts. Historically, nations with effective fireteam organization have had significantly better performance from their infantry units in combat than those limited to operations by larger units.

Now at the risk of firing up too much testosterone in the fellas, here’s a little bit about the makeup of a typical fireteam.

According to US Army Field Manual 3-21.8 (Infantry Rifle Platoon and Squad, formerly FM 7-8) a typical United States Army fireteam consists of four soldiers:

• Team Leader:  Provides tactical leadership for the team at all times with a "Do As I Do" attitude. A team leader is equipped with either an M16 rifle or a M4 carbine, and holds the rank of Sergeant or Corporal, although occasionally a team is led by a Specialist or Private First Class.
• Rifleman:  Is the baseline standard for all Infantrymen'. They are equipped with the M16 rifle or M4 carbine. The rifleman is usually assigned with the grenadier to help balance the firepower capabilities of the automatic rifleman.
• Grenadier:  Provides limited high-angle fire over 'dead space'. A grenadier is equipped with an M4/M16 with the M203 grenade launcher (or newer M320 grenade launcher) mounted to the weapon.
• Automatic Rifleman:  Provides suppressive fire, and is the most casualty producing person in a fireteam. An automatic rifleman is equipped with M249 Squad Automatic Weapon.

You can see that each person has a role.  They may be able to find success by themselves, or with others with similar capabilities, but the real power is in the fact that they have all the roles that they need to get the job done.  They have a guy with a big machine gun, a guy that can make things go boom, and some guys that have a little more of a surgical strike capability. 

Even the A-Team show proved that every team needs a planner/leader (Hannibal), the brawn (Mr. T), the smooth ladies man (Face), and the crazy guy who flies planes (“Howling Mad” Murdock).   

Being a self contained team with all the necessary roles to accomplish the task is ideal.  Camaraderie and dependence on each other is powerful.  A team that locks arms and goes into the battle/project together has a greater chance of success than a group of disparate folks that aren’t invested with each other. 

Team Size

Studies vary on what the optimal team size is.  It’s generally accepted that somewhere between 5 and 12 people is optimal.  I’ve heard 7 plus or minus 2.  The point is you want enough diversity and domain knowledge on the team to get the project done.  

I think we can all agree that one person is not a team.  A basketball team with only one person would be tough.  Baseball with just a pitcher may survive on defense if you had an ace, but my guess is you wouldn’t score much.  Can you consider two people a team?  Well, maybe.  

I consider my wife and I a team.  We work on stuff together consistently.  We work in a complex environment.  We have some diversity in our thinking.  It seems to hold up.  However, consider what happens when my wife is sick.  I’ll fill in the gap for you.  The house comes to a screeching halt.  Why?  Well, with her out of commission, I am left to fend for myself.  I have to make all the family related decisions myself and do all the housework based on what I know.  What does that mean?  Well, typically it means that my kids don’t get clean clothes, healthy food, or guidance to make sure their homework gets done.  I guess I could just sit on the couch and not do anything until she gets better, but that seems like waste.  

What’s the solution?  Backup wife.  Well, that’s probably not going to fly, but think about what happens on typical projects.  People get sick, they take vacation, they get interrupted.  If your teammate is not around you absorb the risk,  may become blocked, potentially leave some good ideas on the table, fight the complexity alone, and deal with many other problems alone.  You also become the single barrier between yourself and potential failure.  Not the safest situation.  (See http://www.industriallogic.com/blog/anzeneering/ for more on safety in IT.)

Teams are important.  They help us fight the complexity that is present whether we want to acknowledge it or not.  So what does all this mean for us?  It means that where possible we should form teams with all the roles necessary to deliver our project work.  Our definition of team is consistent with research and the reasoning above.  For us a team is 3 or more people working together consistently to achieve a goal.  

How does this relate to the Project Key?  Well, that part is easy.  It is simply that you should know who your team is and what roles each person is playing.

For fun I’ve included some nifty team quotes for you.  

“The way a team plays as a whole determines its success. You may have the greatest bunch of individual stars in the world, but if they don't play together, the club won't be worth a dime.”

Babe Ruth

“Individual commitment to a group effort - that is what makes a team work, a company work, a society work, a civilization work.”

Vince Lombardi

“I am a member of a team, and I rely on the team, I defer to it and sacrifice for it, because the team, not the individual, is the ultimate champion.”

Mia Hamm

“I’m not asking you for ten, twenty, thirty million dollars. I'm just asking for a little bit of help. Just get me a little bit closer and I will get you that championship team. I mean, this is why I'm here. This is why you hired me. And I gotta ask you what are we doin' here?”

Billy Beane

If you’re interested in reading more, Jurgen Appelo’s book Management 3.0 is a great read and an excellent resource.

Key 8 - Actual End Date: Michigan Agile Philosophy (MAP) Project Key

8.  Actual End Date
Let’s see…we can look at this one in two different ways.  There’s the literal definition where we look into the past, and there’s more of a predictive definition.  Let’s start with the literal definition.  This is a moment in time.  When did you have your first kid?  When was the Big Game?  When did you graduate?  Each of these have a definite point in time that you can point to after they happened.  This is kinda useful.  It tells us things like how old your kid is, how long since your glory days, and so on.  Really though, it’s more interesting to chase after the second more predictive definition.

This one is more like asking when the milk will spoil.  The date on the jug says March 1^st, but in reality it could be a few days after or less likely a few days before.  Another example could be asking a pregnant woman when she is due.  We have an idea based on experience, but in reality, the actual date could be before or after the predicted date.  Ok, enough of the metaphors.  In practice it looks a lot like the MVP burn up chart was saw last time.  In the pictures below you see the black line which denotes done done for the project.  This means all the intended stories are complete.  This represents all the release stories in the backlog.  You may have some additional work in there that you are planning for another release, but we won’t concern ourselves with that for now.  The first picture shows the best case scenario, the green line as it crosses the black “done” line.

This is telling us that in the best case scenario the project will complete on 3/17/2014.  This is good info, but it only part of the story.  This means that if the team rocks at their best rate, they will finish on that date.  As everyone has probably heard me say by now, “a plan is only as good as first contact with the enemy.”  In other words, stuff is going to come up that is unexpected.  

In this second picture you can see when the project will finish in the average case.  That means that the likely ending is 3/24/2013.  If the team works about how they have been working, they should finish right around that date.

Finally we have the worst case example.  This means that from today on if the team completes their work at a rate equivalent to their worst, they will finish on 4/7/2013. 

At the end of the day with this burn up chart, we get guide rails.  The project will be done between and 3/17/2013 and 4/7/2013.  When you think about it the spread isn’t that crazy.  It’s only a few weeks, but at least it paints a pretty good picture.  We aren’t just pulling dates out of thin air.  Lots of bad things happen when we do that.  Most often it involves people working crazy hours right up until the due date.  This hurts morale, kills productivity, and if you really look at it, that date probably was an artificial date anyway.