Mar

1

Just Enough vs. Just In Case

Posted by Keith McMillan

March 1, 2010 | 8 Comments

It’s amazing to me the lengths people will go to in order to have something “useful” to do at work.  The problem is, in their quest to have something to do, they tend to make more work for, and slow down, the rest of us.

A number of years ago, I was working with a very young client company that, for reasons I won’t go into right now, had very little for me to do when I and my team first arrived. In fact there was little for their folks to do as well.  On the day that I arrived with my team, the clients were discussing what their cube layouts should look like.  They’d plotted on 24 x 36″ paper various layouts, and posted them on the wall at the office. They were voting on which one they preferred, and discussing alternatives.

As I left for lunch with my team, one of them turned to me. “Why are they spending so much time talking about cube layouts?” she asked me.  “Because they have nothing better to do. Once we get them busy, they’ll forget about it” I responded.

I was right, in another week and a half, the diagrams were still on the wall, but nobody was talking about them.  In fact, no one even bothered to take them down for the months we worked with the client, they were just ignored.  Once we had real work to do, the “make work” was ignored.

I see a similar sort of thing happen with bigger businesses too. When working for a large insurance company, I had some dealings with the team that collected metrics for reporting on the effectiveness of the software devel0pment teams.  They’d ask for different figures, like “how many defects were found in the sprint vs. how many escaped” and root causes of various defects.  These were all noble in intent, but the list tended to get rather long after a while. When I asked “what are you trying to get at?” and “how are you going to use the measurement you just collected?” the answer was frequently “well, just in case someone wants to know.”

And there’s the heart of the problem.  If we’re trying to make our teams as efficient as possible, we need to do just enough to get the job done: just enough design, just enough documentation, just enough of pretty much everything.  Focusing on delivering the value in the software. But almost everyone wants to feel like they’re contributing to the overall success of the business, regardless of what we’re doing. We’re being paid, after all.

I say almost everyone because I have met the occasional person who shows up, does the minimum amount they possibly can, collects their check and leaves.   I think I’m incapable of being a person like that, and I don’t understand them very well.  When I’m bored at work, it’s very difficult for me personally, and I think I’d be very bored if I acted like these folks.  But back to the topic at hand.

If we get a bunch of people together who are motivated to contribute to the success of the project, or the business, and we don’t give them clear direction on what they can do to help us succeed, we’re going to get people doing what they think is best.  If we form a group who’s job it is to collect metrics, well, then they should collect metrics, right? The more metrics, the better job they’re doing!  We seldom realize that collecting these metrics “just in case” distracts the team from doing what they should be doing: building software.

In addition to collecting metrics, traceability of software requirements is another very popular time sink.  Traceability is the idea that I should be able to trace from a feature, to a detailed requirement, to a design, to individual lines of code and tests, and back again, by looking at information contained in a tool. Said another way, if I look at a line of code, I should be able to tell you what requirements it satisfies, and which tests verify those requirements, with a bit of research.

Traceability sounds like a great thing to have around, just in case you need that information.  It would be, if it cost you no time or effort to do, but the thing that people selling traceability don’t tell you is that while it can be done, it’s incredibly expensive and time consuming to produce, and to maintain. So much so, that I’ve taken to asking, “why do you want the information? Is there a business driver for it, or do you want it ‘just in case.'”

The antidote to “just in case” is “just enough.”  To be as efficient as possible, we need to do just enough.  If you’re asked to maintain traceability, ask why.  “Why do we need to maintain detailed traceability? What’s the business purpose?”  If the answer is “just in case,” then you can explain how much it costs, and how much time it will consume. That time could be used to beat your competition to the punch on that next feature, or to maintain the information you need “just in case.”

If you’re not serious about doing “just enough” then you’re never going to realize just how fast your development teams can work, because you’ll have them collecting information that you need “just in case.”


Comments

RSS feed | Trackback URI

8 Comments »

Comment by Casey
2010-03-01 09:46:01

Keith, a thousand times YES! I currently work for the large IT department you were recently consulting for, and this article really gets down to one of the major root causes of project delays here. I’m tempted to print up t-shirts and posters with the phrase “The antidote to ‘just in case’ is ‘just enough'” on them. Thanks for your insight.

Reply to this comment
 
Comment by Petri Heiramo
2010-03-01 14:31:23

Nice post, and to the point. Thanks for writing it.

Yours, Petri

Reply to this comment
 
Comment by Rama
2010-03-02 05:45:14

Hi Keith
It is no doubt a very interesting and informative discussion. We face these kinds of issues often.
It will be really good if we extend this further and try to explore on how we could help the team define ” Just what is enough”. I believe that many a times although the team members are aware of the “Just enough”, but what prevents them from implementing the thought is the litmus test for determining what is ” Just Enough”.
Thoughts welcome
Regards
Rama

Reply to this comment
Comment by Keith McMillan
2010-03-02 09:15:29

Hello Rama,

“Just enough” is going to be different for every team, and for each activity you undertake, so it’s not possible to give concrete guidance on how much is just enough.

That’s the reason I suggest that we ask “why?” If we ask “who needs this, and for what? Is this the best form for what they need?” we stand a better chance of finding all that make-work we do “just in case.”

We’re always going to be asked to do more than is “just enough” but at least if we’re asking the questions, we can try to keep our focus on providing just enough.

Thanks for your comments!
Keith

Reply to this comment
 
 
Comment by Ryan
2010-03-04 15:34:49

I agree with your post, Keith, but I think there is another complication here. Sometimes the “just in case” is hidden behind a well constructed facade backed by well thought out (but usually quite convoluted) theories and ideas. It requires digging and wading through the facade in order to realize that what is actually behind there is simply a “just in case” or sometimes a nice CYA. Unfortunately, tearing down the facade usually takes a lot of time and effort.

Reply to this comment
 
Comment by Lev Ayzner
2010-03-06 15:54:54

While I agree with “just enough” mentality in general, I may not agree with traceability is “incredibly expensive and time consuming to produce, and to maintain”.

Knowing what is the right thing to do is necessary but not sufficient. Necessary and sufficient is doing the right thing the right way… Then, it may provide “good enough” value. Hard to believe that no one has got any positive experience with traceability.

Thanks,
LevA

Reply to this comment
Comment by Keith McMillan
2010-03-06 16:30:26

Hello Lev,

I’m afraid we’re going to have to disagree on this. I used to be a proponent of modeling every use case/user story, and then keeping the model up to date, so we knew the design of every use case, which classes it involved, and what methods. Over time, we had to let go of updating all those models after someone changed something, due to the pressure of delivering more to the customer, and a funny thing happened: it just didn’t matter that the models weren’t up to date: nobody used them.

Sure, it’s a good idea to make sure that the features you want are represented as user stories, or use cases, to make sure you don’t forget something important, but that can be done in a very lightweight way (keeping track of themes or epics, and then making sure there are stories for them, for instance), and that’s not what I mean by complete traceability. Traceability to me is being able to refer to a detailed model for the story (typically class and sequence diagrams), and knowing that the model is correct. That means that someone kept it up to date, or rather that everyone who worked on the system did.

The value of producing a model for a story or a use case is in thinking about how you’re going to deal with the requirements, and that can be done at a whiteboard. If it’s put into a formal modeling tool, in my experience it’s seldom referred to afterward, sometimes because it’s no longer correct (because nobody updated it), sometimes because it doesn’t cover the right level of detail in order to be useful, and sometimes because it’s just easier to read the code.

In my experience, which is considerable after over a decade working for large companies as a consultant, here’s only one that got any real value from complete traceability, and they were filing FDA paperwork for medical devices, so it was a requirement for them.

I appreciate your comments, even if we disagree,

Keith

Reply to this comment
 
 
Comment by Mediocre-Ninja.blogSpot.com
2010-08-10 21:38:47

There should have been “YAGNI” around the coding standard/convention to remind ppl of the “just enough” 🙂

Reply to this comment
 
Name (required)
E-mail (required - never shown publicly)
URI
Your Comment (smaller size | larger size)
You may use <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> in your comment.

Blogroll