Estimates in software development are hard. There are good reasons not to estimate at all. Work in thin slices, keep cycle time low, and deliver at steady pace. And yet, it’s still fair of others to ask: when will this big chunk of work be done? And not “maybe done”, but “definitely-I-can-promise-this-to-people done”.

Ideally you can calculate an expected delivery date based on your current pace and the number of slices in the new big chunk of work. But maybe you don’t have the slices yet. Or it’s a new kind of work and your current pace won’t really apply. Or there are upcoming changes in your team or organization that make any calculation tenuous.

So you have to provide an estimate. And you do. You say “six months”. And the other person - from sales or marketing or some engineering director - says: “We need it in three.” What just happened is that you estimated in something that’s not negotiable. In time, in this case. And the end result is that everyone is unhappy. You have other options, though. You can negotiate in something else than time.

Read more…

Throughout the years I’ve used quite a few different languages - if you allow me to be somewhat generous with the word “use”. One language I actually feel proficient in. Some languages I’ve only done coding exercises in. And one language I’ve only used for a total of maybe 10 minutes, but that did really help out a whole team.

I do believe we should be that generous, both towards ourselves and to others. For an industry that likes to talk about imposter syndrome, we seem to enjoy saying “You’re not a real … unless…” a bit too much.

Listing these languages for myself made me wonder what I had learned from them. Did I just learn how to write some code in each of them? Or did I also pick up some more general lessons? Turns out I did.

Read more…

In 2001, nine years before the first version of the Scrum Guide, Ken Schwaber and Mike Beedle published “Agile Software Development with Scrum”. This version of Scrum has some remarkable differences from even the first version of the Scrum Guide.

The three things that struck me most about this version of Scrum, were

• Scrum Master is a management role, preferably by an engineer
• there is no retrospective, impediments are addressed in the Daily Scrum
• Sprints are 30 days and have a goal, tasks can be added and removed throughout

While I don’t want to claim we should return to this old-school version of Scrum, I do appreciate how radical it is compared to how software development is done - even today.

Read more…

Over the past year, I’ve been thinking about how testing-related roles are still an unsolved problem in software development. We keep trying different permutations: shifting left and shifting right, being closer to the programmers while not too far from other testers, doing less testing ourselves so we can support others more, etc.

And still, to be effective in any of these permutations, you can’t let yourself be limited by them. You need to work both inside and outside the existing structures. You have to “be all over the place”, in a good way.

Testers do testing

Let’s start with a straightforward statement: a tester tests. Then what is testing? I still like the definition “Testing is investigating in order to evaluate a product.” The most obvious thing to investigate, to test, is the code that is being written. The best way to do this, in my opinion, is through the combination of exploratory testing and test automation, i.e. what Maaret Pyhäjärvi has named “contemporary exploratory testing“. And to be clear, while the execution part tends to be the most visible, effective testing also needs good test strategy, design, and reporting.

Read more…