Tag: productivity

Changing the code base landfill into a lean and learning recycling center

Waste seems to be a simple enough concept: anything that does not add value should be eliminated. But what about the features that are supposed to add value and actually don’t? What about the features that are started working on as an idea or a quick win that we do to just get it out there quickly – MVP style but not really – that end up being thrown away or redone soon after? Afterward, no one denies those are waste; but how do we turn waste into something that can be recycled?


November 4, 2015 0

MVP: Minimum Validation Phrase – How I know I’m making a difference

I received a text message last night from one of my developers around 8:15 pm. “Do you want to talk shop?” it said. My first thought was, oh dear, what is broken now? (it’s release week as it is every other week and it’s been a rough month or two). When he called me and what he said next completely blew my mind.


September 17, 2015 6

Have you been Bean Boozled? The argument for co-location and shared spaces

I was recently talking to a former co-worker on one of my previous Scrum teams about team rooms. A fundamental of team formation and performance is teams being together and bonding through work and fun. While many companies proclaim they’re practicing Agile/Scrum, co-location and team rooms seem to have become more optional than mandatory. While we cannot completely get away from distributed teams, it seems that often even with teams that have members in the same place those teams are not sharing a space. From this practice I’ve seen teams having a harder time forming, norming, and performing (though they don’t seem to have storming problems). What benefits are teams missing when they don’t have a shared space? And even when they do have one, are they then lacking the ability to work with distributed teams?


June 22, 2015 0

Gaming the metrics is GOOD!

I’m going to start off by saying that I know Scrum and metrics don’t necessarily get along. But I will also acknowledge that it’s a necessary evil in most cases. And in a lot of cases it doesn’t have to be evil. Metrics are simply: a method of measuring something. In Scrum, we measure a lot of things. We measure the size of our work items, we measure the effort or time it takes to complete them. We measure our accuracy. All of this is in our quest to become predictable as a team and to improve (and we need to start with a baseline measurement to know if we’ve improved). But when others start taking notice of our metrics, that’s when things get tricky.


June 24, 2014 1
Junk drawer

The “Catchall” story

So an interesting topic came up in a retrospective last week, one that has come up on past teams as well and I’m still unsure as to the best answer for it. Example: team members get hit up for a production question or something else that isn’t a story in the backlog and spend a decent chunk of time working on it. This interferes with their other work and maybe they don’t get as much done as they committed to because of said question. Now they want to account for those types of things with a special “prod question” or other story in the backlog so they can account for that time and track back to it. What’s wrong with this picture?


March 11, 2014 5