One of the things that I see going by the wayside in most places is the bug triage process. The step of taking incoming issues and validating them and prioritizing them. It’s a real shame when that happens; both of those functions are important. Establishing the priority of the defect relative to the existing work is arguably the more important for delivering the most value per unit time. However, validating the issue is the single most useful thing that can be done. It provides two main benefits. First, it makes sure that the issue is ready to be worked, that it’s not going to waste the time of people downstream in the process trying to figure out what the problem is. Secondly, it’s the quality assurance on the quality insurance process.
Archives for category: Agile
The end of the year is a good time for reflection and doing a personal sprint retrospective. One of the things that I’ve seen in the last year is dealing with cruft in the backlog. Stories that are stale, that have been consistently de-prioritized in favor of other stories. On the face of it, this is how most agile methods are designed to work: you work on the most important thing to do right now and the less important things later. That makes sense, but how do you tell if there is something that is less important and getting to the point of irrelevant? Or for that matter what if there were a way to start detecting when changes are occurring that could be fixed in the backlog management process?
I had started thinking about this when looking at the backlog for a project that we took over early in the year. There were items on the backlog that were consistently low priority to the point where the people that were originally involved in the item had all left the company, so there was no one to answer questions about them. This was kind of an extreme example, but it started me thinking about early detection and management of the backlog.
So as a thought experiment, I came up with a metric that might help detect and easily highlight these problems. I haven’t tried it out yet, other than looking back forensically at the projects that I was involved with this year. it will be interesting to try and apply it to the projects coming up to see what happens.
One of my personal project that started off as a thought experiment is slowly turning into reality. One of the ideas was to see what would happen if I turned up all the best practices to 11 and see what happened. The other part of it was that it was an excuse to use some technologies that I wasn’t that familiar with and learn something new. There were a couple of surprises, some of them very pleasant. Among them was how much starting load and performance testing early impacted the architecture of the project.
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 »
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.
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.
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.
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?”
I’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”.
One of the arguments that I see a lot in favor of Test Driven Development is that it helps deliver higher quality software more quickly. The more I projects I take part in or observe, I realize that this is only half true, and less than half true for Agile projects. I’m not saying that TDD has no place in Agile projects, just that it has a very specific place and time.
Scott's Thoughts 