My current project is a fairly large team, nine developers in all, three of them are women. I have to admit that I was a little taken aback by the casual sexism of some of my male peers. It wasn’t brogrammer type comments, but gender getting brought into discussions about shortcomings of different team members when it’s not a gender issue. When the conversation is “she will need more oversight on this task, and she’s a woman”, that’s as sexist as saying “she will need more oversight because she’s a woman”. We already know she’s a woman, the gender specific pronoun gives it away.
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.
One of the things that I try and do to further my personal development is to read at least one new business or technical book every month. About 6 months ago, I read To Sell is Human: The Surprising Truth About moving Others. I didn’t realize it at the time, but this was the most useful book I read in 2013. Basically, the premise of the book is that most people are in the business of sales; or at least persuasion. Your job may not be to get people to sign on the dotted line, but most knowledge worker professions are about convincing people of something. That’s certainly true about project kickoffs and architecture meetings. The whole purpose of that kind of meeting is to come up with a plan, get people invested in the plan and start the project off in a positive direction.
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 see when dealing with agile teams and new challenges is people being either unwilling or incapable of accepting the challenge. Of the two, unwilling is a lot worse than incapable. Dealing with teams that are unwilling to undertake a project, or are incapable to doing the project present special challenges. Part of the problem identifying what’s going in is that on the surface, unwilling presents itself as incapable.
For some reason lately, Taylorism has been coming up in conversation. Perhaps because the quantified and systematic workflows are considered the opposite of agile processes or just because scientific management has so dominated American management theory in the last century. Either way, like “The Origin of Species”, most people have heard of “The Principles of Scientific Management” and few have actually read it. Taylor, like all of us, was a product of his times. One of the things you have to continually put aside when reading it is the classism and elitist attitudes that were pervasive at the time. Once you get past that, you can start to see what Taylor meant about scientific management instead of what everyone “knows” about it.
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.
Scott's Thoughts 