I was recently thinking about a situation that puzzled me, and came to a realization that makes me a bit nervous ....
I have had exposure to some teams where even though they are in firefighting mode more often that is comfortable, and/or even though their customers are unhappy, and/or even though their software has a *lot* of bugs, they still don't seem to "get it" and try to do things in a better way.
I have sat, baffled, looking at people who lead these teams, my jaw on the floor, wondering why the people leading these teams are passing the buck on the team's responsibility for problems, and instead presenting a magic show to prove why the problem is not theirs.
And today, something hit me: I was thinking about what would cause someone to change; what would make it so that they finally felt the need to do something different, and the term "the wall of pain" came to mind. This term comes from a blog post I read a few months ago, "Fighting Technical Debt with the Wall of Pain". What would instigate change? Enough pain that it feels necessary, in order to escape the pain.
This reminds me of Parenting 101: How do I stop my 12-year-old from making irresponsible decisions? I make them painful enough that he will be sure to avoid the pain. Luckily, these days that is as easy as "Oops! Your PSP ran away! I can't find it!", or "Where are your Playstation controllers? Gee, I don't know ... I guess maybe they will return when you start doing the chores that you are responsible for."
BUT ... BUT ... what about companies where the new development team is a separate entity from a maintenance team? What if the developers who are writing new code are sheltered and protected from the results of poorly written code? In some cases, it goes something like this:
- Development team writes software ... Maybe they fix a few bugs along the way. Sometimes, if bugs come up and it can be proven that they existed in previously written code, they may shrug them off as not the result of current work, so not their problem right now.
- Development team's schedule gets squished, and as it gets closer to release time, only the *most* important bugs that are proven to be the result of their current work, are even looked at by the team.
- Release happens. At this point, product is a released product, and the workflow now looks like this:
- Customer has an issue, customer calls Support. Support tries to reproduce it, and if they can, they file a bug. Bug gets reported to Maintenance team, and they work on it.
In the above scenario (which exists in some companies), the team that originally wrote the aforementioned poorly written code never sees the wall of pain. Seriously, for the most part, there is absolutely zero repercussion to them directly for bad code.
In a case like this, the responsibility for well-written code falls upon those who are internally motivated to do their best, and strong enough personalities that they fight the push to get *something* out *faster*, well-written or not. I believe that this type of personality does not describe the majority, and the whole team falls into a pattern of continuing to write poorly written code. What is there to stop them?
Has anyone had any experience helping a team to transition into a more agile-like process from a situation that looked like this one? How do companies like this adjust to fight this pattern?
I wonder if it would help to break up the idea of "new dev" versus "maintenance" teams, and instead cross-pollinate into functional teams. In this case, there would be a team for one specific module, component, or module, and they would handle both new work and bug fixing/maintenance. Would this strategy work?
4 comments:
I think they really need to be in cross functional teams. Splitting new dev and maintenance activities only hurts the company as a whole. Being a support engineer is a morale crushing hole and not having to face the pain reinforces the wrong behavior. They are saying good boy to the puppy who craps on the rug and punishing the one that wants to go into the back yard.
Hi Dawn,
Interesting question! I can only speak from my personal experiences of course...I have been on teams that were responsible for both new development and maintenance within the same product line ("product family" as we called it), and I think this approach was beneficial for a couple of reasons.
1) The team could learn from the bugs they had to fix - a lot of the pain points in the apps being supported were architectural in nature and since the developers knew intimately what smelled, they knew where to focus refactoring efforts.
As a tester on the team, I also learned about new (well, new to me) scenarios/use cases to consider when testing new features or changes to existing functionality.
2) Speaking exactly to what you discuss in this post - at least partly because the team "felt the pain" of dealing with bugs and maintenance issues, we were aggressive (can't think of a better word) in our attitude and approach to testing. TDD, pair programming, shared testing responsibility (across all team members, not just "the testers"), building a regression suite, and collaborative acceptance criteria definition became part of how the team operated on a daily basis.
Now, there did come a time when the maintenance and new development responsibilities were split across two teams. This was part of the reaction to an urgent business need. I ended up being on the "new development" team so I can't speak to what being on the maintenance team was like; I can tell you that more than half of the people on the maintenance team ended up leaving within 3 or 4 months of being put on the maintenance team, though.
I'm going to forward the link to this post to some former colleagues who may want to share their experiences as well.
Marisa
I think you've got this exactly right, and it's one of the reasons that agile teams that release frequently often don't run into this sort of problem. They're ALWAYS living inside that codebase, and there's not really a separate maintenance stream except for critical bugs.
Recent events have taught me well about perverse incentives. I think you've identified one.
I would agree that having a separate maintenance team hurts efforts toward accountability.
Some of the reasons for two teams include:
1) PE / maintenance programming is "easier" and/or a training ground to "learn the code" .. I disagree to a certain extent .. but it is different. And some of the PE guys get very good at fixing bugs quickly.
2) The management wants to improve accountability for the Development Team .. no excuses for not meeting the development deadline.
I have watched two teams get more accountability when their maintenance team was not forth coming. This allowed the developers to directly feel the pain and also see where things were going wrong.
Agile should help.
It is tough to meet schedule if bugs are falling like rain.
So in a case as described above if someone can be "enlightened" and keep the quality, slip some of the function for a release all, customers and developers, should benefit.
All too often a management team is seduced into a release date that has the function, but a boat load of bugs. The quality goes in "AFTER" the name goes on.
Seen it several places.
good luck to you.
Post a Comment