The Top 5 Rookie Mistakes in Software – #4 The Team

How do I know if my Development Team is any good?


Good Question.
Actually, it’s a critical thing: the importance of The Team can’t be understated. It’s one of the single biggest factors influencing the success of your software.
Those who aren’t seasoned with a) how to hire a good development team and b) know what to expect from them, will likely be faced with a frustrating time. Without more to go on, they’ll use something like the following as their criteria:
  1. They don’t dress very well
  2. They play Team Fortress II at lunch
  3. They talk techie all the time
  4. They cling to each other at the Christmas party
  5. They babble like idiots when a girl walks into the room
If all these are true, they MUST know what they’re doing.

Leaving it to chance is a pretty common mistake.
I had a funny-but-tragic experience working with a guy who’d been given the responsibility to integrate a recent acquisition his company had made (he was the VP of something). He was a super-smart guy, but not that experienced in the world of software. He figured out pretty quickly that to accomplish the IT side of this integration, all he needed to have built was a Map.  A web-based map that a user could log into and find out key land ownership information by zooming around and clicking on land parcels.  Really, that easy.  But he needed it quickly – this was key.  So, rather than taking his requirement to the IT (dev) department, who were notorious for having all kinds of barriers and rules and taking forever to turn something around, he instead gobbled up a couple developers who happened to be kicking around after some acquisition or other. Two guys who fit his profile: they were programmers and at that moment had a fairly aimless list of things to do.
They’ll do, he thought.  A developer’s a developer, right?

time

So he gave them his map vision, and to his amazement, they had something up and running within days.  Days! This was gold!  He couldn’t wait to give his status update to senior management.
Flip to the developer’s perspective now: they wanted to secure their jobs.  So to get some quick sizzle to the VP, all they did was download an evaluation copy of ArcGIS Server and ran a tutorial with some sample data and sample shapefiles.  They loaded the server part, clicked next->next->next on all the various wizards; and splammo, things were pretty much up and running.  They couldn’t wait to show him their status update: they’d basically got the nuts & bolts of his Map working.  He, of course, was over the moon.

I’m going to skip a few details and flash forward a bit…
A year later, my VP friend still didn’t have his map. A simple map to enable users to click on a land parcel and get a quick report.  What!? Why would that be so hard?   I had lunch with him around that point and, the poor guy, he couldn’t contain his frustration, “All I want is a MAP!” he echoed over and over while pumping the air with his fists.
Those two developers? They were re-distributed into the marketplace, and a few new ones had been brought on to take their place. There’s now a full team working this project.

So what happened there?

Self-Organization and The Product Team

Well, lots of things happened. I could tear into this problem – unfortunately, a pretty common problem – from a variety of angles, but I’ll summarize it this way: the developers didn’t organize themselves into a product team.  They didn’t take technical ownership of the situation and instead reverted into being day-to-day programmers, just coding whatever the VP asked for.  And ya, HE was totally at fault too for completely misunderstanding the magnitude of the effort required, and for dismissing the need for proper development splat 2infrastructure. However, in this world we live in, there is an obligation for the technology professionals to self-organize and assume a higher level of responsibility. In their case, they completely failed to effectively communicate, and act on, of the true scope of his simple Map.  They just performed tasks and went home at 5:00.  No Team. No Product.

This type of thing happens all the time.  All. The. Time.  Complete disconnect in communication and understanding between technical and non-technical people:
  • Person needing dev help clutches onto a programmer and asks for stuff
  • Programmer goes “Sure”
  • Person is pacified
  • Programmer is thinking, “Task”, but Person is thinking, “Commercial Product”
  • Ok, person is really thinking more like, “Product that makes serious money or makes me a star.”  Programmer is thinking, “Maybe I can finally use some Windows Workflow for this.”
  • Disaster. Everyone is sacked
The best designs and successful software products emerge from high-functioning teams.  The developers themselves don’t necessarily have to be superstars, of course.  As in most anything, even a group of strong players can fail badly if they don’t work as a team.  Similarly, a team of average programmers who communicate well and build trust & respect and a team atmosphere, are more likely to succeed than a group of aces who fail to interact as a team.

The point I’m trying to make is; to determine if your dev team is any good, I’d worry less about whether the individuals are champion programmers, but more about how they organize as a team.  This goes for small teams, large teams, small companies and big companies.  It’s really all about the team and the fact that they recognize that they’re not simply completing tasks, but building a commercial software product that has a customer at the other end of it. There’s no question you do have to have good people who know what they’re doing and know how to get software to market, but it’s the team that builds great software.  To that point, the aim in this article is to present some ideas on how to evaluate a software product dev team.  So, the discipline of ‘Hiring Good People’ is not really the topic being addressed – that is an art and a science, and a different conversation.

What to Expect From The Team

Still not sure how to tell if your dev shop is any good?  Below is a handy list of 6 quick tips to help you figure that out.

As an outsider looking in, you might struggle to know what they’re supposed to be doing on a day-to-day, week-by-week basis.  Don’t just cross your fingers and hope for the best – you’re better off knowing what should be happening.Emergence

I’d encourage you to have a look at an earlier posting on Software Failure that contains key recommendations for processes your team should be engaged in.  The following points – which are aimed more at someone overseeing a dev group – will provide a quick indication of whether or not a development team is working effectively.

  1. The software should always be working as an integrated product. You should be able to see continuous measureable progress in the product. It should move forward every day and every week.  You shouldn’t have to go to a developer’s machine to look at software in progress.  In other words, they should be ‘releasing’ it on a daily or weekly basis.
  2. The team should be transparent amongst themselves and to all outside stakeholders. No secrets, no dark places.
  3. The team should be measuring their own progress.  They should metric themselves by estimating on sprint tasks then, after the sprint is complete, reflecting on what was accomplished. Each team member should present/describe what they’re going to do, and then explain what they’ve done
  4. They should be continuously forthcoming about risks, scope, timing and any issues that affect the product or release
  5. They should be taking advantage of productivity tools and methodologies to ensure a rapid turnaround
  6. They should have an obvious desire to innovate

Let me know if you have any questions about any of these.

This isn’t a one-sided relationship – Obviously the team has many expectations from outside stakeholders as well. That is coming in another posting on rookie mistakes.  Stay Tuned!

Chris Ronak

Advertisements

2 responses to “The Top 5 Rookie Mistakes in Software – #4 The Team

  1. Chris,

    A very interesting artical.

    Self organizing – how do you evaluate this? How do you know if they are self organizing well? What are typical management actions to move a team that isn’t self organizing to one that is? And when the team is self organizing, what management actions and activities are required to keep it self organizing?

    How do you move from a working practice where the product isn’t integrated to where it is integrated?

    Thanks

    2bananas

    • From a management point of view, it comes down to the visibility you have into progress in the app. The team’s own internal self-organizing structure is not of huge interest to you: how they’ve managed to divide out their ownership and roles is not something you need to get involved with as long as they give you visibility. The key is, if they’re organized, the team should be releasing daily or weekly; so you should be able to go view progress from some known place. If they don’t have an ‘independent known place’ setup, that’s not a good sign. If you then ask them if you can see the app in progress, and they bring you over to show you on their own machine – this is a bad sign. If the team isn’t releasing, they’re probably just ‘coding features’, because developers prefer to just ‘code features’. The problem is, ‘coding features’ amounts to 40% or less of the total effort required to ship a successful product. Things like: Deployment, Security, Licensing, Administration, Operations, Integration, etc. are all things they prefer to avoid as long as possible. Not to mention: QA, Usability, Technical Writing and other efforts non-related to ‘coding features’ that are required to ship, need to be arranged. If all these things aren’t obviously being addressed by the team from day 1, your action as Management, is to simply ask for it. And continue to ask for it – you have every right to expect it. My team today ships the product several times a day. I can go to a web page and download a MSI that deploys the product on my machine. It’s a work-in-progress, but I can tell exactly what’s changed from one day to the next. I didn’t have to ask for that – and I don’t care how they’ve arranged themselves internally; I just care that I can see the product moving in the right direction.

      Chris

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s