Information about information

I liked this post, Information about information, from a few days ago by Seth Godin. One of the challenges that my team is working with right now is figuring out how to take the huge amounts of data that we generate and create actionable information. We're making progress, but there is still a huge amount of data that doesn't get reviewed in a timely manner. Sometimes it's weeks before we realize that the automated tests have actually found a bug. If we don't look in the correct time scale it appears to be noise in the system, but if we look graph out a couple of months of results onto a single page, sometimes a pattern leaps out.

Standards, measurement, autonomy, improvement

I was reading a post today on Gemba Panta Rei: Igor Stravinsky Agrees: Standards Enable Creativity

My favorite line was actually a quote from Taiichi Ohno, the "father" of the Toyota Production System.

"Where there are not standards, there can be no improvement."

It got me thinking about the resistance I've run into over the years in various attempts to standardize and measure the work people do in developing and testing software. I've assumed that a lot of the resistance was based on fear. People are afraid if they are measured they are going to fall short. Which leads to lots of conversations about how hard it is to measure what developers and testers do.

The most successful measurement/improvement efforts that I've been part of have happened in places where there is a high trust environment. Senior management was able to start that they wanted to standardized definitions of work and measure things so that they could make the case for more resources. Because they had built up enough trust, they were believed. Or at least believed enough that no one sabotaged the measurements.

I wonder how much of the resistance was also about autonomy? People value being able to work in a particular way--usually the way that they have been working, which feels comfortable and familiar. The best success I've seen with this was at a start-up, so there were not already established ways of doing things that people were invested in. At other places I've seen HUGE resistance from people who have been working in a particular way for a long time and don't want to move to something different.

But it's really hard to improve if you keep doing the same things the same way. The claim "we just need more resources" doesn't fall on receptive ears at the exec level if you aren't making improvements.

What is the REAL problem?

I was reading a post by Rajesh Setty recently entitled "The problem is never the problem." It brought to mind the hardest recent interpersonal/team challenge I've had to deal with at work. The ostensible issue was around the security implementation in a new tool.

The real issue, as best I could determine, was that some of the people involved don't trust each other very much. We had to address the trust issue before we were able to deal with the technical issues.

Do you know who your real customer is?

I was reading Seth Godin today and found a post that spoke to my experiences running an agile team over the past few years.

His statement was, "If you are working hard to please the wrong people, you'll fail."

My team builds tools for internal use. I've struggled to figure out which customer I should be please. Should I be trying to please the testers who use are tools? Should I be trying to please the test managers? Should I be trying to please the dev managers? Should I be trying to please my boss (hard to go wrong there)?

At various points, I've emphasized one customer over the over. And it has changed over time. It's a source of tension for myself, and to a lesser extent for my team.

Which customer are you trying to please? Is it the same all the time, or does it change with the wind?

Decisions have costs; change is expensive

I've read some fascinating things lately about the energy cost (as measured by brain imaging) of making decisions, resisting temptation, and why that makes it hard for individuals to change their behavior.

I have vivid recollections of being exhausted by all the decisions I had to make setting up a new household. Some of the decisions had significant consequences--which house was I going to rent? Others were utterly trivial--which of the 16 different kinds of kitchen trash cans that they sell at Home Depot was I going to buy? And the funny thing was that make a bunch of inconsequential decisions was far more draining than making a couple of important ones. Apparently now there is science to back up my personal beliefs about that.

I'm not quite sure how to apply all this to Agile/Lean software development. I think the best match might be in the arena of Real Options. They conciously choose to delay decisions. Hopefully in additional to better information, they will have fully re-charged brains when the have to make the final choices.

Saturated Testing

Nice post from Rikard Edgren. If additional testing in an area doesn’t give any important, new information, and is it worth the effort? I have found situations in which additional testing would not change the outcome, but not very often.

Perhaps a more interesting question from agile perspective is "will adding additional tests here increase or decrease the total utility of my automated testing suite?"

If adding a set of tests to your automated unit tests make it too long (long enough that developers won't run them as often?), then maybe it would decrease the total utility of your test suite

Good pain

I was reading Rajesh Setty's blog this morning and noticed a Tweet he had posted that said "The pain of discipline is now, the pain of regret is later." There was a related tweet from someone else that said the pain of regret is always greater than the pain of discipline.

One of the things that I noticed in my first year or so as a Scrum product owner was that simultaneously the best and worst part of the process, at least for me, was the moment in the planning session when I drag items from the backlog into the new sprint.

Inevitably, I always wanted to try and squeeze one or two more items into the sprint than would fit. I had to acknowledge that we couldn't do all the work that I had hoped we would be able to (worst part). And having acknowledged that reality, then I would work with the team and stakeholders to make hard decisions about what we were NOT going to work on. We would end up with an amount of work that we were comfortable we could finish (best part).

In this moment, I was experiencing the pain of discipline.