Agile Life: Transparency

Ever wondered what benefits Agile and Lean methods such as Kanban actually provide? Ever wondered what transparency ever did good to the world? I’ll try and provide an example right here, straight from my own ordinary life!

My cohabitant uses a medication. She’s supposed to take it every morning, and that will make her feel better. If she doesn’t take it, bad things can happen during the day. Not necessarily, but they might. If she takes more than one, it’s apparently not A-ok either.

A while ago, I found this thing (photo below), lying on the bathroom sink. Now, if you’ve looked at the picture (and know Swedish) I hardly need to explain where I’m going with this or what the benefits of transparency are in this particular case. But hey, let’s say for the sake of it, that the picture isn’t showing up in your browser.

Transparency Tool!?

The thing she brought home is a plastic box, with seven compartments, one for each day of the week. She fills these, one pill in each, so that each time she takes a look at it she knows whether she’s taken the pill that day or not.

You know where I’m going with this now, don’t you? Since this box is in OUR bathroom, I happen to see it too, every time I visit the place. What do you think happens when I see a pill in the Wednesday compartment and it’s Wednesday afternoon?

Another effect of the box in this simple analogy, is that I, an external part of the process, become much more aware of the details of it. Immediately after she started using the box I recognized how often she takes the medication, how many pills she takes each time, the size of them, etcetera. Questions I previously couldn’t have given answers to when asked about. In effect, she’s shared the process with me, in a vary unobtrusive way…

Right, so I reckon transparancy works like this also if you scale it up, and use it in software development. Wouldn’t you agree?

Don’t Underestimate…

You know it happens all the time. You know you’ve done it yourself. Indeed, I’ve done it too: Underestimated a story or task that is. This may seem like an innocuous thing at the time it happens, but of course it can have pretty dire consequences.

In my experience, people tend to underestimate tasks for a whole range of reasons. It easily happens in groups or teams where the members aren’t fully secure where they stand on a professional level compared to the other members. Many people hesitate to tell a room full of new acquaintances that their estimate is way off target, and fail to realize that precisely that may be the ‘senior’ thing to do. Obviously, newly created teams are prone to this issue.

There’s also the issue of pressure on developers to ignore risks in certain situations. When your estimates decide whether your company will get that ‘fat’ contract – a job you, as a developer, are desperate to land due to the nature, size, importance or technical aspects of the project – it may feel like the most natural thing in the world to underestimate. Pressure can also come from management or from expectations on a person elevated to ‘architect’ status to perform miracles in no-time.

Yet another another underestimation trap to fall into is our tendency of pure wishful thinking. Nothing bad could possibly happen to my progress when using this pre-alpha document database, I promise!

I’m not talking about zen agile projects that have the same team running for years, in a business area where the money is flowing and everything is hunky-dory. The software world is not that perfect, and the above mentioned constellations of new teams, short-term projects and up-front estimates are not uncommon.

Anyway, there’s a scientific term for this, namely ‘Planning Fallacy‘, which automatically makes it more comfortable; we know others are experiencing the same thing. Unfortunately that doesn’t mean we want this ever to happen.

Thinking back, I remember a smaller contract project that a client requested offers for. I estimated the total effort to something like 50% more than the winning bidder. The project was supposed to run for about two to three months for a couple of developers. A year later the client had finally received an acceptable delivery. However, the code base of the product was not in a fully coherent state and thus my company got the chance to continue development. In the end, it would probably have been more profitable for the client to scrap the code base and restart from scratch.

If I would list a few recommendations to alleviate the problems, it would look something like this:

  • Management and project leaders or other stakeholders should try and conceal any preliminary budgets or estimates to the team. Otherwise developers could easily be influenced.
  • Architects and senior developers must take responsibility of having the mature view of the estimation of tasks. They should have the best apprehension of risk, and should try not to jump to conclusions.
  • The team should learn and use available estimation techniques, such as Planning Poker.
  • Everyone involved should be aware of that in the long term, it’s more profitable both for the client and the contractor, to cancel work that have very little chance of being completed within the given budgets.
  • It’s very hard to overestimate things by a large margin – stay on the safe side. Even if you manage to meet your daredevil estimates, will you be comfortable with the delivered code quality?

It’s not easy being a client; it’s hard to know which contractors can be trusted and which cannot. If you’re a manager looking at budgets there is an immediate pressure to find bargains. Developers also have a hard time, contractor or not, with the issues described above. But the next time you estimate something, anything, do our business a favour and don’t underestimate the cost of developing working software.

Running Selenium IDE Against Different Environments

When running test suites inside Selenium IDE, you can set the ‘Base URL‘, which is basically the domain part of the site under test. If you want to be able to run the same test suite against various environments, such as ‘test’ or ‘stage’, you obviously want to run with different base URLs. However, it’s not that obvious how you accomplish this, and it’s not well documented either.

What may happen if you try to just change the base URL is that the first test case in your suite runs against the new setting while the rest run against previous settings. The cause of this lies in the fact that each test case can have a hidden base URL, as shown below!

What you want to do is to simply remove the complete line with the link element. Then Selenium will use whatever you write in the ‘Base URL‘ field when running the test suite. Handy eh?