One of the things that I always hear about agile development and scrum in particular is the idea of creating a releasable piece of software at the end of every sprint. This is usually redefined into “a potentially releasable piece of software” at the end of each sprint. It tends to be a little more grey than that, some sprints produce a deliverable that is more potentially releasable than others so there are an infinite number of levels of potential between actually releasable and only hypothetically releasable.  Almost all of the scrum teams that I have worked with over the last 15 years have all been on the “potentially releasable” and of that spectrum.

There’s a huge difference between “potentially releasable” and “releasable”; it’s the difference between having gotten a speeding ticket and actually being a race car driver. As an experiment, the team that I am currently the scrum master for has been releasing at the end of every sprint; this has made some interesting changes in the way that we approach everything. From the last several sprints, actually releasing software at the end has made the entire process more disciplined and focused. The changes started at the tail end of the feature life cycle and continue to work their way forward through the whole process.

Read the rest of this entry »

Advertisements

I recently started a new project.  It took a while to get it going, in fact it took 4 project kickoff meetings before we finally got it moving at all. This was for a set of bug fix releases,  not a whole lot of new functionality. In theory, it should have just do the book keeping, introduce the team, schedule stand up times and start the first sprint the next day. So what happened?

Basically, listening happened. I don’t mean listening in the sense of being able to repeat what someone said, parrot back why they thought a a feature was important. I mean active listening in the sense of everyone really communicating and understanding the problem and how the other people were viewing the problem. The reason it took multiple attempts at a kickoff meeting was that we would talk, there would be some research to be done, a week would go by and the cycle would begin again.

Read the rest of this entry »

Being able to do multiple concurrent tasks for a story is the holy grail of agile development.  It may not be a myth, but the amount and benefit of it has definitely been over sold. One of the consistent things that I hear that didn’t work well in sprints is that people complain that “this task forced me to rework that task, and it cost time”. This seems to happen most commonly by development changing test plans. However, I’ve heard it from people in pretty much each role at one time or another. Occasionally, I’ve been the one saying it too.

It’s too easy to just say the usual platitudes, “mythical man month”, “can’t produce a baby in one month…”. Blah, blah, blah who really cares? That’s been discussed a lot and no real answers have ever come up. The more interesting question is why do we keep buying into the idea that tasks are completely independent and can be done in parallel? For that matter, why do we think the same thing about stories also? If we start to understand why we think the tasks are independent of each other, perhaps that can provide clues about why this occasionally breaks down.

Read the rest of this entry »

I had an interesting experience last week, watching another scrum master try and develop the concept of limiting work in progress and then explaining it to the team.  I found it interesting because of my background with lean development.  In lean, limiting work in progress is a core piece of lean, so it kind of goes without saying.  That started me thinking about the crossover areas between lean and scrum and the way they interrelate across similar problem areas.

That’s when I saw this post http://scrumcrazy.wordpress.com/2013/02/04/kanban-vs-scrum-kanban-is-not-for-software-development-but-scrum-is/

I can’t say it’s comparing apples to oranges, more like comparing apples to the orange peel. Comparing scrum to kanban is kind of like comparing lean to a sprint planning meeting. A kanban board is one facet of using lean to manage a project, the same way that using a sprint planning session is just one facet of using scrum.

Read the rest of this entry »

I had an incident last week where another developer accused me of applying a double standard to contributions on a project. The root cause of the misunderstanding was that he was looking at the unit test that he copied from the other developer, while I was doing a code review of the code he submitted. That got me thinking about code reviews versus unit tests.

Ultimately, it comes down to the quality of the code review and the quality of the unit tests. A lousy code review is waste of time for all parties and is less effective than good unit tests. The reverse is also true, a good code review beats poor unit tests.

Read the rest of this entry »

I got asked recently about the role of architecture in agile development. Basically, the question boils down to some variation of “Is there a place for architecture in agile development?” This is a common and mostly misunderstood question. It seems like it gets asked on every project. It’s based on a faulty assumption: that architecture is something that is stand alone, that can be bolted on to a project.

To talk about agile architecture, you first need to understand what architecture is. Once you know what architecture is, and what it isn’t, the question changes to “How can you do good architecture in agile development?”

Read the rest of this entry »

I'M LATEI’m late! I’m late!  My whole project is late!

Can an agile project be late? What does it mean for an agile project to be late? There are really two different kinds of lateness for agile projects.  First, there’s the kind that everyone thinks of “this project will take 8 sprints instead of 6 so release it”.  Then there’s the more insidious kind, “these stories got started but not completed in the sprint”.

Read the rest of this entry »