I wish there were more sites like Todo MVC. It has a number of different implementations of the same simple web site using different JavaScript frameworks. It makes it trivial to make apple-to-apple comparisons. I like Agility, Knockout, and oddly enough the jQuery versions.

Over the past week or so, I’ve become quite a fan of FitNesse. FitNesse is “a simple tool that allows non-technical users to specify and run acceptance tests for software systems.”

Our situation is familiar to many programmers. We have some legacy code that we desperately need to refactor, but the code is not under test. It was written by a team of engineers that’s no longer with the company. There’s some documentation, but it’s far from complete. The software is in production and is used by a number of clients who would be very upset if its behavior changed.

The piece of the system we want to rewrite is data-intensive. It’s the part of the code that takes client data feeds and import them into our system. I’m sad to report that the logic is scattered between some C# libraries and SQL stored procedures. The previous team wrote ambitious integration tests in NUnit that tear down databases and rebuild them each test. While better than nothing, code coverage is low and the amount of SQL code coverage is uncertain.

What we need is a simple way to exercise the feed importer: give it some data and check that the data imports as expected. Some tables in, some tables out. Enter the FitNesse tests. When Michael Feathers wrote in his book Working Effectively with Legacy Code that systems should be under test before refactoring, he did not say they had to be unit tests. Once we figured out some of the tricks to getting .NET fixtures working, it turns out it’s quick to mock up a simple customer data feed and import it into the database with our FitNesse fixtures. For guidance, I suggest Gojko Adzic’s e-book Test Driven .NET Development With FitNesse.

While these first tests were good, it wasn’t clear that they offered many advantages over our existing tests. At first, there was a lot of repetition and I saw FitNesse as an inferior tool. As I started to learn about page includes and special pages like SetUp and TearDown, though, I started to see FitNesse pages as modular pieces of code like methods and classes, and I was able to refactor away the awkwardness of the early tests.

However, when we started loading multiple data feeds in succession, the advantages became crystal clear. To verify data in FitNesse, you write the expected data into a Wiki markup table. Because we were having trouble getting the FitNesse fixtures to work, we kept paring down the data feed until it was a single unit of work.

Seeing the expected data in a simple table on a web page made the relationships between the incoming tables clear, not only to us but to our product owner and QA engineer as well! Things we thought were bugs turned out to be good conversations with our product owner about tricky business rules. After the first dozen tests or so, the NUnit tests looked cumbersome and wordy in comparison.

Yesterday afternoon in a conference room, I got the whole team of developers writing FitNesse tests. To some, dissolving the barrier between development and QA is a cherished sceptre of agile software development power. For them, the light bulb came on. Everyone kept writing tests today, even though the training was over. Tomorrow, we’ll get our QA engineer up to speed. He may not be writing his own fixtures right away, but he can certainly mock up new data conditions and write new test pages.

In retrospect, we could have achieved similar results if we’d stopped thinking of the NUnit tests as unit tests and started thinking of them as black-box integration tests, and if we’d simplified the data. In contrast, the NUnit tests took real customer data with multiple scenarios through the system at once and they verified the results at each intermediate step. Writing these NUnit tests required intimate knowledge of the data import process, which only one developer had taken the time to master.

With the FitNesse tests, I don’t have to worry about the steps in between and there’s only one effect happening at a time. And, the NUnit tests would have been a hinderance in our current project, whose goal is to replace the bulk of that code with a newer, faster implementation anyway. I can’t imagine feeling confident in our redesign if we had to rewrite the tests to verify the design.

Have you been able to make use of FitNesse or another testing technology like Cucumber in your project? Please share your thoughts in the comments.

As a concerned American, I read David Brin’s recent article about the differences in how Democrats and Republicans wage war with interest. It’s well-written and worth careful consideration. He posits that since Reagan, the Democratic strategy of limited, targeted involvement is more effective than the all-in Republican one. He wrote the article to refute claims that the Democrats are “soft” on war.

As a proponent of agile delivery methodologies, I saw another parallel. His description of the approaches reminds me of comparisons made between agile delivery and traditional delivery methods. In the article, Brin echoes interviews with retired generals and admirals that on the whole, Democratic presidents readily admit their ignorance on how to wage war and their readiness to collaborate with military experts. By contrast, Republican presidents formulate battle plans and expect the military to implement them.

I see these two approaches to project delivery in my line of work. Agile project managers – product owners – seek collaboration with their delivery teams. They advocate for the needs of the customer and are open to formulating a plan together.

Other project managers, ones I’ve come to envision with a John Wayne attitude and a PMP, fashion specifications and expect teams to implement them, which works with varying degrees of success depending on the technical prowess of the project manager. Seldom does the latter approach work; seldom does the former approach fail. I find that when agile projects fail, it’s in implementation more often than in poor design.

As the article attests, there are edge cases in the Democratic approach, just as there are with the agile one. One of the best project managers I’ve worked with had a PMP and loved to collaborate with developers.

If this comparison between agile and politics is apt, does this imply that we will see a paradigm shift in politics as we have in business as agile methods gain traction and traditional delivery techniques flounder in the face of rapid change?

One challenge an agile government would face is working in an environment that is very resistant to change: public opinion. The American people are very intolerant of change. Although the economy is shaky and many people see their fortunes waning, attempts to reform campaign finance, healthcare, and social conventions are met with staunch resistance. And yet it seems clear to me that, in Game of Thrones parlance, winter is coming.

Somehow we the American people need to come together, collaborate, and innovate a creative solution to the problems facing our nation. We need to foster a safe to fail environment where ideas can be tried and honed. Otherwise, we are entrusting our well-being and that of our descendants on the very few decision makers.

I pray that we will begin this work very soon. We can’t afford to ignore the agile revolution in delivery methods much longer, especially in an institution as important as our government.

Tech note: I wrote this at lunch on my iPhone using a Bluetooth keyboard. It’s a brave new world. Feedback is welcome.

I’ve uploaded a presentation I made with Haiku Deck to SlideShare:

[slideshare id=14736147&doc=linq-121015114558-phpapp01]

Haiku Deck said I had us at frozen Han Solo and that it was a virtuosic left brain/right brain combo. Strong praise indeed! I’m humbled.

Let me know what you think of it in the comments.

Look, I get it. You have a boss that hasn’t coded in five years and doesn’t remember that the path from idea to code isn’t a straight line. You have a product owner that expects a miracle a day or the product won’t ship on time. And the fridge has a stale batch of Mountain Dew that tastes like beer from an archaeological site.

Todays, let’s talk about impediments.

Cost Cutting Measures

Process deficiencies aren’t the same as technical debt. Technical debt is accumulated over time and is ultimately the result of not knowing the future. People make design decisions that turn out to be wrong. The product changes focus, some assumptions change and it invalidates the design.

Because time to market is finite, though, some technical debt is inevitable. Good teams try to avoid creating technical debt through supple designs that can bend to meet future requirements. The ideal is a team that can pay technical debt faster than it accumulates.

When I say process deficiencies, I’m talking about the gap between an ideal process where there is zero waste and the actual process that’s in use. There will always be gaps, places that could be improved. People are fallable. And, again, the future is unknown, so there will always exceptions to be handled.

To further the economic analogy of technical debt, process deficiencies represent the cost of doing business. In the recession, talk of cutting costs is inevitable. In agile, this talk takes the form of an impediment backlog.

The Impediment Backlog

Part of the point of an agile retrospective is to challenge the status quo and to continue to strive to improve. Team members suggest ways to cut costs. An impediment backlog is a way to capture that information.

When coming up with the impediment backlog, the team doesn’t sit at my conference table and ask themselves, “why does our work life suck?”. They ask, “what is holding this great team back from cranking out features?” For more on this topic, take a look at Jean McLendon and Jerry Weinberg’s article, Beyond Blaming.

Some teams don’t want to do this introspection. The list is long and daunting. Some of the items are outside the control of the team. However, when I hear a team say, “let’s ignore impediments”, I hear, “let’s stick our heads in the sand and pretend that our practices and our company’s practices don’t impact our efficiency”. It contradicts the “art of the possible” spirit inherent in agile. My advice: Dream big.

When creating an impediment backlog, I intend to be honest, maybe brutally honest, about the state of our practices. It’s our duty as agile team members to identify and address the things that stand in our way.

An impediment backlog is about naming the beast. An impediment backlog is about empowerment. It’s about turning a “can’t” into a “choose not to address right now”, or just maybe, into a “choose to do something about it”.

My impediment backlog has three columns:

This example comes from a company where the SCM team does not manage changes to the development environment, just integration and production. Development teams maintain their own development environments, which takes time and effort that could be spent creating features.

I encourage teams to brainstorm potential solutions, that no idea is too wacky to be included. Some of the solution ideas like hiring a new person may be impractical.

The Value of Identifying Impediments

Management needs to know when there are practices and environmental conditions that slow the team. The team needs to accept that management won’t always choose to address them.

As with cost cutting measures, with every potential process improvement, there is a cost. Going back to the Iron Triangle, maybe the tradeoff is in quality. For example, perhaps the team identifies that the regression test suite takes a long time to execute and isn’t finding as many defects as they had hoped. They pitch the idea of doing a random sampling of the tests. The risk is an increased chance that a defect slips through.

Maybe it costs scope. Maybe defects escape into production that would have been caught by regression testing. The team decides that the regression test suite should cover more functionality. The cost comes in the time spent doing additional testing instead of developing new features. The risk is that the additional testing won’t find new defects.

Maybe the cost is in time. Instead of releasing less work on the same schedule, the team decides to increase the time between releases. The risk there is in marketing. Can the product continue to be competitive if features get to customers more slowly?

Maybe the cost is in quality. Maybe Product and Development together decide that the number of defects going into production is acceptable compared to the demands of the customers and needs of the product, so no change is made. The benefits outweigh the risk.

Conclusion

There are no easy answers to these questions. However, in my experience, oftentimes these questions aren’t even asked. Items in an impediment backlog start conversations, and they make invisible costs visible. Impediments might just get the CTO’s mind thinking about ways to help the company self-organize, and suddenly the “impossible” becomes reality.

How have you used an impediment backlog in your work? Do you have different ways to do it?