Saturday, January 14, 2012

Sustainable pace at work and having a special needs child at home

Sustainable pace within software development teams has been discussed in depth for many years. I first came across it when I was introduced to eXtreme Programming in 2000. It's a sad state of affairs that we have to explain that knowledge workers perform better at a pace that isn't to fast and not too slow, but at an even cadence.

This isn't just good for productivity at work, but also for those of us with children with special needs. If you don't have a child with special needs you may not be familiar with the amount of stress parents are under. Firstly there's the stress just from the fact that your child has additional needs. Then there's dealing with the additional needs themselves. (In my case there's constant supervision, many sleepless nights, meltdowns, developmental delays, sensory issues, etc). In addition to this there are appointments and paperwork that needs to get done. There's also worrying about the future too. The list goes on.

We have all this and have to hold down a job. Working the occasional night or weekend is fine, but because a lot of us are so tired already this can't be maintained for long periods of time.

This is where sustainable pace comes in. It levels the playing ground between parents of children with additional needs and everyone else. We can come in on time and leave on time without feeling guilty or stressed, because everyone else is doing the same. It also lessens the risk of burn out or getting sick.

What are your thoughts on this issue?

Sunday, January 8, 2012

Are software maintenance teams an anti-pattern?

This might be a controversial position, and I'm not trying to make light of the good work software maintenance teams do, but I'm questioning the need for maintenance teams at all.

The idea behind having a maintenance team is to take pressure off of software development teams so they don't have to deal with triaging customer issues and fixing bugs. Sometimes this also includes creating minor enhancements to the software. There's also the economy of scale where one team can support many applications across an enterprise. Note: I'm not talking about support teams that help customers and may in turn create bug tickets (that's a conversation for another day).

That said, handing software over to another team is problematic and expensive. It's not possible to transfer all of the knowledge that has been gained through the development cycle and the application may have to be documented heavily to compensate.
In a lot of organisations I've come across the idea of having a maintenance team is standard practice and sometimes considered a best practice. This is something that I think we should challenge.

To me when I hear about software being handed over to a maintenance team it points to one thing, they are having quality problems. There are too many defects escaping to production and the developers are getting bogged down with fixes so they aren't able to create new functionality as quickly.

Rather than putting a bandage on it, the organisation needs to step back and ask themselves why they are generating so many bugs. The bandage may take pressure off of developers, but also tells developers that they don't have to be too vigilant about finding bugs before release because the maintenance team will fix them.

There are many reasons for quality problems within an enterprise, too numerous to mention. That said, there are a number of things a software development team can do to improve quality and reduce the need for a maintenance team.

1) have quality as your number one organisational and team value and actually practice what you preach rather than paying lip service to it.

2) give the team the space to create quality software.

3) use techniques to push defect detection as early as possible (TDD, continuous integration, pair programming, pair testing etc).

4) focus on ways to improve quality in some of your retrospectives and make sure that the action items actually get tested and implemented.

5) make sure your code is potentially releasable at the end of each sprint.

6) visualize your bugs so that everyone can see them at all times.

Yes you probably will still get bugs in production, but they should be fewer and shouldn't overwhelm the development team.

What are your thoughts on this?

Sunday, January 1, 2012

Which member of the Agile/Lean software community influenced you the most in 2011?

Nominate the member of our community who influenced you the most in 2011. Please one nomination per person. Based on this list I'll set up an online poll.


Leave the person's name in the comments below as well as their Twitter id, G+ or blog URL.


This was originally posted on Agile+