Get Your Team Working Together

woodleywonderworks

Let’s face it, compared to other engineering disciplines software development is just coming out of the stone age. Heck, I’m sure I’ll get a lot of flak for even suggesting that software development is an engineering discipline (though I have to admit the way a lot of developers go about their work, calling it engineering does seem a bit of a stretch). Real life is seldom black and white, but I’d like to describe the two basic camps below.

Serial processing through departments for Release X.Y.Z

Most of us have worked at a place like this and, unfortunately, most of us still do. You know what I’m talking about – a traditional shop running with the waterfall process. Each department spends months working on a feature that ultimately, not many people are thrilled about releasing.

 development is finished when the calendar has advanced to a mystical date picked out of thin air months before

 after “finishing”, the QA department can begin testing and will find the bugs (after all, this is their job, right?)

 operations is generally the last to know about the new feature resulting in emergency architecture meetings, more compromises, and even more delays

Parallel processing within a team to deliver RTFs

Ready Tested Features are one of the main goals of agile software development. Instead of defending turf, the development teams in these companies aim to please the customer by regularly delivering features.

 small teams of designers, developers & system architects work in parallel on a daily basis

 the team strives towards delivering something to the customer in weeks

 development is finished when the team has met the customer requirements

Why we can’t change

Change is the only constant in life and most people don’t like it. In trying to improve your development processes, here are a few classic excuses you’ll hear from the naysayers:

“We need to sit in our department to make sure we don’t do conflicting work”

• what it really means → insufficient integration testing
• what to do ⇒ give QA a real job – begin to implement an automated integration test suite

“Our developers work in another country a thousand miles away”

• what it really means → the shareholders have spoken
• what to do ⇒ heavily invest in video teleconferencing equipment, conduct video sprint meetings and daily scrums (also consider conducting face-to-face quarterly planning games to help align and gel the team)

“How can we plan our data center infrastructure if you don’t even know what you’ll be doing next week?”

• what it really means → we don’t know how to plan for capacity
• what to do ⇒ employ meaningful business monitors (not how many images are created but how many photos are uploaded). Prepare monthly presentations to upper management showing growth vs. capacity (having to prepare for this meeting is a great way to PULL the information out of your data center).

Now that I’ve given you some hints how you can begin to change your daily work, what are your experiences? How do you do development in your current company?