…which stands for “you ain’t gonna need it” and is an important principle of Agile development, with strong benefits for the business. The basis for YAGNI stems from a failure common in many software development projects: that when a developer creates a component of a system they tend to give it more flexibility than is … Continue reading
…which was a size of problem we noted but wouldn’t tackle. When we estimated the work for R2 up front we used t-shirt sizes for each feature: S, M, L and XL. The largest single task the team would tackle was an L, which was the equivalent of five days’ work. We felt this was … Continue reading
…which was, and is, a hugely important part of our software development, and something that took a long time to learn to do well. Pair programming is when two developers sit at one machine and one keyboard to write the software. It’s very difficult to do: the driver has the pressure of someone watching their … Continue reading
…which lasted two weeks and culminated in a full new release of our software. I’ve written elsewhere about what happened in one week of a particular iteration in June 2008. However, our R2 iterations didn’t just involve implementing software. At the same time each team was also working with a business analyst and end-users to … Continue reading
…which are a fact of life — certainly if your life revolves around developing software. During R2 there was a 40% churn on requirements. That means by the end of the project 40% of the work we had done had not appeared in our initial plan — some things were dumped, new things were introduced, … Continue reading
…which means different things to different people. In our case it meant extracting requirements and turning them into something that could be implemented. Business analysis is often misunderstood when it’s used in an Agile context. Agile people often think it’s not necessary — after all, they say, the analysis is best performed by the developers … Continue reading
The traditional way to track a project budget (which is to say, the way I learnt to do it first) is to track the time people spend on the project each day and add it up. I call this bottom-up budget tracking. Agile forces an alternative approach, which I call top-down. I was involved in … Continue reading
Mishkin Berteig says that rotating developers in and out of a support team should never be considered. I’d argue that he’s wrong, and that it’s often highly desirable and should always be considered. In this article: Background. In which I outline what this is all about. Support rotation is desirable. In which I explain five … Continue reading
We work using agile development processes, which obviously needs the buy-in of internal users and project sponsors. But this jumped out at me when I read it. It’s from Carolyn McCall, Chief Executive of Guardian Media Group, which owns the company I work for. She was announcing a £15m investment in our digital business, and … Continue reading
One of the problems with agile development is that it’s subject to changes, so means you’re in danger of changing it into something which isn’t agile. How do you know when you’ve gone too far? This isn’t a problem for seasoned agile practitioners, but it’s a concern if you’re just starting out, or working with … Continue reading
