I’ve covered a number of basic agile concepts over the last few weeks, and I think it’s time to start to talk about some of the more complicated ones. This week, it’s time to talk about failure, and why you should fail fast. Read more



This week, we’re going to take a look at retrospectives. The principles behind the manifesto include “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts it’s behavior accordingly”. The most common way this is done is the retrospective. Read more



Continuing the theme from last week, where we discussed some of the principles behind the manifesto, this week’s concept is technical excellence. The principles say “Continuous attention to technical excellence and good design enhances agility”. Why should that be so? Can’t we just add quality in later? Read more



The Principles Behind the Agile Manifesto includes among it’s many good ideas the following: Simplicity – the art of maximizing the amount of work not done – is essential. What’s that about, then? Read more



Agile practitioners like to use lightweight project management approaches. We still need a way to keep track of what needs to happen, even if we don’t use a Microsoft Project plan.  One approach, favored by Scrum practitioners, is the backlog. So what’s a backlog? Is there more than one type? And what goes in them? Read more



When folks set out to estimate the amount of work they have to do for a particular user story (what’s a user story? that’s another post…), they have to decide how they’re going to estimate the level of effort. There are two popular ways to estimate user stories: ideal hours (if you did nothing else but this task) and story points. What’s the difference, and which should you choose? Read more



I thought it would be interesting to start a series on agile concepts, giving a simple definition (or at least as good as can manage) and some examples. I decided to start with the Cone of Certainty. Read more



One of the fundamental tools in a Scrum project is the retrospective, the regular meeting at which the team looks at what they’ve been doing, and thinks about ways to improve. To my way of thinking, it’s sort of like the project post mortems we used to have, only better. But not all retrospectives are created equal. Read more



I sometimes wonder about whether large companies can be agile. When I think about how a company grows organically, one of the first things that seems reasonable is that as you add more testers, for example, you hire a testing manager, and they have their own group.  The same applies to database administrators, business analysts and the like, and you arrive at something that looks very like the average modern company today.  When you set out to create a project team, it’s obvious with this structure you’re going to need specialists from a number of different domains to fulfill all the requirements of your project. Read more



Firstly, apologies for the long delay in posting anything, my current client has a project in trouble, and I’m doing what I can to help them keep it moving.  I wanted to share some thoughts on what it takes for a business to be successful with agile adoption, in particular, what you have to be willing to do as a company in order to achieve the kinds of success that people brag about when they talk about agile development.  This is likely the first of several posts on the topic, and we’re going to talk about estimating and measuring progress on an agile project. Read more

keep looking »


WP Themes