agile - Matt Kimber

Matt Kimber

agile

A collection of 21 posts

Servant Leader, Helicopter Parent

Servant Leader, Helicopter Parent

Why is developing software so slow now? Provocative statement, so let's unpick. Maybe I'm getting more impatient as I get older, but the pace of modern software development feels glacial. Honestly, why do simple app features or new API endpoints swallow half a team for three or four weeks at

Methodology? What Methodology?

Methodology? What Methodology?

I think I'm getting kind of post-methodology in my thinking. I don't really care what it is or what it's called, but I do care that it facilitates three critical things

Agility and the power of No

Agility and the power of No

One of the nice things for me about writing is I get to go back to my old articles every once in a while and see where my viewpoint has matured, where it's changed...

The 10x Developer and You

The 10x Developer and You

I'm in the mood for sarcastic graphs. I think (I hope) that the idea of the "10x" developer is not an astonishingly new and radical one. People in the upper quartile of the profession are not proportionately better than those in the bottom quartile, they're orders of magnitude better. But

Two Transformation Questions

Two Transformation Questions

What exactly is a transformation? Is it "go to the cloud" or "be Agile" or "containerise the things"? Despite the number of organisations which state those as their goals, I'd say it isn't. Those examples are merely means to an end. They're often a part of transformation, but they're not

The Definition of Done Dashboard

The Definition of Done Dashboard

I've been working on an infrastructure-heavy project of late, and one of the problems our team faced was differing viewpoints on what "done" actually means. In short, we ended up with a lot of variations of the following conversation: "It's done, I finished it." "But... I still see an error

Technical User Stories - Who, What and Why

One of the problems we regularly face with our more technical stories (for example, setting up a monitoring stack) is explaining to the people in charge of the budget why they should pay for this. It's a valid question. I think it arises because when we're writing technical stories, we

Too much in flight

In a Scrum context, multitasking is bad. Teams who follow Kanban will be familiar with this concept, as that process invites you to explicitly set your lane limits up front - only 3 things in progress, only 2 things awaiting product owner review, only 7 tickets waiting for release, and

The Backlog

I had one of those "changing the way we work" discussions today, about the product backlog. I'll spare you the details, but it came down to answering two questions: 1. How many of the stories we know about should we have on the product backlog? 2. How many of the

Planning isn't free

Planning isn't free

I've got a confession to make: I secretly enjoy rewriting code when requirements change. I get to think again about what I was doing and my assumptions, tidy up the lingering technical debt, make a few performance optimisations and abstract things a little bit so I don't have to worry

Firefighting

Firefighting is one of the biggest and most common causes of lost productivity and morale in software development. It usually manifests as developers being pulled off their project to urgently fix something - the live site is spewing 500 errors, there's a button in the wrong place, or a senior

Working with both physical and electronic progress boards

Yesterday in a retrospective one of my teams asked a question which is all too familiar: "Updating both a physical board and an electronic board to track our progress is a bit annoying - can we get rid of one of them?" So we had a bit of a discussion,

Kaizen and Scrum

Kaizen, the process of "improvement" in the Toyota Production System, is a valuable complement to Scrum, based on many of the same principles. It means teams can get effective results both from their retrospectives and daily attempts to resolve waste. At the core is a variant of the PDCA loop

Waste redux

A conversation today reminded me of my musings about waste [http://www.mattkimber.co.uk/waste/] from a couple of months ago. The context being that Scrum is misunderstood more often than it's understood, the relatively broad statements of the Agile Manifesto are easily abused to claim whatever you're currently

Agile transformation: The Low

Agile transformation: The Low

A few months into any company's journey towards agile development I often see a point which I call the Low. This is where you've brought in a few experts, and done a few of the things they've said... but nothing seems to have improved and now people are wandering round

Bimodal IT isn't anything to aspire to

Bimodal IT isn't anything to aspire to

Bimodal IT is a term created by analysis form Gartner, to describe an increasingly common pattern in enterprise development. It's where you have one part of the organisation working in a very traditional, governance-focused manner using lots of process charts, documents and explicit signoff, and one part working in a

Lean Startup is Agile by another name - and that's okay.

Lean Startup is Agile by another name - and that's okay.

There's a lot of buzz building around the Lean Startup model lately; it's been around for a few years but we're starting to see mention of it in places like the WSJ and the boardrooms of major enterprises. To some degree the sentiment is that Lean Startup will deliver us

Be careful with "Modern Agile".

organisations Featured

Be careful with "Modern Agile".

I have a problem with a lot of the recent advice suggesting firms looking to adopt agile practices should eschew the stand-ups, estimations and fixed iterations of Scrum. Which is strange as a lot of that advice is coming from respected, experienced Scrum practitioners. However, I think what's happening is

Breaking down user stories

Breaking down user stories

A user story is a short, simple description of a piece of functionality, as told from the perspective of a customer. It's intended to form the basis for a discussion about how to provide business value, and it should be relevant to the customer. "I want to be able to

Avoiding nightmare releases

Something I've seen a lot of supposedly Agile teams fail with is releases at the end of a project. Everything up to that point ticks along nicely, but the final sprint is a monstrous combination of time extensions, shifting scope, last-minute changes and unexpected problems. I've seen all sorts of

That's Not Agile

For every 10 companies claiming to have an agile development environment, maybe 1 actually does. This is because "Agile" sounds a lot better than "horrible collection of organisational code smells we've accumulated by having no real process". Here are some things that are emphatically not agile development: * Jumping straight into