In the middle of cold winter days, what could be better than making a roaring fire? But you’ve probably been building an inefficient fire. It’s probably hard to start. You have to keep adding logs and moving them around to get good burn. The edges of the logs don’t burn. It takes a long time to get going and you have to keep stoking it. This cuts into your marshmallow roasting time.

Lessons on the Upside Down Fire

Tim Ferriss shares in his blog how to make an upside down fire. You begin by putting the biggest logs packed tightly in a row. Pick wood of similar thickness to make the top as flat as possible. Then take smaller logs and make another tightly packed row set perpendicularly to the one below. Then take split logs and make another row offset by 90 degrees. Then do a row of smaller branches. Then lay down a layer of bark and sticks as tightly as possible to make a flat, solid surface. Lastly, I build a tent in the middle out of twigs and put dryer lint inside the tent. Paper works too, but dryer lint burns fast and hot.

Light the lint and it will ignite the tent of twigs. This in turn lights the “table” of bark and sticks below it. As each row burns, the hot sparks light the row below it. The key is to have no gaps between your logs in each row because the sparks will drop too far and light too many rows at once.

The upside down fire burns unattended for 3 hours. It burns hot and evenly. You don’t end up with much ash. So, a simple tweak – looking at something common with new eyes, creates a significant improvement. S’mores heaven!

Rethink

This got me thinking. How often do we do things by habit without thinking? What are some simple tweaks that could make common things more efficient? If things I do frequently are more efficient, does that make me more efficient overall? What insights can you find if you turn your thinking “upside down”?

I thought a natural place to start tweaking is with the agile/scrum process my team uses for small to medium size application development. The process is very flexible. If something doesn’t work, you adjust it with the next sprint. The most time you can lose is three weeks, so less risky to tweak sprint to sprint.

Generally with software, you start with business analysis to find the problem and define it. Then you determine the way to solve the problem, write the requirements, build the solution, then test it. So what happens if you turn this process upside down?

The Upside Down Story-Test … errr, I mean … Test-Story

Instead of waiting until the end to write the test case, what if you began with the test case? Then you would have a very clear idea of your target. You actually create tighter solution.

How? Developers have a tendency to over-engineer solutions. It’s normal, natural and a noble trait. However, if your developers do that with each story they build, you end up with what project managers call “gold plating”. These are extra features or “nice to haves”. When working a tight time box, you don’t really want to waste time on extras. You need laser like focus on the stories planned for the sprint. Any extra time should be spent on building out more stories from the backlog.

So, write your stories backwards. Start by writing a test case that minimally (but completely) satisfies the requirement. Tell the developer to move onto the next story when their code passes the test case. If an enhancement idea becomes a “must have”, then add it as a story to the backlog and get to it in turn.

It Really Works!

For example, one project had a story to report to display data by region. After building the report, the developer started to add (as expected) good ideas. He started to add additional views by state and wanted to add sorting by state and region. These were great ideas, but went beyond the scope of the story. I needed him to spend that time on higher priorities stories still in the backlog.

I pointed out the test case and asked him to confirm if his code passed the test. It did, so he moved on to the next story. I spoke with the business line manager about adding the new stories. The developer was able to finish the planned stories early. With the extra time, he was able to build the additional view and sorting function. It was a win-win. The business line got a better product. The developer knew I listened to his good ideas and used the system to help him get more done than he would without it.

Conclusion

So, think backwards! Write the test case first, then write the stories. Each story should have at least one test case. Be a trustworthy listener to make your development team confident in the system. They have to believe that moving on doesn’t mean their good ideas are forgotten. You as the scrum master have to work hard to record and add their good ideas as potential stories. This helps keep the developers focused on building the highest priority items first. You will build team trust and you increase the chance for success. Win-Win!

NOTE: All views and opinions are those of the author only and not official statements or endorsements of any public or private sector employer, organization or related entity.

Chaeny Emanavin is part of the GovLoop Featured Blogger program, where we feature blog posts by government voices from all across the country (and world!). To see more Featured Blogger posts, click here.