Category Archives: Lean

Unit Test When? Why?

Agile, Lean, Software Development, Software Engineering, Web Development, , , , , , , , , , , , ,

The topic of when to unit test came up in a recent discussion with some people who are smarter than me. I’d just finished listening to a great presentation on Software Gardening. I hadn’t considered the option of Test First as I’ll describe it below. I’m not promoting the concept, but I thought it was interesting. Also, I’ve done what I’m calling Test Now, but I’ve never really heard it referred to as anything but another breed of Test After. The distinction is meaningful, and I think it deserves to be called out. I’m going to go out on a limb and make the assumption that you understand the importance of unit testing if you are reading this.

Why have this discussion? Because we want to be lean and do the minimal amount of large-scale rework. Also, because we want to understand the benefits and downfalls of each approach. In theory, there will be “best” options for a given set of circumstances. Let’s see what happens.

The Test When Continuum

I’m introducing the Test When Continuum as a way to help explain the commonalities and differences of these various test practices. The way I’m considering them is by the absolute amount of time between writing unit test code and production code.

Assuming we have a story or feature with 10 testable units taking one unit of time to complete each, we get the following dataset.

Given the assumption that testing beforehand is always best, and the data above, our test continuum looks like this:

Test First

First off, I misspoke when I said I’ve never heard of this approach. It was proposed by the software architect team at one of my workplaces in the hazy days of the distant past. I just hadn’t heard it called Test First Development, or if I did– I blocked it out. At any rate, in this particular gig, there was a lot of top-down design (or there was meant to be). The proposal was, if the architects wrote unit tests for their platform features up front, developers could just code monkey up and make those tests pass.

I was still learning at the time, and the idea seemed intriguing, if slightly wrong, and I couldn’t figure out why. For whatever reason, my Spidey-sense was tingling. I chose to ignore it, and as it happened, the architects didn’t have the time or discipline to take this approach either. So no harm was done.

Looking back, I’m sure my feeble brain was trying to tell me a few things:

  1. Throwing design over the fence with a set of requirements creates pretty much every problem we see in waterfall-type project management of software. Stage gates, anyone?
  2. Even if the developers had taken requirements and written every test possible, the approach
    • Doesn’t allow any flexibility in design when discovery happens mid-development
    • Creates a false imperative to stick with the original design no matter the cost
  3. There had to be a better way.

Consider your tests as eggs and the code as the critters inside the eggs, and I’ll drop some amazing English idiom on you.

Test Driven

Commonly referred to, by me at least, as the Holy Grail of testing. It solves all of the problems above. Does this mean the world should just give up every other type of development and convert to TDD (yep, this is just a link to the Wikipedia article on TDD)? Under the right circumstances, maybe!

I’ll say this: the test-driven approach leads to the best and most solid code I’ve seen in most cases. If you are doing Object-Oriented Programming (not your second semester college professor’s OOP, but modern OOP favoring SOLID, composition over inheritance, minimal state, and immutability), and you follow Red/Green/Refactor creating the simplest tests and bits of code to make them pass, then you refactor responsibly with the guidance of a skilled coder, you’re probably going to produce SOLID and clean code. There are additional benefits like semantic stability I won’t get into in detail.

Test Driven works well in most general cases as long as you are operating in a greenfield/new code environment.

Test Now

What’s this? Another made up name. I’m on a roll today with the Test When Continuum and Test Now. I must be a writer to make up so much garbage.

I feel like any kind of testing done after a material code change is always referred to as “Test After”. Let’s change this because there are varying strengths and weaknesses in the approaches.

The idea of Test Now is that after we complete a small, testable unit of code, we immediately write a test and make it pass. Then we look for opportunities to refactor our code and tests. Simple. Very similar to TDD, but perhaps with a couple of benefits under certain circumstances:

  1. You’re working with people unfamiliar/uncomfortable with TDD and they are driving.
  2. Your environment is exceedingly brownfield or “legacy” (existing code without tests and hard to test).
    • I know what you’re gonna say: “Just read Working Effectively With Legacy Code by Michael Feathers and all of your problems will be solved!” (Fantastic book by the way.)
    • The problem is, getting good at TDD takes time, practice, and diligence under the best of circumstances. Now we’re going to add learning how to effectively test legacy code to the workload at the same time. It’s a difficult thing to ask. The skills are important, and prioritizing what is most important can be difficult. I can’t tell you what would be best for your team.
  3. Your organization has just bought into the idea of Test After, and you want to move a step in the right direction.

Test Now gives quite a few of the benefits of Test Driven and is a nice place to stay for a while, but stick with those TDD katas. Keep practicing. Learn from Michael Feathers. In the meantime, Test Now is the second “Lean”est approach on our Test When Continuum.

Test After

Similar Test First in more ways than one, I’ll use another egg idiom to make the point. Testing after a feature or story is complete results in an “all your eggs in the same basket” scenario. Untested production code is fragile. All it takes is a couple of false assumptions. Maybe a sub-optimal design choice. Next, your tests are revealing the need for a systematic overhaul of the feature or story. At best, you hobble along and put tech debt stories in the backlog to fix it up later. Hopefully, you have time to get to them.

Conclusion

If you hadn’t guessed, I favor testing as close as possible completing increments of code. Before the code is written when possible– and after when it makes sense. General benefits are flexibility and usually better design.

My gratitude to Ben Davidson, Craig Berntson, Kaleb Pederson, and Dwayne Pryce for their eyes and time reviewing this article!

Here’s an updated Test When Continuum:

Response Unicorn Isn’t Responsive (When Your Team Doesn’t Get “Agile” or “Lean”)

Agile, Career, Leadership, Lean, Learning, Software Career, Team, , , , , , , , , ,

In response to Agile: 3 Signs That You May Be Drinking Unicorn Blood by Joseph Nielsen. Joseph is a friend and former co-worker who’s reviewed my stuff in the past, and we collaborated on the concept for this post. I’m just a year late in publishing it.

Whatcha Mean We Wanna Be Agile? What The Hell Is Lean?

Having spent at least half of my career on teams with ad hoc organization and work practices, this is a question I once asked. It was my first time at Agile Roots in early 2010 when I knew I wanted to be Agile. I mean, I understood the value of some of the tools and practices often associated with Agile. Like several people from my company at the time, I had caught the “vision” and thought bringing back some of these tools and practices would make our organization Agile.

I was a development team lead at a previous employer at the time and was utterly unprepared for the level of resistance we would receive from both upper management and individual contributors on my team. Knowing what I know now about change and why people find it scary, I’d recommend my younger self to read the book Fearless Change: Patterns For Introducing New Ideas or a similar work. Nevertheless, I (and several others) pushed forward with our “agile rollout.” We created physical kanban boards on every empty wall in sight and held standups around them. In the meantime, the company was hiring traditional PMO project managers who were trying to put it all into MS Project, and some folks were trying to get traceability by plugging the results of standup into electronic kanban boards using Team Foundation Server.

Rightly, many folks were questioning the approach and overall vision. Developers just wanted to go back to having their 30-45 minutes being spent in standups back. Management wanted PMO-style project traceability, and accuracy be damned. Analysts wanted to build their requirements and throw them over the wall to developers. QA testers and dev wanted to interact as minimally as possible.

They were all quoting Carly Simon whether they knew it or not.

Are you seeing some problems?

We didn’t get buy-in.

We didn’t have a concrete strategy for implementation.

Most importantly: WE WEREN’T HAVING RETROSPECTIVES. For some misguided reason, we made the same mistake I’ve seen so many others make: we thought standups were the key, not retrospectives. To be honest, I’m not even sure we knew where to start.

I’ve heard this called frAgile. At any rate, eventually something had to win out, and it was the waterfall/ad hoc approach. We took down all the boards and ended all of our agile experiments at the direction of leadership. I don’t blame them. The whole situation was a hot mess.

Other Ways To Do It Wrong

I had seen the light, and therefore, the next company I worked for wasn’t adamantly against Agile. I made sure of it. However, that company is no longer in business. No, I don’t think it had much to do with their agile adoption or the semblance of it they had. This group had many of the basics of Scrum in place, even if they got there partly by accident.

They would pick up bits and pieces and bolt them on until, at a certain point, they had standups, planning meetings, reviews with stakeholders, and a leader huddle which sort-of worked like a scrum of scrums. But they were estimating work in hours, they didn’t organize cross-functionally, stuff was “thrown over walls” for others to pick up all the time, and THEY WEREN’T HAVING RETROSPECTIVES.

You might ask, where did the good practices come from? The folks in charge had those ideas. If an idea didn’t come from someone in charge, it probably wasn’t an idea worth having. All fine and dandy, but you can imagine the teams didn’t feel much autonomy (a key motivator from Daniel Pink’s Drive: The Surprising Truth About What Motivates Us). They certainly weren’t coming up with a lot of great ideas on how to be better.

I came in and still had my Agile Roots-colored glasses on. Everything I wanted to do was related to getting folks thinking about continuous improvement, continuous learning, and reflecting on what we were doing and experimenting to see what we could do better. (By the way, I believe that as an Agile organization, those are the main components you MUST HAVE to get to a thriving place.)

At any rate, my enthusiasm was– out of place, and my leaders reminded me on several occasions that I should mind my position and keep my head down.

So I did.

They promoted me for it. Twice.

With a little more clout, I picked my battles, and where possible, I tried to get the folks I worked with to think differently. We were starting to see some progress. Developers were getting excited about our work again. They were getting back the passion for this amazing job we do. By this time I was the software architect for all the teams, and I was unhappy. Even if folks in the org were starting to catch the vision, upper management was not. I believe they thought we had our working system and didn’t need to try to make it better. Two years was an awfully long time to see as little progress as we had, and I felt like I was still dragging leadership along kicking and screaming.

Additionally, the company was struggling financially (and worse than I knew). When I announced my intent to start looking for another job, the next day I was asked to put in my notice after having been promoted during that same calendar year. They couldn’t afford me if I weren’t in it for the long haul.

So I tucked my tail between my legs and decided to do better at picking my next employer. I wanted a place where Agile was already a reality, or at least where a culture of learning and improving wasn’t just “this silly idea Will has.” Three weeks later I was starting work at what I hoped would be the right place. The lesson, as far as I was concerned at the time, was that bottom-up influence doesn’t work for Lean-Agile adoption.

The Grass Was Greener (Purpler)

HealthEquity touted their culture when I was interviewing, and I DID NOT buy into it at first. My previous employer was ranked in the top 50 for corporate culture in the nation more than once by Forbes. “Culture” was no longer a brand of kool-aid I drank. I guessed the purple drink was probably laced with cyanide or strychnine.

I did know three things about HealthEquity:
1. A friend of mine already worked there, referred me, and spoke highly of the place.
2. The director I’d be reporting to was new to the company, and he seemed to share some of my values and was open to new ideas.
3. The company was offering competitive wages including stock options. I didn’t assign a mental value to the stock options (they had none), but I figured if they were incentivizing folks by giving them a stake in the company, that probably wasn’t all bad.

It was enough. Now I’ve worked for HQY almost double the amount of time I’ve ever worked anywhere else. We’ve been through good times and bad times and great times.

When I started, there was no SDLC at HealthEquity. Stakeholders would sit next to developers and tell them how to program. Developers would push code directly to production and had admin access to the production database. We had a QA manager (in a QA department of one), and he ended up doing DevOps and release management as a full-time job because no one else was doing it, and the company assigned him the “quality issues” they were having with releases because that’s when everything broke.

Work was very ad hoc with a tendency toward waterfall. I don’t remember my actual response when I was finally allowed to contribute effort toward a production project that wasn’t a bug, I know I was ecstatic after the months in purgatory. I’m not sure if I let the “excuse me” out when my director asked me to create a comprehensive design for an entire project that looked like something that would take months to complete before I wrote a single line of code.

Of course, I tell you this to supply a baseline. HealthEquity is now one of the premiere agile shops in Utah. How did we do it? RETROSPECTIVES. Partly.

It Matters Who Buys In

The company hired a new CIO/CTO about three months after I started. Her role was to bring us to some semblance of order, so we could scale predictable teams and get the quality problem under control. I think it was her second month when we had some ridiculous number approaching TWENTY urgent production releases because each successive release to production either didn’t fix the problem we were trying to fix or they caused a cascading issue so drastic it required another urgent release.

The CIO/CTO was patient and prescribed a strict diet of agile conversion and a focus on quality. The quality staff ratio improved to one tester for every two developers in short order. A director of PMO with a strong Agile SLDC background was brought in. Our tooling and work pipelines were updated and organized. We organized into cross-functional teams of dev and qa. Then came the consultants.

To their credit, the consultants did a great job setting a baseline for what Agile should be while training us on the specific process of Scrum. The sessions were filled with retrospectives and lean coffee. I was in heaven. Yes, there were a few folks who were not pleased. Mainly those who’d been with the company for some time. They didn’t take long to self-select out to new jobs once the future of HealthEquity technology became clear. The baseline was set, and that was one of the keys.

The consultants, I think, were a critical factor. It showed everyone two things:
1. Leadership was serious about this agile thing because they were taking us away from the constant pressure to deliver more features so we could learn about it.
2. As a company and a team, we were willing to put our money where our mouth was. Hiring consultants is in no way cheap.

Is this the end? Have we achieved “AGILENESS LEVEL 5000”? No. Will we ever? Probably not. The secret true agilistas know: there is no such thing. There is only review and improve. At HQY our technology leadership (and even our CEO) understands this. We give our teams room to experiment, fail, improve, succeed wildly, and be better tomorrow than we are today.

The goal of this phase of adoption was to set the baseline with a consultancy group, create ground rules, then unleash the continuous improvement and learning. The consultants were brought back on site multiple times to iterate. Over time, folks began to catch the vision. We hired in-house agile coaches to take over the continuous improvement. These are people who could be consultants in their own right, but wanted a 9-5 at a local company. The dedication to doing nothing halfway drove home the idea that HealthEquity is in the lean-agile thing for the long term.

Why Is It Awesome?

At HealthEquity, teams work together with leadership to take action on feedback and retrospectives. At first, I remember being surprised when issues were actually addressed. I’ve never worked somewhere so responsive. In previous organizations, near revolt was sometimes required to make any meaningful change. Here, we adapt, adjust, test our assumptions, and try something new when we don’t get the result we hoped for. Again: retrospectives. But the source of our willingness to experiment and take action to improve comes from the top down. If your organization’s leadership doesn’t believe in it, and you do– maybe it’s time to start looking at better options.

Like Joseph wisely quoted when he read this “love is a battlefield”. Struggling and improving together is the point; it is the destination. Today, we are working toward a low WIP-limit team collaboration approach and building out the quality and tooling to support Continuous Delivery. Will that be the end? No. Our teams will not settle. They will continue to find ways to improve. It’s in our DNA.

Let’s Retro This Article, Shall We?

What went well:

  • My reviewers were fantastic, and the article wouldn’t be half as well written or have as many good images/memes without them (THANK YOU, Joe, Katie, Britton, Caulin, Matt.)
  • It’s always a little dicey supplying personal details in an article like this, but I think it adds some credibility and people seem to like it.
  • Writing about this helped me increase my understanding of the patterns of a successful agile rollout.

What didn’t go well:

  • The speed with which I completed the article. MONTHS.
  • I let it block other things I’ve intended to write.

What could improve:

  • It could have maybe been broken up into a couple of articles– I waffled over this a lot. So looooong.

I’d love to see your retrospective items in the comments, fair reader.  Also, why not check out my other Agile articles. See you next time.

Kata Cups: Solving Kata Problems Since 2014

Agile, Kata, Lean, Learning, Training, , , , , , , ,

First: credit for this concept goes 100% to Llewellyn Falco. I was running one of my favorite Javascript coding exercises in 2014ish at a Utah Software Craftsmanship meetup, and Llewellyn not only showed up, but he also solved the problem I was having with my presentation style.

The Problem

Who’s run a guided code kata for more than three people?

Need a definition for a guided code kata? Start here, then add the idea of one person either displaying steps to follow and/or performing the steps on a large screen in front of several people. Guided katas are commonly performed at user groups, lunch learnings, or at a local coding dojo meetup.

Back to my original question: who’s run a guided kata for more than three people?

Still reading? Then you probably relate to the problem. The problem is:  how can you tell when a reasonable percentage (or 100%) of the room is ready for the next step?

In my case, I was leading a guided kata for a room of around thirty people. Even with about half the room doing the exercise in pairs, I was spending a lot of time asking, “Who needs more time?”.

The Solution (hint: it’s kata cups)

Cut a notch in two sides of some paper cups, and ask people to put them on their laptop screens when they finish the current step of the kata. When a significant agreed upon group of folks are ready, call out “Cups down!” and move on to the next step.

Simple.

When you don’t have any cups handy, try having everyone fix a sticky note to the top of their laptop. Post-its work in a pinch, but the cups are more reliable– and fun.

The use of kata cups has spread throughout the office at work. It’s fun to see something so simple aid in the success of a lean-agile culture. So many things we do are about visibility and collaboration and finding the right solution just-in-time. Kata cups are no exception.

Lean Teatime Is Both More And Less Than Lean Coffee

Agile, Leadership, Lean, Team, , , ,

Ok, I’m going to share this like no one has ever thought of it before.

braceYourselvesMeme

The other day, I was giving a lightning talk at Utah Software Craftsmanship about how I run bi-weekly team meetings with Lean Coffee. In short, I highly recommend the practice. It helps keep our meetings quick and on-task. Succinct really.

People seem to like it because we discuss the most important things, and we usually finish early.

If you aren’t allowing your meetings to end on time or early– use this opportunity to rethink your life. You don’t want to sell anyone death-sticks.

Back to the lightning talk. I spoke for about three of my five allotted minutes and opened up the floor for questions. There were a few, but the most interesting question by far (paraphrased) was this:

How do you get people to arrive at desisions when running a meeting with Lean Coffee?

The query took me by surprise.

For a moment, I considered decisions that came out of our meetings. Granted, there weren’t a ton. Often these sessions are more informational. Sometimes they result in questions I don’t have an answer to, so I take to-do items and communicate back to the team later.

However, we did reach decisions. We planned a team party, for example. For these types of situations, I looked for a majority consensus. Often, we found ourselves using a technique I will now dub “Lean Teatime”.

6808987192_cb44303a47_z

Lean Teatime

Lean Teatime is a subset of Lean Coffee. It can be run either in the middle of a lean coffee session, or completely separate from it. The gist is simple:

  1. Set expectations by making clear the intent of the Lean Tea session (e.g. selecting a venue for a team party).
  2. Make sure everyone has access to Post-It notes and Sharpies (the tools of any agile facilitator).
  3. Set a timer (2-5 minutes) and have the group come up with as many ideas as possible. They will write each thought on an individual Post-It.
  4. Organize similar items into groups and stick them to a desk (or wall for bigger groups).
  5. Give everyone groups/3 dot votes and turn them loose to place dots on the item groups they prefer. Allow one dot per group or multiple, your choice (I prefer 1 per).
  6. Order the results from most votes to least. In the event of a tie for first, vote one more time with the two tied items only.
  7. I like to do a fist of five at this point to see if anyone just hates the thing that ended up on top. In this case, I’ll ask the group to offer mitigation suggestions.

All of this only takes a few minutes and usually has a positive result.

So there you have it. The “genesis” of Lean Teatime. I hope you find it useful.

If you enjoyed the article, hit me up on Twitter or leave a comment below.
If you disliked the article, hit me up on Twitter or leave a comment below.