Why a tool doesn’t bring you business success
A couple of days ago FC Internazionale Milano won the UEFA Champions League final. Is it due to the qualities of Wesley Sneijder? Although he’s an excellent football player it’s definitely not due to his individual qualities only that Inter won the Champions League. Is it because of the coach, Jose Mourinho? He definitely played a big role, but it’s still a combination of a team and it’s coach. Is it due to a technical head start in equipment?
Let’s stop trying to come up with more questions, I’m definitely not an expert in this field.
When I was musing about this subject I realized something. On this blog I write about technical stuff: Service-Oriented Business Applications, Model-Driven Software Development, and a combination of these subjects in something like Model-Driven SOA. I like to think and write about these subjects, I also like to explain why these techniques can give you real business advantage. However, in practice, it’s not the tool which brings you business success; it’s a combination of a team and a tool.
Empowering a team with a tool
A fool with a tool,
is still a fool
bringing disaster faster.
A tool always contains a balance between flexibility and guidance. The more flexibility, the more a team needs to decide on its own how to use the tool. For example, when using a Model Driven Development tool the team has to decide what models have to be created in what order. Other decisions include change management, work breakdown, project management, etc. That’s why tool needs to be accompanied with a methodology. Or, better: a tool implements (or supports) a certain methodology.
It is people who develop software. Their productivity can be improved a lot using tools, however, they’ll need guidance on how to use these tools. Templates can help to make the start with a tool a lot easier. Reference models can help to show the best practices. Both can provide guidance and structure. This is one of the reasons we recently introduced the Mendix App Store, tightly integrated with our Model-Driven Development environment, to search and download templates and model parts directly into our tool.
Again, it is people who develop software, so even methods and tools are not enough. Ivar Jacobson, one of the founders of the SEMAT initiative recently wrote about two complementary macro-trends in software engineering. He states that besides methods and tools (e.g. the SEMAT initiative), we also need professionalism and craftsmanship. There’s a human side to software engineering and what we need to improve this field is better training and education for people to become professional craftsmen.
I believe we need tools to make teams more productive. However, tools are not enough. We need to empower teams with a tool by providing accompanying methodologies, templates, references, and by not forgetting the human side. After all, it is people who develop software.
The importance of a team in building a tool
It’s not only the team using the tool playing an important role. The single most important thing I learned in the last couple of years is that to build a successful software product you do not need a team of excellent people, you need an excellent team of people. The latter doesn’t exclude the premier of course.
In this piece explaining the dangers of programming alone, there’s an excellent quote (source doesn’t exist anymore). I couldn’t express my feelings around the importance of a team in a better way, so here it is:
Some folks have claimed that [working alone] presents a great opportunity to establish your own process. In my experience, there is no process in a team of one. There’s nothing in place to hold off the torrents of work that come your way. There’s no one to correct you when the urge to gold-plate the code comes along. There’s no one to review your code. There’s no one to ensure that your code is checked in on time, labeled properly, unit tested regularly. There’s no one to ensure that you’re following a coding standard. There’s no one to monitor your timeliness on defect correction. There’s no one to verify that you’re not just marking defects as "not reproducible" when, in fact, they are. There’s no one to double-check your estimates, and call you on it when you’re just yanking something out of your ass.
There’s no one to pick up the slack when you’re sick, or away on a business trip. There’s no one to help out when you’re overworked, sidetracked with phone calls, pointless meetings, and menial tasks that someone springs on you at the last minute and absolutely must be done right now. There’s no one to bounce ideas off of, no one to help you figure your way out of a bind, no one to collaborate with on designs, architectures or technologies. You’re working in a vacuum. And in a vacuum, no one can hear you scream.
If anyone’s reading this, let this be a lesson to you. Think hard before you accept a job as the sole developer at a company. It’s a whole new kind of hell. If given the chance, take the job working with other developers, where you can at least work with others who can mentor you and help you develop your skill set, and keep you abreast of current technology.
In short, you need an excellent team of people to:
- structure the development process,
- brainstorm, crunch knowledge,
- collaborate on ideas, designs, architectures,
- to keep asking for the rationale behind incoming requests,
- strive for excellence.
But also to:
- prevent you from pitfalls,
- review your work,
- keep you on track.
I can tell you that being part of such a team is not only a beautiful experience, it also leads to exciting results!
Creating the right environment
No matter in what place of the chain of software development you are, you will need an excellent team of people to really succeed. For example, as mentioned before, a team building a tool, or a team using a tool to build a business solution. The question is: how to ‘create’ such a team. Or, formulated in better way: how to create an environment in which such teams prosper?
A lot has been written about this subject. Freedom and empowerment are important key aspects in building excellent teams. As a starter into this subject I recommend to read Twelve Tips for Team Building: How to Build Successful Work Teams. Another interesting article in this area is Urs Peter’s summary of a seminar by Marc Lammers, one of the most successful hockey coaches ever. He shares the principles Marc Lammers discovered and describes how they can be applied in software development.
Another important aspect in creating the right environment is to motivate people. When motivated a team can face almost every challenge, if not there’s nothing you can do unless you find a way to motivate your team. You really should watch this excellent, cartoonish movie explaining the truth about what motivates us!
In short: once the tasks people should execute call for rudimentary cognitive skills, a financial reward doesn’t work, it sometimes even lead to less motivation. There are 3 factors that motivate people:
- Autonomy: the desire to be self directed.
- Mastery: the urge to get better at stuff.
- Purpose: the need to make a contribution.
For a list of practical points see 25 sure-fire ways to motivate your team members.
While context and people are always different, there’s no straightforward guide telling you in detail how to build an excellent team. In my experience the first step (of a manager) in creating an excellent team is taking a step back.
What are your experiences in successfully adopting a tool? What are the key success factors in your opinion? What should a tool provider do to make sure a team can get the most out of a tool?
4 Comments Added
Join DiscussionA fool with a car is still a fool.
A fool with a Large Hadron Collider is still a fool.
I’m not sure what the benefit of these statements are.
I though you may like to know of a discussion on LinkedIn about EA tools “GARTNER: “A FOOL WITH A TOOL IS STILL A FOOL”
Its here http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&discussionID=20329940&gid=36781
In the EA Network Group which you need ot be a memmber of here http://www.linkedin.com/groups?home=&gid=36781
Hi Kevin,
You clearly don’t like the fool with a tool quote 😉 I hope it didn’t hold you from reading the reminder of this article.
What are your experiences in successfully adopting a tool?
Hi Johan,
No I did not read the rest of your article. Many apologies 🙂
But I Have now.
You’re post here touched a nerve but that nerve is only really in name more than substance.
We are coming at tools from 2 different perspectives and my perspective and the mental baggage I carry as a result is based on a quote from Gartner, in the context of Enterprise Architecture. (Note that Gartner still thinks of EA as largely an IT centric discipline which is not my belief)
There are many problems with organisations adopting “true†EA (tEA????).
What Gartner seems to be saying is that don’t’ start by buying/using a tool – even though many organisations have very successfully adopted this approach as evidence by a presentation by Colin Birchenalls at last weeks conference where starting with a tool was the absolute best approach for Serco and Glasgow City Councils LLP and for the many successes they have achieved in growing up to the full EA level by delivering massive and real value.
But to answer your question “What are your experiences in successfully adopting a tool?†Having spent over 30 years in industry and growing up through the IT route I have seen many IT tools in use and mostly with great benefit. Maybe it’s because IT people just “get†tools. IT people tend to be able to just generally “use†tools without any training apart from a quick look in a help file every now and then.
Business people, however are a different kettle of fish and, since EA tools are meant to be used by just about everyone in the organisation and the more senior and business oriented the better, EA tools perhaps have a harder time in terms of acquisition and also in terms of being used correctly.
In terms of just EA tools, my experience has been very bad. There have been only 2 places I have worked that adopted a tool (Casewise in one and System Architect in the other). In both instances they had been acquired long before I arrived and were very old. They were either not being used or being used incorrectly.
Acquisition of EA tools also have cost problems as people perceive them as expensive. Some of them are, but some are free. However, the expense of the license is actually not the problem. The expense of training and integrating (culturally) the tool is the much bigger problem and where many companies that swallow the license cost come unstuck. Ultimately the “project†fails and then people think that adopting a tool was a bad idea, when in fact it’s not the tool that is at fault but their adoption processes.
PS
If you want to see the EA Tool discussion I referred to, its on this lineked in group http://www.linkedin.com/groups?home=&gid=36781 and on this thread http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=36781&discussionID=20329940
> Ultimately the “project†fails and then people think that adopting a tool was a bad idea, when in fact it’s not the tool that is at fault but their adoption processes.
I think our experiences are largely the same. Thanks for sharing yours!