Category archive


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.”

An Agile Team Task by Any Other Name – A To Do

in Agile/Agile Engineering/Leadership/Teams
Sprint Planning Hell

Let me first say, I know the idea of task decomposition is fairly well covered and some might call it a basic practice of any team; however, as a coach helping teams to adopt agile software development, I don’t always see teams finding this practice of defining “how to get to done” as a natural team planning activity. Instead, I see teams getting frustrated with a clunky approach or a high-level of disengaged team members or a member of the process police controlling the meeting that is distinctly a team meeting or I still see the “lead” define the tasks and simply dole them out.

Defining “How” to get stuff done as a team should be the straightforward activity around software development. It should be an engaging activity of brainstorming, learning, sometimes arguing, and ultimately a good feeling of “let’s git’r done.” All-too-often it seems like a torture technique riddled with challenges. These challenges are often rooted simply in poor practices, some of the which include:

  • Creating faux work breakdown structures (yes, I said it — WBS) of standard tasks (e.g. each story has “Design”, “Code”, “Review”, “Test”, “Deploy” tasks). Some would argue this is not a poor practice, but tasks should have context and be relative. Not to mention, this is kinda mundane, requires no thought, and is flat out lazy and contrived.
  • Focusing on the accuracy of hour level estimation. If we are consistent with relative estimation and looking at cycle time, we can come up with the “low risk” and lean approach to determine which stories to work on. Estimation at this level is more of a measure of certainty.
  • Creating tasks and tests that are ginormous — like a 40 hour task for a two week iteration. If someone tells me that it’s going to take 40 hours, then I view that as high risk and we need to keep talking about it to better understand it.
  • On the other hand, creating micro tasks — yes, so many that the Task board looks like like a sticky note factory exploded on the wall or invoke pagination within the tool.
  • Having the developer and tester creating tasks and tests in isolation without any conversation with each other or the rest of the team.
  • Oh yeah, let’s not forget when I get asked about reports that measure how underutilized people might be. Often the focus of understanding “How” becomes simply an exercise to maximize utilization.

That last point about utilization, it seems like a frequent driver of the planning exercise. It’s odd in that sometimes people think that if we don’t have a plan with everything defined that we are going to do before we go do it; well — when the stuff we do get done is complete, we’ll simply stop working and sit there and stare at each other. I’m pretty sure that this is never the case and if it is, either get new people or look in the mirror.

Does any of this sound familiar? Does any of this frustrate you?

Well, I have a few ideas for you to try — most of these are common sense and talked about by others, but it’s always good to mix it up and try something different to get out of the rut or remove the pain associated with planning.

First, abandon planning using ideal hours — I know, I’m crazy — but hear me out. The common rule for any to do or task is that it should take no more than a day to get completed, ideally less. Tobias Mayer’s book called The People’s Scrum contains a curated set of his past blog posts, one in particular called, “When is Scrum not Scrum?” explains his reasoning for non-estimated, day or less tasks — (1) eases tracking – just burndown tasks — the burndown is number of remaining open tasks and (2) it helps to unearth unforeseen impediments that are often just part of what we normally do. While these are great, I would add that focusing on estimates and accuracy of the estimates actually just results in taking the eye off quality and flow of value.

Next, decompose just enough stories to commit to the goal and get started. The Scrum Guide is pretty clear about this:

… enough work is planned during Sprint Planning for the Development Team to forecast what it believes it can do in the upcoming Sprint. Work planned for the first days of the Sprint by the Development Team is decomposed by the end of this meeting.

Now, new teams may need to decompose all stories during a sprint planning, but teams that have been together for a while may be able to quickly determine what stories to do in the next two weeks, how they fit a incremental goal, and then just go. Don’t make your sprint planning meetings more painful — if you are planning for 2 hours and you have enough work to start the sprint, then go start.

Try different techniques for this meeting that encourage engagement. For example:

Taskstorming. A simple approach where the team selects which stories they are going to work on based on past velocity and then, interviews the Product Owner on each. During the interview, the teams is noting on sticky notes the tests and tasks. Once a goal emerges, then it’s time to task [and test] storm. On a whiteboard, write the title and draw a large box for each story. Now have the team place their stickies up on each story. Duplicates can be discussed as well as someone can put up something that doesn’t make sense to anyone else — well discuss it. Through this process, let the conversations flow – observe a story with a ton of task, then maybe it should be broken apart? Taskstorming not only makes the meeting more efficient, but it’ll make it more effective because everyone is involved and engaged in the process. At the end, have folks pair up and help get the data captured in your favorite tool (which means VersionOne).

Other techniques you can try include Task-n-Tell and Test First Tasking.

Finally, as I’ve mentioned in a couple past blogs, put this on the team – this is a team activity. If you are a team member, take ownership of this meeting and you lead it. The Scrum Master or Lead or Facilitator of the team would typically do this, but if you find them directing or assigning tasks out without engagement. Well you have a problem and the best way to change it is for a team member to take over. If you are a Scrum Master or Lead and you are struggling with getting the team engaged, try something new — don’t be insane. Try introducing a facilitation game or asking someone else to facilitate (not the product owner or anyone else in a position of authority).

No one should suffer through a sprint planning meeting. Yes they can be hard, but they shouldn’t be torture — so, inspect and adapt. Time to make them fun and effective.

Remember that at the end of the day, tasking is simply defining the proverbial To Do list to get a story done.

Go to Top