Retrospective

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

Advertisements

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!