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:
They don’t dress very well
They play Team Fortress II at lunch
They talk techie all the time
They cling to each other at the Christmas party
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?
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 infrastructure. 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.
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.
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.
The team should be transparent amongst themselves and to all outside stakeholders. No secrets, no dark places.
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
They should be continuously forthcoming about risks, scope, timing and any issues that affect the product or release
They should be taking advantage of productivity tools and methodologies to ensure a rapid turnaround
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!
Call it hubris, call it ego. Call it a lack of understanding of the market and user, but a huge rookie mistake is to try to do too much. How many times have you heard this bit of common-sense wisdom, “It doesn’t have to do a lot, just build it to do a few key things and do those things well.”? It makes sense right?
It’s unfortunately easy to lose sight of this little rule-of-thumb when the momentum of product roadmap overtakes you. You browse around a competitor’s website, for example, and discover that they’ve just released a new version that has a new featureX; but you have no plans to build feature X in your tool. Well, now you need to add feature X to your scope to remain competitive. Or, maybe your legacy product has feature Y and your existing customers have learned to depend on feature Y to do their business. How can you ship your new product without feature Y? Add that to the scope.
Add a hundred more components and modules and exports and reports that keep getting added and added through demands from a few sales & marketing people, some customers, your favorite SME’s and a BA. Your simple, focused product has now ballooned into a Colossus that will take 800 man-years to release.
So, am I talking about Scope Creep?
Not at all. Scope Creep is one of those old, pre-Agile sayings that poorly organized dev shops used as an excuse not to ship software.
Scope will always change and creep. It’s normal, healthy and all a part of building an effective product roadmap. To maximize the competitive opportunity of your software, you need to be open to new market information, business drivers and innovative ideas. These will always change and add to your product backlog (total scope). Change, scope creep, uncertainty, etc. is all GOOD, wholesome stuff in the world of software and technology. Our learning path evolves every minute of the day. Think of it this way: if you don’t know more in 6 months than you do right now, you’re not really doing your job.
I’m talking more about confidence. Cojones. The guts to ship early to a market you understand.
The true challenge is having the nerve to ship your software before the entire scope is complete. As a rookie leader, you likely won’t understand that your software team can ship a quality product with the minimum possible feature set that will bring business value – even modest business value – even if it’s only to a percentage of the total market opportunity you’re shooting for. You probably won’t think it can be accomplished as a continuous incremental improvement of features over a time period of x-months or years. You’ll be more inclined to want everything – you’ll want the whole scope, first time, and ship that with a huge boom – you must, as a rookie, obliterate the competition with one crushing blow. Or, maybe yours isn’t an ego issue. Maybe you’ll want everything because you’re not confident enough in your understanding of the market and users; so best hit them with everything and maybe something will stick.
Either way, Big Rookie Mistake.
Wanting everything is obviously the wrong way to think about it both from a technical and business point of view. The fact is, it actually takes a great deal more courage to be laser-focused and put your product out to market with a simple, lightweight vision to accomplish a few targeted things to a clear and strategic market. There is much more of a calculated mastery in that.
And, sure, you will continue to have a product backlog of great, innovative ideas to add to the product over time. Believe me, there’s time for that. What the more experienced Business Leader will know is that: getting your more precicely-focused product to market accomplishes four important things:
You now have commercial adoption of your product. (Reduced risk)
You’ve minimized the investment needed to generate revenues. Your product is now out there making money, and you’ve spent a fraction of what your total scope will cost. (Increased ROI)
You are now receiving valuable customer feedback on your product, which will help you further prioritize the next features to add. (Strategic market information)
You and your team have proven that you can build and ship successful software. (Time to celebrate
Ok, so now if you don’t want to fall into this trap, what do you do? The key is to prioritize the backlog. You have 100 innovative, killer features you want to put into the product, but you only have room for 10 this realease. Someone has to take ownership of which 10, and in what priority. Then prioritize the next 10, and so on. Maybe the remaining 90 will change after you’ve shipped the first 10. That’s a good thing. Keep prioritizing the next 10 (or however many you choose). Have a look at this article by Dennis Stevens on Capability Analysis for some good insight on prioritizing features.
Who owns that? Typically your Product Manager or Product Owner. Maybe you do. Whoever it is, remember, one of the most important things for a software development team to be armed with is: What To Do Next. Mike Cohn has some sound ideas on the Product Owner, backlog and other gems to help gain more context with this.
A few months ago I had lunch with a friend who wanted to pick my brain about some frustrations she was having with her company’s software development department. Her company produces specialized machinery for something (actually, I forget what they do), but they also build and sell software products. In her role, she leads up a marketing team in charge of commercialization, PR and marketing of their software.
She started the lunch in a quite civil mood – the food was great, the restaurant was awesome – but once she started talking about their software guys, she got a bit edgy. “I don’t know what they’re doing.” She said, clearly agitated. “We’re supposed to release this new version in 3 weeks, and I’ve never even seen it. I don’t know what new features are actually going into it, and they won’t tell me.”
“Every Time I go to meet with them to get more information, they treat me like I’m an intruder – like I’m some annoying idiot from Marketing invading their turf. All I get is hand-waving and the big brush-off: ‘Nothing to see here pretty lady…’ blah blah blah.”
“I don’t get it. How am I supposed to do my job? We’re supposed to go live in 3 weeks and they won’t even show me!”
My immediate reactions while she was telling me this story were a bit like this: I wanted to go strangle that software team. It was clear that they were badly organized, lacked leadership, they’ll no doubt miss their release target, it will ship with a reduced set of features, and the quality will be poor. I got especially annoyed when she went on to tell me that they were “Agile”. Her comment was, “I know you do Agile too, but I don’t think it works.” That was the clincher.
Agile is all about transparency, it’s about delivering continuous working software, it’s about inviting all stakeholders in to participate in the development of a product. Like anything, there are a lot of pretenders out there using a popular concept to hide their own inability.
So, if you were in my shoes, in that situation, sitting across from her, what would you say she should do?
Should she escalate the issue to higher-ups?
Should she continue to badger them till she got answers?
Maybe she should just know-her place. Bow down to the divine miracle-makers in software. Wait patiently until they’ve completed the magic-of-software-development before asking more tedious marketing questions.
What would you say? (see poll below)
Ultimately, there are so many things wrong with this situation; I struggle to know where to begin. So, I’ll make a quick list of the obvious problems that this represents before diving into any detail:
There’s a clear misaligned idea of product ‘ownership’. While the product should be owned by the business as a whole, the development team appears to view their role as somehow ‘more entitled’
There is a dangerous breakdown in Transparency and Communication
The software team doesn’t know how to ‘ship’ software
A misaligned idea of product ‘ownership’
Clearly many software teams are compelled to believe that what they do – their role in their organization – is to ‘write software’. Which, in some respects, has some functional truth to it; but the greater truth to what technology professionals do is, “Build Market-Driven Products”.
So, okay, maybe that statement makes you want to roll your eyes to the sky … but at the end of the day, we all work for a company that is in the business of doing business. Making money. Whether you’re building commercial or internal software, your company is investing in your time because they believe that it will help them make money. It’s pretty rare that someone will pay you to play with technology. The fact is, they’re paying you to do whatever you can to produce a product that has the maximum market potential and ROI so that they can make money.
The long and short of all that is: the technology team doesn’t ‘own’ the product and they have no right to throw up barriers around that product when other stakeholders with equal ownership need to participate in the product’s success. The product is owned by the business, and the software group’s contribution to that should be a business-driven contribution. NOT a technology-driven contribution.
A Breakdown in Transparency
Software developers have a strong desire to hide in a dark corner and fidget away at their work – their creation – for as long as they can get away with. The goal is to reappear, unveil the masterpiece with a “Ta Da!” and crowds will applaud the genius, the angels will sing and he will have saved the day.
This is likely the most dangerous thing in the world of software.
Ensuring that your team is fully transparent from all aspects of communication, visibility and availability of working product is absolutely fundamental to a successful software project. If you’re getting pushed off with the “Move along, nothing to see here…” attitude from the dev shop, it’s a clear sign that things are not well in that department.
Learn to ShipSoftware
I just had a chat with my friend, and as it turns out, 4 months later, they still haven’t shipped that release. And it’s still not clear to her, or anyone else outside the technology department, what will be released or when.
Writing the code is only one aspect of creating a commercial product that you deliver to happy customers (internal or commercial). The act of shipping that software product is craft that requires practice, experience and a lot of planning. It’s tricky to ship. No question. So, to manage the risk and pitfalls that exist around getting your product to market, best practices tell us to ship all the time. Ship your software as often as you can. Even if it’s only to internal stakeholders – your BA, Product Manager, trusted clients, etc. Ship.
If you are on the outside looking in; and your dev group can’t prove that they can ship the software asset you’re investing in long before the release date – this is another sign that things are not well in that department.