Candor Improves Productivity

Business people having a meeting and discussion

Many times we focus on the more visible factors related to productivity, but how many mistakes could we erase and how much time could we save with candor?  Research by NASA in the 1980s found that “take-charge” pilots made incorrect decisions much more often than pilots who included their crews, even in as little as a 45 second time frame.  Healthcare studies concluded that a nurse would only speak up 8% of the time when a doctor was not following the proper hygienic protocol while conducting medical procedures.  Efforts that require just your team are 80% more likely to succeed than those requiring cross-team collaboration.  Most people would rather stay silent then provide criticism to a co-worker leading to frustration, water cooler conversations, gossip and/or passive aggression.  For others the outcome becomes yelling and public berating.  Some of these situations could arise in a moment’s notice and likely become emotional, putting you at an even bigger disadvantage.  Your body uncontrollably gets ready for “fight” or “flight”.  It releases adrenaline and pumps blood to your arms and legs while sacrificing blood to your brain, making the promise of a constructive conversation that more difficult.radical-candor-2x2
Figure 1:  The Candor Inc. Radical Candor Quadrant

So what can we do?  Kim Scott, co-founder of Candor, Inc., tells us that we need to operate in the “Radical Candor” quadrant (see Figure 1 above) where we directly challenge, but at the same time care for the person we are talking to.  It is much easier to give and receive feedback when you feel that the other person cares for you as a person.  Many of us can conjure up a vision where we would react completely different to the same message from two separate people. The book “Crucial Conversations” advises if we sense that the other person is not feeling safe with the conversation, then we must step out of the conversation and build safety before continuing.  After establishing safety, you identify what you would like as an outcome of the discussion and lead with the facts.  Listen and concentrate on the desired outcome and not on winning.  The way the message is delivered is important and goes to creating safety.  Too many jerks deliver the message inappropriately and then say “I tell it like it is”, thinking this gives them carte blanche to be obnoxious.  They are certainly not creating safety with that tact.  The flip side of the coin is “sugar coating” the message.  If you “sugar coat” the message then many times the recipient will not catch your meaning or gravity of the situation.

If you recognize the benefits of conducting candid and crucial conversations then start with yourself and dig into the available information out there on the topic.  We’ll make a lot of progress and save a lot of time with proper candor.

For a more detailed understanding on this topic, read the book “Crucial Conversations” by Kerry Patterson and Joseph Grenny and visit Candor Inc.’s website at http://www.radicalcandor.com

Multitasking Is Inefficient, Ineffective and Bad For Your Brain!

multitaskingdriving

Many people boast about their ability to multitask, but it’s really nothing to brag about.  The simple truth is that it’s inefficient, ineffective and the human brain is not built for it.  If you’re multitasking you’re not going to be able to produce your best work.  This is why many states have implemented laws such as not allowing drivers to text.

Studies show that you’re not doing your brain any favors either.  The brain produces dopamine when we successfully complete a task.  Our brain loves these quick little dopamine hits when answering an email or text and crave even more, resulting in even more multitasking.  Another down side is that multitasking also increases the production of a stress hormone called cortisol and this tires us.  Beyond the chemical implications, our brains were designed to focus on one thing at a time and when we barrage them with information it only slows them down and produces less than quality results.

A University of London study showed that people experienced a significant drop in IQ level when multitasking.  Even context switching, which is a less rapid switching of focus, costs us in efficiency and effectiveness.  In fact, interrupting your focus to read an email has been shown to reduce your effective IQ by 10 points.

Gerald Weinberg, computer scientist and psychologist, has assessed that context switching between projects costs you 20% of your time per project.  This means if you are switching back and forth between two projects for the week then you will effectively have only 40% of your overall time to devote to each project due to the cost related to switching context (see the graph below from Gerald Weinberg).

multitasking2

With all the distractions technology has introduced in society and the workplace, it’s a wonder that we can get very much done at all.  We have emails, texts, tweets, alerts and social media to name a few. To address the situation, try to commit to specific blocks of time to address these and minimize interruptions.  Work emergencies will occur and interrupt our work efforts also.  It will help to derive a criterion with your customers for the definition of an emergency and effectively triage incidents.  Whenever possible we want to have people assigned to one project/task at a time, let them get it done and then move onto the next one.

The bottom line is that multitasking is not something to add to your list of skills, but instead something you want to minimize.

Try the exercise below to illustrate the loss of time due to context switching.

Exercise

Label three columns on a sheet of paper as follows (“1-10”, “A-J”, “I-X” [the roman numerals]).  Now time yourself on how long it takes you to first write the numbers 1-10 individually under the column labelled “1-10” then writing the individual letters A through J under the “A-J” column and then writing the Roman numerals I through X under the “I-X” column.

Now time yourself for this second way of writing down the letters and numbers.  Get a fresh piece of paper and put the same three columns on the top again.  Now, first write “1” in the “1-10” column and then go to the next column and write “A” and then the next column and write “I” and then return to first column and write “2” and so on, writing each next number or letter in the next column until all of them are written down.

Your time in writing them the second time is substantially longer than it took the first time.  Why is this?  Because switching focus costs you time.

Agile Principle #1: Satisfy the Customer

Value

Agile Principle #1 states “Our highest priority is to satisfy the customer through early and continuous delivery of valuable solutions.”

Principle #1 is #1 for a reason!  Every team, group or organization has a customer, whether it’s an internal customer, an external customer or both.  The utmost concern for our team must be that we are providing value and satisfying our customer, for without that nothing else really matters.  In almost all cases, satisfying the customer is economically driven and teams have limited people and resources in doing so.  We relatively rank our items to address our most important and valuable items first.  This may be easy and quick for a simple “to do” list or we may have to spend more time for a list of more complex initiatives, always with a watchful eye on expending just enough effort to do so and no more.

Peter Drucker stated “There is nothing so useless as doing efficiently that which should not be done at all”.  Working on the right thing is important and we can increase our success by adhering to best practice relative ranking exercises.  Even in doing so, we can still fall prey to failure. Failure is not necessarily a bad thing.  Much is learned by failure, but if we are going to fail we want to expend the least amount of effort to do so – in other words, “fail fast” to learn.  By failing fast, we can quickly pivot or pick up something new that will provide customer value.

“Through early and continuous delivery” is a phrase in principle #1 that amplifies two significant points which are “leveraging feedback loops” and “maximizing value”.  Feedback is the cornerstone of Agile. Feedback loops are akin to a sailboat tacking to its final destination.  The tighter the feedback loop the better we can adjust and stay on line, but also the more effort we expend on the checking process.  Determine how long you want to sail along before checking your course.  Early and frequent feedback loops with the customer enable us to adapt, pivot and fail fast.

Releasing early and continuously allows us to also maximize value.  If we have 20 things prioritized, we then identify the smallest number of those things that will be of acceptable use to the customer and provide maximum value.  As an example, if we were building the first Automated Teller Machine (ATM) and we wanted the machine to “Withdraw Cash”, “Deposit Funds” and “Inquire on Balance” would it be wise to wait until all three features were available before delivering it to the customer?  Would it be wise to wait for the ATM to be able to remember what your most common withdrawal amounts were and proactively offer those choices?  Or would it be wiser to deliver the ATM as soon as possible without certain features?  These are decisions that you need to make, but the point is that the longer you wait to deliver value to the customer the longer you wait to receive the economic rewards which in turn is losing you money, along with depriving you of essential customer feedback as they use the solution.  So why not deliver the smallest number of features that provides the most economic value and then adhere to Principle #1’s phrase of “through early and continuous delivery of valuable solutions” by then delivering subsequent prioritized features continuously throughout the life of the effort.

Through some of the outlined and other practices we can deliver value to our customers continuously.  Continuously Providing Value = Happy Customer!  🙂

Watch the Work Product, Not the Worker!

Manager Watching Clock

At a number of organizations, I am observing management concentrate on the number of hours a worker has worked, ignoring some of the more important factors impeding software development.  The worker’s hours may be one of the most visible factors, but rarely the most significant.  Singular or heavy concentration on this by management indicates that the organization has a poor software development economic framework.

As direct or indirect pressure is applied to the worker by measuring hours worked without addressing product related factors, the worker will be pressed to engage in inefficient activities and context switching.  This activity further camouflages some of the important economic factors we really should be addressing.

We need not concentrate so much on the inefficiency of the worker, but instead more on the product. If we have no economic standard to order our efforts, then a couple of things could happen.  We work on efforts depending on which “HIPPO” (Highest Paid Person’s Opinion) matters at the time.  We stop and start efforts as the next important emergency trumps the previous.  We take in new work without finishing the work we already started. If this were manufacturing, we would see incomplete inventory laying all over the warehouse, visibly showing us something is dreadfully wrong.  In software development the inventory remains invisible.

Our greatest waste is not unproductive developers, but instead the wasted time incurred by product thrashing, poor communication, idleness due to dependencies, working on the wrong things and other product related factors.

Let’s start concentrating on these more important factors first instead of singularly concentrating on the more visible factor of how many hours our workers worked this week.

Daily Scrum Personas

Daily Scrum Team

The Scrum Guide defines the Daily Scrum as a “15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours”.

Each person answers 3 questions:

  • What did I do yesterday that helped the Development Team meet the Sprint Goal?
  • What will I do today to help the development Team meet the Sprint Goal?
  • Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

The Development Team leverages these 3 questions to inspect, self-organize and empirically adapt to deliver the Sprint Goal.

The above information is straight out of the Scrum Guide, but as we practice our Daily Scrum we just might meet up with some of these people, listed below, that will provide us some coaching opportunities.

I hope these examples are helpful for the person just starting to implement Scrum at their organization and a review for other experienced Scrum practitioners.  Anyone who has any additional examples, please feel free to add them as a comment and we can build on the list!

Larry

Larry “Looking for a Leader”

Larry is 45 years-old and has been in IT for nearly 25 years.  All of those years have been working in a strong command and control environment. He’s a very structured individual and a compartmental eater.

Larry looks directly at the Scrum Master while answering the 3 questions.  This is a tell-tale sign that Larry is looking to provide a status report to a person in charge.  He has not yet embraced the philosophy of a self-organizing and empowered empirical team.  He should be speaking to the team and not any one person. Explain and reinforce the empowered empirical team through coaching, games and exercises.

Penelope

Penelope “Problem Solver”

Penelope went to well-respected university and was a double-major in Computer Science and Philosophy.  She doesn’t have much patience for useless formality or rules that get in her way.  She loves to dive into the detail and solve problems.  Her mantra is “Patience is a waste of time!”

Penelope conducts an immediate deep-dive into details surrounding information voiced during the Daily Scrum.  When an issue comes up during Daily Scrum, she asks questions and begins to solve the problem on the spot.  We need to coach Penelope and the team to list topics for further discussion in a parking lot or discussion list.  When the Daily Scrum is done then you can identify who wants to participate in the discussions.  There is no reason to involve teammates who are not interested in that topic.  The conversations can be conducted right after the Daily Scrum or later as the team sees fit.

Nicholas

Nicholas “New Guy”

Nicholas is 22 years old. He just graduated college and joined the company about 3 months ago.  He’s a little overwhelmed with all the things he needs to learn at the new job.  He’s hardworking, but insecure about the amount of work he can get done in a day compared with his experienced teammates.

Nicholas talks about anything he can think about that he did in the day, so that his team will not think he is unproductive.  He mentions the meetings with his manager and other non-sprint related activities.  Nicholas and the team need to be reminded that they need not speak about non-sprint related activities during the Daily Scrum.  They should only be speaking about information that pertains or impacts the sprint.

Sammy

Sammy “Scrum Master”

Sammy was a project manager for 5 years until his company adopted Scrum and he transitioned to Scrum Master.  Sammy likes nice orderly meetings and ensuring that the team is on track for delivery.

Sammy sets rules for the team, such as punctuality, no interrupting, etc.  He sets the order in which people should speak to increase efficiency.  Although rules are not necessarily a bad thing, the team should create rules of engagement and determine the speaking order on their own.  We need to take every opportunity in having the team realize and practice that they are a self-organizing team.  Conduct activities and games to fortify this concept.  Try having the person currently speaking choose the next person to speak.

Priscilla

Priscilla “Product Owner”

Priscilla has worked for this company for 20 years.  She is very intelligent and understands the sales and advertising business very well.  She also loves technical work and is adept at pulling data and analyzing it.  She always wants the latest technology solution and, even though she works in sales herself, is an easy sell.

Priscilla listens to the Daily Scrum, but cannot help advising the team on how to order their work effort to be more efficient.  She questions remaining time on tasks and pushes the team regularly at the Daily Scrum. We need to counsel Priscilla that the Daily Scrum is for the Development Team to assess progress and figure out as a self-organizing team how to accomplish the Sprint Goal and deliver the agreed upon sprint backlog items by the end of the Sprint.  As the Product Owner, Priscilla should not be interjecting during the Daily Scrum.

How Should We Structure Our Agile Teams?

Agile Team

There are two types of teams, Functional Teams and Cross-Functional Teams.  A Functional Team, sometimes referred to as a Component or Specialty Team, is comprised of people with the same skill set.  Cross-Functional teams on the other hand are centered around delivering the same business value and consist of people with different primary skill sets.

The Functional Team benefits from frequently sharing and bettering their specific skill set knowledge across the team.  It is easier establishing and enforcing standards. Communication and collaboration within their specific skill set is very efficient, since they are all on the same team.

A Cross-Functional Team on the other hand benefits from having people with different primary skill sets so it can deliver the requested business value without or with minimal dependencies on other teams.

When looking at the two different team types, there are a couple of important questions we must ask ourselves to decide team structure.

Question 1:  Do we currently have enough people with that skill set so we can place a person on each Cross-Functional Team that has a need for that primary skill set?

We don’t want someone being a member of four different teams.  In fact, many Agilists believe that a person should only be a member of one team.  I believe there may be exceptions, but there should be a good reason for it and once you split a person across more than two teams it should certainly raise a red flag.

Question 2:  What will be the most important and most frequently needed communication and collaboration?  Is it with others with the same skill set or is it with people delivering on a common business initiative?

Communications with and dependencies outside of the team are responsible for most of the delay in software development.  If we can keep the need for cross-communications to a minimum, then we can minimize this delay.

I learned a valuable lesson a few years ago when I took an existing group of integration specialists and divided them up across cross-functional product teams.  On the surface this appeared to make perfect sense.  I thought the cross-functional teams would benefit greatly by requiring less hand-offs, better design decisions, simplified planning and improved speed of delivery.  What I didn’t realize was the integrations people needed to communicate more with each other.  The integrations code was legacy code.  It wasn’t very loosely coupled at all and every time you changed something you had to coordinate with the rest of the team.  Obviously, this technical debt needed to be addressed, but until that time it made more sense for the integrations people to be on one team.

The main point is to determine where the communication needs are and base your team structure on those findings.  After I learned this important lesson through failure, I also found a book, “Management 3.0” by Jurgen Appelo, which addressed the topic in “Chapter 13: How to Grow Structure”.  I highly recommend this book for this subject and other great information and insight.

Happy Team Growing!

Hey John, Don’t Abandon Agile!

blame

I was speaking to my buddy, let’s call him John (quite possibly because his name is John). John is a good friend who also happens to be in software development.  We were having a nice chat about our families and such when our conversation transitioned to our work. That was when John dropped the bomb on me and said, “Hey Phil, I know you’re a big proponent of Agile and my company does Agile, but you know sometimes you just have to abandon Agile and get things done”.

I don’t think my buddy John is the only one out there thinking this way.  What Agile adopters need to understand is that Agile will uncover and shine a spotlight on issues.  If organizations don’t have a healthy practice of inspecting the issues, identifying root cause, creating action items and conducting remediation – then they won’t move forward.  Why did we miss expectations? And if you can’t answer that question then ask “why” four more times.  It is so important for remediation on prioritized issues.  If you don’t, then you might take the position to abandon Agile, but in reality you have not followed the rules of the game because you have not addressed the root issues Agile has uncovered.  If your organization has been practicing Agile for a while and you feel, as my buddy John does, then I would challenge you with the questions below.

Can you utilize retrospectives to identify the root cause, prioritize action items and at the very least chip away at fixing them?  Sure, you may not be able to address everything or even half of what you find, but can you commit to start?  What issues do you face?  Does your organization experience some of these issues below?

We can’t do a two-week sprint – it takes us a week to test this stuff!

The end goal is to create a test-driven development environment.  In the interim you can do your best to create automated tests.  It may not be easy, but start to carve out some time and at least create automated testing around some of your more visited code.  Try to adopt a policy to have automated unit testing done for new code.

OMG!  Look at this code!  This needs a complete overhaul!

Don’t grow technical debt without a conscious decision to do so.  Even if you don’t practice pair programming, setting up a practice where there are peer code reviews or more than one set of eyes on the code is good practice.  If you don’t do this, you are probably working in an environment where over 30% of your time is spent complaining about and/or addressing technical debt.

We conduct retrospectives and identify needed improvements, but we don’t have the time to fix them!

If you have a hard time acting on issues found in retrospectives, make sure you create product backlog items for the action items and prioritize at least some to be addressed.  Make sure you’ve identified the root cause and address at least one or two per sprint.

Man, they just keep loading us up with things to do – we can’t keep up with this!

This is tough if you don’t have executive support.  You’ve got to have prioritization in place for initiatives. Strive to get an agreement in place for a work in progress (WIP) limit at the initiative level. Create an information radiator Kanban board showing all the projects and their state so it becomes apparent to everyone that there is a lot going on here.  Cull and keep your product backlog to a manageable number and notify stakeholders when a product backlog item is being deleted.  There will always be a higher number of requests than can be done.  If the stakeholder does not want it deleted, then they need to make the case for its priority.

They just told us about this the other day!  How can we get this done!

Identify the root cause of why you received this request so late.  If this happens often then record these events in a spreadsheet and have a discussion with needed individuals to uncover root cause.  Did another department sit on this request?  Is it a late request from a 3rd party, regulatory body or vendor?  Do your best to meet with the appropriate people, address and fix the situation.

They keep on interrupting our current project with another emergency project!

When you start working on a project do you define the smallest amount of features that you can deliver?  This is considered to be the minimal viable product (MVP).  Small batches are more efficient and at least if you get interrupted you have a better chance that you will have delivered something.  An emergency can happen, but if it becomes the norm then you’ve got more digging to do for root cause.  If you’re constantly stopping one initiative to start another, then you also may not be working on the right things.  A lot of organizations don’t have the proper scrutiny around economic feasibility (possibly my next blog) and without that objective measurement the newest squeaky wheel can sell anything as an emergency. Software started and abandoned cannot be seen the same as unfinished product laying around the manufacturing assembly line, so this happens more than we like to admit.

We’re dead in the water waiting on this other team!

Strive to create cross-functional teams, so you are not so dependent.  In the beginning this can be tough and cannot be done for everything at once, but if you don’t try then you will pay the price.  The biggest waste in software development is found waiting on dependencies and cross-team communication.  Think of creating a Kanban board displaying cross-dependencies.  This can assist in identifying queuing issues.

This issue happens over and over and is just killing us!

Continuous improvement is needed.  If you identify issues, but don’t act on remediation then you are not going to grow.  Capture the action items in product backlog items and prioritize at least one every sprint if you must.

This code migration is taking forever!  The code worked in test so why isn’t it working in production!

Do your best to move towards automated builds and continuous integration and delivery.  Couldn’t leave this one out, but even like some of the others – this could be its own blog subject.

Is this Agile?  What the heck are we doing!

Get an experienced Agile Coach to guide you in your transformation.  It will be worth it.  When in doubt refer to the 12 Principles of Agile.

This guy sits right across from me and he’s emailing me on this!

Do whatever you can to create trust throughout your team and organization.  That’s one of the top reasons people continue to use email.  Try to speak to people if you can. Get to know the people you work with.

I can’t get all these tasks they gave me done!

Eliminate as many dependencies as you can.  Try not to work on more than one thing at a time.  Context switching will cost you 20% of your time per item.  The more cross-functional your team becomes the less chance that tasks will have to be done by one person.

As Agile implementations fail at some organizations because we didn’t address the uncovered issues, Agile will probably take the hit.  Let’s try and prevent that from happening, by just remembering to nurture, care, feed and grow our Agile transformations through continuous improvement. Hopefully, some of these scenarios have hit home and illustrated that Agile may not be failing us – we just may be playing the game wrong. Concentrate on continuous improvement for the issues that Agile is uncovering.

Oh, and John and I will still be the best of friends after this blog because, you know, healthy conflict is a good thing.  Love you brother!

Liven Up Retrospectives With a Game!

dixit card 3

Having fun at work – guilty as charged!  I’m always looking for different ways to energize my teams and to have fun at work, especially during Sprint and Agile events.  Here’s a great new game, derived from Chris Sims‘ session at the Global Scrum Gathering, that you can play when conducting your Retrospectives.  My teams loved it!

This Retrospective game uses cards from the board game DiXit (which you’ll need to purchase) and proceeds as follows:

  1. Write all the team members names on the whiteboard to keep score.
  2. Spread all the cards out so the team can see them.
  3. Instruct team members to think of the most important retrospective item that they would like to discuss.
  4. Tell all team members to then take one of the cards which they feel best represents their retrospective item (crazy fun pictures on DiXit cards if you’ve never seen them before).
  5. Collect unused cards.
  6. Tell them to now write a description of their retrospective item on a sticky.
  7. Select one person to start.
  8. Person selected puts their card where the whole team can see it (card presenter).
  9. The other team members look at the card and write on a sticky a description of the retrospective item they feel the card presenter is conveying through the picture.
  10. When all are finished step above (may need to time box and disqualify people who cannot come up with anything if taking too long), in round-robin fashion each person guesses what retrospective item/topic the card represents.
  11. When all team members (beside card presenter) have voiced their guess then the card presenter tells everyone what their retrospective item was.
  12. Team members who guessed correctly score a point on the board.
  13. That retrospective item and any other retrospective items that were guessed are put on the board.
  14. Steps 8 – 13 proceed for each team member until done.
  15. The team is now asked to group like retrospective items and prioritize discussion order of items (maybe by dot voting).
  16. The team then discusses the retrospective items in priority order and records action items when necessary.

This game was well-received by the teams and a lot of laughter was generated on the art selection of fellow teammates.  What better way to work then to have fun doing it!

Let the Agile Games Begin!

Dog Poker

I’ve wanted to introduce Agile Games to my teams for some time now and finally pulled the trigger with much success.  It was just before the holidays and like high school students attending their last day of school before the Christmas break, you can imagine that the team’s minds were not as focused as usual.  Yes, the perfect time for an Agile game!

I started off with a quick simple game addressing the effects of multi-tasking, interruptions and thrashing.  This was a game I believe I read about somewhere, but kind of rolled my own with the team.  Anyway – the game went as follows:

I had 4 teams of 3 people.  Each team had a space at the board.  Three columns labeled on the board for each team (“1-10”, “A-J”, “I-X” [the roman numerals]).  The first round I told person 1 from each team to write on the board the numbers 1-10 under the column 1-10 and then do the same for A-J and then the same for I-X.  They raced against each other and I recorded the person with the fastest time.  I then let person 2 of each team do the same and then person 3 do the same while recording fastest time.  We then went through all 3 people again only this time they had to write it in a different order.  They had to write one in the “1-10” column and then go to the next column and write A and then next column and write I and then return to first column and write 2 and so on.  I timed them all again.  At the end of the game, I asked them which took longer for them and obviously it was the second way of writing the symbols.  Why was this?  Because switching focus costs you time.

The game made it so obvious.  If you feel your team is having issues with context switching you could quickly play this game at the beginning of a retrospective.  It won’t take much time and it will spice things up and set the stage well for your retrospective.

The other game that I played with the team is called the “Ball Throw”.  This game supports the theory of Work in Process (WIP).  I had a larger team of about 12 people (you can probably play with 6 to 15 people) and 20 tennis balls.  The object is to capture the amount of time it takes the team to get all the balls in the done bucket.  The rules of the game are:

  • The same person must be the start point and the end point for the balls.
  • The start person can throw a new ball in anytime they wish.
  • The start person yells “IN” every time they take a ball from the start bucket and throw it in.
  • Each person in the team must touch the ball at least once.
  • Every ball toss must have air time (they cannot be handed to the next person).
  • You cannot toss the ball to a person who is right next to you.
  • The end person (same as start person) receives the ball from the last team member, deposits it in the done bucket and yells “OUT”.
  • Any dropped ball is considered a defect where the person dropping yells “DEFECT”, retrieves the ball and continues on.
  • After explaining the rules to the team, they have 2-5 minutes (your choice) to plan and discuss their strategy before they begin the game.
  • At the end of each round, the team has 2-5 minutes to perform a retrospective on how they would like to improve.

This is one of the most popular Agile games.  It is fun and easy to play and enforces the importance of WIP.  I especially like challenging the team in the 2nd round, telling them they can do it faster and then proceeding to put pressure on them to go faster while the round is in action.  This simulates the business pressure they receive in real life.  You’d be surprised how the defects go up in that 2nd round.  Remember after any game to have a discussion on the parallels of the game to the workplace.  We’ve had some good discussions.

If you’re interested in conducting the Ball Throw Game you can use a spreadsheet that I found online and have shared below.

https://www.dropbox.com/s/rfht8thsa57d5as/Ball%20Flow%20Metrics%20Template%201.6.xlsm?dl=0

The spreadsheet allows you to track throughput by clicking an “IN” and “OUT” button for the balls.

Some other resources for Agile Games are the book “Gamestorming” by Dave Gray and the website www.tastycupcakes.org.

Playing the games added another valuable channel for Agile education for the teams and organization.

So have fun and … LET THE GAMES BEGIN!

Cynefin Decision Framework and Agility

cynefin image

I had the pleasure of being one of four Agile panelists answering questions at the Tampa Bay PMI Symposium (good turn out with more than 300 registered).  One of the other panelists, my friend and respected Agilist Steven Granese, mentioned the Cynefin Model.  After that discussion, I felt it would be good to discuss the Cynefin Model and how it supports an Agile process, especially when dealing with complex situations.  So, here it goes …

The world is complex and shows no sign of abatement.  The military learned this as they dealt with different autonomous Al-Qaeda (AQ) cells.  Teams of our military personnel did not have time to contact command to formulate or validate plans.  They couldn’t identify many set patterns because AQ would continuously adapt.  Our military could not be even relatively sure that the same tactical action would yield the same result in each situation.  So, they dropped the silos between teams and departments and opened up communication; empowering the individual teams.  Previous information that was on a need to know basis was now available.  They let their units make decisions, probe with different tactics and then share the learning later on.  This problem area certainly fit in the complex domain of the Cynefin Framework.

Cynefin (pronounced kuh-nev’-in) is a leader’s decision framework developed by David Snowden that aligns things into defined domains.  The framework was developed for knowledge management and strategy, but I believe can assist us in identifying the need for Agile software development.  Cynefin prescribes the way to act on something is based on the domain it falls in.

The five Cynefin domains are:

Obvious or Simple (the known) – We’ve seen this a million times and as such can categorize and respond according to established best practices.  The relationship between cause and effect is well known.

Complicated (the knowable) – Although we don’t immediately know what is happening, we can analyze the situation and come to a conclusion of what must be done.  We can enlist experts to analyze, set up constraints and a process addressing resolution.

Complex (the unknowable) – We’re not able to determine what will cause a particular result. The best course of action is to conduct experiments and check if any or all take us in the correct direction.  A lot of time when human opinion and decision is involved we could be working in this area; simply because humans are complex beings.

Chaotic (the incoherent) – The situation is very unstable.  We don’t have time to experiment or probe since the situation is dire and we need to act.  An IT issue that must be taken care of immediately with no delay may be categorized as such.  If we have no time to figure out a system deadlock issue, we may opt to get ourselves out of this chaotic state by rebooting the server.

Disorder (not determined) – Anything whose domain has not been determined falls into this domain.

Cynefin Table

Image provided by: InfoQ.com

The Cynefin Model suggests that we identify the domain type and respond accordingly.  Agile (Scrum for example) is geared to operate in the Complex domain.  The Agile methodology offers the proper Cynefin response to the uncertainty present in many software development projects.  It is inherently adaptive and uses the “probe, sense, respond” method.  Waterfall could handle Obvious and Complicated domain issues, but would fall flat when faced with a complex situation.

Software development offers issues that fall into all the domain areas, but if you use Waterfall you will be at high risk delivering anything in the complex domain area.  If you use Agile, you could have some minor inefficiencies compared to waterfall in the simple domain, but you will reduce or eliminate the high risk of failure in the complicated, complex and chaotic domains.  It seems sound reasoning then if you’ve got any unknowns involved then your software development projects would be minimizing risk by following the Agile methodology rather than Waterfall.