ScrumBanAgileFall

There are a million posts on which Agile methodology is better to use, this post will not be one of them.  Nor will I bash either approach.  The engineers before me have thought alot about how to optimize building software and created these frameworks to help us, and I thank them for that.

So what really works?  Change.

Is daily scrum becoming monotonous?  

Cancel it!   Chances are you know what your team mates are doing anyway.

Scrum software becoming a pain to use?

Move back to a physical board as a radiator.

Sprint iteration too long?

Try to shorten it or stop using iterations.

Requirements or stories poor?

Communicate to stakeholders you need their input before you start the work.

Is Kanban too open ended for your project?

Try Scrum for a more structured project.

Like the Kanban board, but some of the structure of Scrum?

Mix and match people.  It’s ok, feel free to experiment for what works for your team.

The point I am trying to make is that you need to know when to “break the rules” and use independent thought.  Don’t be afraid to experiment and innovate to find what works for you.  Blazing the trail sometimes is better then following a path you know does not work. Be bold, Be Brilliant, Be Happy.

Agile sucks? 10 things you are probably doing wrong…

Scenario: Your team is heading into a sprint planning meeting to determine what they will work on in the upcoming sprint.  Everyone is happy, life is good until the multiple stakeholders show up with one line requirements wanting the work completed on Friday.  Oh, and here’s how you need to implement the solution technically.

Reaction:  The team goes through the five stages of grief (Denial, Anger, Bargaining, Depression, Acceptance).  The work is still committed to, and the team is discovering half way through the sprint that each item is really an “epic” and not just a story.  Now the team stresses out trying to rush to complete the committed work or the velocity will go down.   In the meantime, 5 new bugs have popped up and an emergency requirement has just been added at the last second.  Oh, one more thing, there was carry over work from the last sprint that was not accounted for.  Moral goes down, stakeholders are not please, and the cycle continues again in the next sprint planning.

Welcome to a typical day in tech.

Antidote: There are a few things wrong that are going on here.  Can you see them?  Let’s look at this together.

  1. Too many stakeholders.   – The team needs one voice to speak and ask for the work to be completed and prioritization.
  2. Requirements are too vague (duh).  – You need to prep your stakeholder (singular) with backlog grooming work BEFORE the meeting occurs.  I consider this practice before the sprint planning meeting.  Prepping the stakeholder to deliver the information you want, in the format you want is key to a smooth sprint.  (Don’t forget, you will still go over these items with the team together, this is just prep). * BTW, if you are not already, I strongly recommend using the Gherkin format for writing stories so they can be turned into functional tests later.
  3. Stories that are not ready should be rejected. – This is not new, but do you have the courage to stand up for your dev team and pushback?  You might lose the battle, but ultimately winning the war by setting the correct expectation.
  4. Requirements are huge.  – Break the stories down (duh).  Anything larger than a “medium-sized” story should be broken down.  Do this to give yourself a chance to succeed.
  5. Overcommitment. – If the story cannot come off for any reason, have the team commit to an investigation to deepen the requirements.  This provides some movement on the work, and let’s the stakeholder know you are still not comfortable forecasting a solution or timeline.  Or perhaps commit to “code complete” or some other partial status to let the stakeholder know that movement is occurring, but it will not be delivered completely by sprint end.  Alot of times, things like testing, setting up an environment, releasing to prod, or even waiting on someone else is missed when making the commitment.  Break these up and commit to them separately, by doing so, you are communicating better and setting expectation.
  6. Don’t fill up the cup completely. – If you were drinking coffee, would you fill the cup to the absolutely top before drinking?  Of course not, that would immediately cause you problems when you tried to drink it.  So why would you max out your capacity in a sprint?  Think about it, you are always going to have interruptions, bugs, new requirements coming in the door (that why it’s called Agile).   I like to tell the teams to budget for 60% capacity to leave some leeway for “sprint-busting” work.
  7. Not Tracking the velocity. – The team needs to see their “scorecard” against commitments so they can get get better and self-manage.  make a point to make sure they are not feeling performance pressure of their velocity is slow.  This is a tool to help everyone get better around planning, not to weed out the “non-performing” developers.
  8. The Dreaded Deadline – Stop these now.  Really.  The team should design the correct technical solution and how long it will take to complete.  If the estimate is too long for the stakeholder, they can use tools like cutting scope, changing the date or sometimes adding resources (forgive me readers of “Mythical Man Month”).  The technical team should always be offering alternatives and solutions that work.
  9. Stop telling us the solution – Often stakeholders are very comfortable providing direction, but in the wrong way.  When you are confronted with someone that gives you the exact technical solution they want, you should stop right there.  Your powerful tool is of course to ask questions.  “What are you trying to accomplish?”, “Why do you need this?”, “What happens if we implement only this?”, “Does it have to have a the head of a shark and the body of a lion?”.  Asking these questions allows you to take back control of the requirement and really drill down what the stakeholders need.
  10. Have Fun. –  What?  This is not in the Agile Manifesto!  Nor is it in any of the methodologies.  The explanation is simple.   Software is built by people.  People need recognition, challenges, and want to enjoy their career.  People are what make companies.  It’s not signs or logo, nor the colocations or Macbooks we tote around (sorry pc users).  Having fun and not stressing about your job increases retention, but also creates a tighter team bond.  You will accomplish more, have better quality software, and overall be a more successful with a lot of smiling friends around you.

Now that sounds pretty good, doesn’t it?

-Steve D

Nerf War Week

When my company asked during a leadership meeting if someone could run a NERF game, my hand sheepishly went up.

“I’ll do it,” I said. Though I can honestly say at that point in time, I had no idea what I was getting into.

What I was getting into was five days of mayhem, as teams of warriors turned the 9th floor into a battleground. The prize was glory — though many felt the reward was in the fight itself.

More than 125 participants from 16 different departments including Analytics, Talent Management, Software Engineering, People Resources, UK & US Marketing, Project Management, IT, TechOps, Creative Services, Quality Assurance, and Business Intelligence joined forces to make this memorable event happen.

Eight teams were created based on an animal name/color to distinguish the competitors in the “arena.” Members of every department were mixed into teams such as: Salamanders, Warthogs, Ferrets, Dingoes, Parrots, Ducks, Badgers and Spiders.

Each day the teams faced a new challenge to test their skill and mettle in the arena. The challenges included:

  • Sink the Biz: Find the “biz” among the crowd, win the game
  • Capture the Flag: Capture the symbol of honor from your opponent
  • Duels: 1-on-1 challenges to test accuracy and resolve disputes
  • Manager Target Practice: Win points in a shooting gallery comprised of managers
  • King of the Hill: Three teams compete, as two attack and one defends “the hill”
  • Armageddon: Freeze tag and “Last Man Standing” (all teams)

The “arena” served us well, as the games took place in the kitchen and the east corridor. A new configuration of decorations, obstacles, lights and office furniture set the tone for the game to be played each day.

Now if you’re currently thinking, “This sounds really cool,” you would be right.

How amazing is any company that lets you play NERF games during the workday to meet new people and blow off some steam?  Enova “gets it,” and realizes the importance of stimulating the mind at work. We have fun, are more engaged and have a culture we are proud of.

By Steve Durko