Category archive

Humor

Testivus for the Rest of Us: A Whole Team Testing Experience

in Agile/Agile Engineering/Humor/Leadership/Teams
Happy Testivus

The Story

I want to share a true story of a relatively newly formed agile team. We were made up of ten engineers writing and testing code in C++, Java, and fully embracing the emerging javascript frameworks. The application we were building was both complex and complicated. We were learning how to launch a product, trying to embrace user-centric design, and honestly, I often screwed up as a lean agile leader. All that said, we were a pretty great team and we were constantly learning.

We were in the midst of a new product release that was careening towards a GA date. The testers on our team — who were pretty great at what they did — were getting pressed against that GA date with the build-up of feature inventory. As a team, we were doing an okay job at establishing automation, but we could do more — a lot more. So with the testers in the needs of some aid and the need to shift left more testing, we arrived at Testivus for the Rest of Us.

How It Started

As a team, we often themed our sprints. Sometimes these sprint themes were merely broad brushed sprint goals. We already had the “Unleash the fury, Mitch” sprint in which we literally sprinted to the finish line several key product features. In need of raising our game around test automation and in general, switch the team from a “test right” to “test left” where quality was truly the starting point of all work — we decided to theme a sprint “Testivus.” What better theme than Testivus — time to air our grievances and demonstrate feats of strength.

NOTE: In case you’re not a Seinfeld fan, Testivus is a play on Festivus. See Festivus – Wikipedia for more information.

In preparation, we built the sprint backlog around those items that needed the most attention (we looked at a heat-map of components based on bugs previously found, code complexity, and skeletal impact to the product). This backlog wasn’t just a bunch of technical stories, we focused on the functional areas and created functional validation stories that restated the user outcomes, and we refined the acceptance criteria based on usage validation (as well as early learning from the field – e.g., performance needs, essential data needs, etc.). Some may call this just a regression backlog, and that’s fair; however, our mindset was different — it was all about outcome validation and, to some extent, validation that the product we were making was innovative and would kick-ass in the minds of our prospective users. Also, to note, this wasn’t about a “Hardening” sprint. You could argue this; however, we weren’t at the end of the release, and our core goal was to bring testing left in the cycle.

Once we built the stories and the resulting tasks included fleshing out a test harness, more in-depth unit testing practices and practicing TDD, functional UI test automation, and refining our CI process to extend into CD including bootstrapping test and demo data creation.

The Results of the First Testivus

The tangible outcomes were:

  • Stronger installation and deployment automation including packaging.
  • A robust test data generator and demo data bootstrap.
  • A new & improved test harness that handled both functional aspects as well as continuous performance benchmark validation. The harness covered over 1,800 scenarios nightly.
  • Increased code coverage from single digits to a substantial double-digit percentage.

The most impactful outcome was that team’s mindset which was already pretty good, became hyper-focused on how quality should be built-in. From this point forward, during refinement, the first thing we would talk about is attributes of testing.

The Longer Term

Testivus became a regular occurrence in the context that we called for a “Testivus” day or two every 5-6 sprints. Sometimes the need surfaced when we noticed a trend of bugs in a particular area, field feedback, and a couple of times we “Testivus” as part of a quality hack day.

Reflecting on Testivus, there was a need and the theme was awesome. It changed our mindsets, we had some focused energy on quality, and we had some fun — even though it was intense at times.

The great thing is — this concept wasn’t unique to us. Sometimes teams need a cause and a theme to try something new, and this helped us gel around some learning of good practices.

A couple of years later I joined VersionOne where the development team adopted “meatfest” which was a bug bashing event that had the team grilling out meat and vegetables, and drinking some beer throughout the day — all the while just fixing a bunch of stuff (I would point you to the awesome blog on this topic, but someone took it down).

Please let me know if you have experienced the same or would like to discuss further. Thanks for reading!

Update: We definitely weren’t the only one’s going down the Testivus path — just Google “Testivus.”

Friday is Always Better with Bacon

in Bacon/Humor

Problem Solved: Formula to figure out How Much Detail is Required with Agile Requirements

in Agile/Humor
Documentation Formula
WARNING: Shameless plug for my session at Agile2014 ahead.

I recently got the priviledge to listen to Alistair Cockburn talk to a small group at the VersionOne offices. He told the story about Kent Beck and how the idea of how the user story on notecards was born (I’ve read about this before, but it was great hearing it from Alistair). He talked about how the card was just that — a card with a title that reminded the developer and the target customer/user what they were building, maybe there were a few notes jotted down on the card. The narrative about the story wasn’t captured on the card — the details were verbally communicated because the developer and customer were all in close proximity of one another — they did this crazy thing, they simply walked down the hallway and talked.

In addition to this story, Alistair spoke about his experiences with a team that had development in Singapore and the business folks and architecture worked in the states. The company was having challenges with the team in Singapore at getting things done efficiently and, in some cases, getting things done right. It seemed like there was an inordinate amount of time that had to be spent on discussing requirements and getting questions worked out. The company decided to send some of the business and architect team members to Singapore to work out some improvements. When they did — the quality and productivity went up. When they returned, it took just a couple weeks before productivity slipped and all gains were lost. The reason for these results seems obvious — timezones, communication barriers, and not being able to have impromptu conversations can have a great impact on how well teams understand the requirements especially since a lot of conversations capture the specifics.

Hearing these two stories triggered some ideas in my head, and I thought — why can’t there be a simple formula we can use to gauge the amount of detail (words) we capture in a story to make it work. Through some hard work — I’ve now have that formula.

Here are some factors that I think go into figuring this out:

  • Complexity – just how well does the team understand the story and how hard the team thinks it will be, either from experience or flat out guessing. Usually captured as story points.
  • Difference in Timezones – the number of hours that separate us greatly impacts how fast communications can happen, especially if the communications occur near the bookend points of the day.
  • Auditing Requirements – audits are generally costly and require an additional amount of documentation overhead.
  • Multiple Offices – when people are in different buildings, it raises the amount of details that have to be captured.
  • Offices on Different Continents – although this somewhat relates to timezones, there is also the fact that people speak different languages. Even if they all agree to use english as the primary business language, there’s still slang, accents, and even cultural differences that impact communications.

How Long the Team has Worked Together – knowing each other is key, we figure out accents, we are able to exchange less verbal words, and we learn how to work with one another — what level of information is required to work effectively as a team.

So I reached out to some friends and the folks at Tagri Tech, and with their help — here’s the formula we came up with:

Amount of Words in Story = (Complexity * (1+ max absolute difference between timezones) * (1 + # of annual audits) * (Total # of locations * # of continents)) / (# of quarters the team has worked together)

And here’s the formula in action:

Documentation Formula

Multiple simulations have been ran and I found that the formula works in less than 0.01% of the situations. The people I’ve been working with at Tagri Tech’s statistics analysis department have ascertained that every team is different, and every product is different — this means that no matter how much documentation you have — the people involved in creating the documentation or the target consumer of the documentation really are not going to read it. They found that while some documentation like compliance reporting and end user documentation are necessary, much of the collaboration level docs are only consumed by the person that created it.

Ultimately, Teams will generally work together to figure out how much details are truly required to facilitate working effectively. If your teams are having challenges with how much documentation is required within Agile Software Development projects, then please come to Agile 2014 and check out my session on Friday at 9AM in the Sanibel room, we’ll talk about some ways teams can workout their own formula.

Best Day Ever

in Agile/Humor/Product Management/Project Management/Teams

My dog Mocha has a great tail — her fur is fawn colored and her tail has a white tip. My wife and I call Mocha’s tail the Happiness Meter. You see, you can tell how Mocha feels based on what her tail is doing. She has multiple wagging patterns:

TailPatterns

Every morning, when I wake up — Mocha is there with her tail going in the helicopter pattern. Yes, this means that she is extremely happy to simply be waking up to another day. She does this every day — to her every day is the BEST DAY EVER. The one thing to know about Mocha is that she’s getting older, she definitely has stiffness in her joints, she has a bum knee, and she suffers from bouts of mild pancreatitis. Even if Mocha went to bed not feeling well or wakes up stiff — her outlook is always, this is going to be the BEST DAY EVER.

We’ve all heard of the power of positive thinking — heck, there’s probably a couple hundred books on Amazon written about or referring to the power of positivity. But since we are humans, it’s difficult to squelch down the trials and tribulations of day. In the software development world, we talk about “the death march.” This is that project that drags on, is considered a failure before the first user even sees it, the one where the management tells folks to work on the weekend, the one where for every bug fixed someone finds two more. If you work in information technology, then you’ve been on one of these projects.

Now since you are reading an Agile blog, you are probably waiting for the Agile Punchline or to hear about the Agile Secret Sauce to help over come the challenges of these projects. Well, the reality is that Agile generally will expose problems earlier and maybe make you realize that this project is going to be painful and heading for certain doom. We hope that we course correct or try something different, but sometimes we are simply just in a bad place and cannot get out of the rut.

So while working on these projects, people come dragging in for another day of drudgery. Another day of running on the hamster wheel and not getting anywhere. Another day that the project is dragging us down — in fact, today just may end up as the worst day ever.

Remember, today didn’t start out as the worst day ever, it started as the BEST DAY EVER.

  • Today is the day that no matter what happens we will find something positive and see how today is better than yesterday.
  • Today we will find that our small failure is just that, a small failure — and we learn from it, and have a piece of knowledge that we didn’t have yesterday.
  • Today is the day that we celebrate finding defects, because those are defects our customers did not find.
  • Today is the day that we find joy in having to refactor some old crappy code, because we know that when the next developer visits that code — they’ll get to enjoy changing it, not dreading the fact that they are likely to break something.
  • Today is the day that we move one day closer to getting the project out the door.
  • Today is a great day to laugh with a coworker.
  • Today we admire what has been accomplished versus what is remains.
  • Today is going to be the BEST DAY EVER.

And if you don’t believe me, just ask Mocha.

Who Knew? Bacon Duct Tape

in Bacon/Humor

Bacon Duct Tape

 
Just when you thought you’ve seen everything, you stumble upon some duct tape with bacon printed on it. Click here to buy a roll.

Go to Top