open | +44 020 3422 3400 | +31 208 905590 | +44 020 3422 3400 | +31 208 905590


Trends and insights making an impact in your digital transformation journey.

People factors in successful software development
Themi Themistocleous

People factors in successful software development

Problems are mostly caused by people. Thus, if one can improve the people factor, it stands to reason that the success of software projects will increase.

In my experience, the three important factors that contribute to making people more successful in software development are:

  • The culture of the organisation
  • The correct use of development processes
  • Having the right people in the right roles

The Culture of the Organization

We all acknowledge that people are our most important asset. If that is so, surely we need to create the right culture and environment to support and nurture them. Such an environment stems from the leadership of the organisation. Most highly productive teams have the kind of leaders who make it a point to do this.

Year in and year out, the companies that are voted as the best places to work or the most admired are the companies that understand the importance of an enabling culture and also happen to be very successful at creating one. Back in 1983, the first software company I joined as an executive, Systems Programming Limited (SPL), happened to be the largest software development company in South Africa. It had a few hundred developers and specialised in developing bespoke software for large organisations in South Africa. SPL was unique and had a culture that was revolutionary for its time:

  • Status was not key. Everyone in the company — from the messengers to the CEO — had the same desk and chair.
  • No memos were allowed. People had to communicate personally with each other.
  • People could buy things they needed without a formal process as long as a purchase met one criterion: would they have bought it if it were their own company?
  • Rules were kept to a minimum. Why introduce rules that affected everyone because one or two people did the wrong thing?
  • Everyone had to be tested by an industrial psychologist to determine their personality type and fit to their role, as well as to the company culture.
  • Even though there was a job description for each role (the box), the stated intention was to fit the box around the individual.
  • Over 50% of the staff were female, and the company provided a fully staffed daycare center to accommodate childcare needs.
  • Over 30% of the executives were female.

It was an extremely successful company and a great place to work. It also had the lowest attrition rate in the industry. One of the main reasons for its success was that it placed the right people in the right roles. This enabled management to get the best out of people by knowing how each could be managed most effectively. I have always tried to emulate these principles in my own companies.

The Correct Use of Development Processes

According to a 2011 survey by Cutter Senior Consultant Scott Ambler, iterative development (e.g., RUP) has improved the success of software development over the traditional waterfall process (see ”How Successful Are IT Projects, Really?“. But a common problem arose after the successful implementation of pilot projects using iterative processes. During the subsequent rollout of these processes, they were suboptimized and got a bad reputation through no fault of their own because:

  • People ended up filling in forms (artifacts) without understanding the goals behind the paperwork, thus defeating the purpose of the process. They went as far as looking at previous project documentation and simply altering the project details for new projects.
  • Organizations added additional process steps and documentation to the original lightweight iterative process in order to integrate it with existing non-Agile corporate project management strategies based on the likes of PMBOK or Prince. This added unnecessary bureaucracy to the process, resulting in projects taking much longer to complete.

That’s where Disciplined Agile Delivery comes in (watch the Cutter webinar “Agile and Outsourcing: A Disciplined Approach). DAD offers ways to provide non-bureaucratic governance, such as built-in risk mitigation and proving the architecture in the early part of the project. DAD requires you to understand and address the goals of the process rather than focusing on paperwork. This is a great improvement in terms of being able to do the right things to have a successful project. It is far better to focus on project goals than follow a process for the sake of a process.

When helping customers to implement RUP and avoid turning a simple Agile process into a bureaucratic nightmare, I used to try to get them to understand what I call the philosophies behind the process, which DAD describes as the goals. Understanding the goals behind each step of the process framework establishes a consistent way of doing things in an organization and, done properly, identifies risks and problems early. It also allows people to change projects with ease and be highly productive in the shortest possible time. The goals further enable a project team to tailor the process so as to address only these goals and not waste time, money, and resources filling in unnecessary documentation and doing unproductive work. This goal-oriented approach to using RUP has enabled me to deliver large projects successfully and even come in earlier and at a lower cost than the estimated schedule and budget.

Having the Right People in the Right Roles

Having the right people in the right roles will improve the success rate of projects. I believe that the lack of understanding of the importance of doing this is one of the reasons that cause Agile teams to fail. When implementing Agile strategies, it is important to make sure that coaches, mentors, and team leads do not assume that all people will behave and act like themselves, thereby biasing the Agile implementation toward what works best for them. By understanding the different personality types, Agile leaders can help guide their teams a lot more successfully and ensure that the right resources are on each team.

In my more than 30 years’ experience, I have seen how important it is to put the right personality types into the right roles. When I joined SPL in the early 1980s, I went through a battery of personality tests, as did all new hires. Even though people were hired for a specific job, the company would rather resolve any mismatches by changing the job description to fit people’s strengths and thus utilize their skills more effectively and increase their job satisfaction. Personality profiles also enabled the effective management of individuals, as one knew what their strengths and weaknesses were.

I have subsequently used personality profiling for all hires in the companies I owned or worked for. This contributed greatly to my project successes. In the early days of object orientation, I had some of the best OO programmers working for my company, and they were continually being head-hunted at double their salary or more. It became a real business challenge to match these offers and retain these employees.

I developed an idea to skill up people as the auditing profession did. We used the money that we would have used to match salaries to fund the recruitment of other top IT graduates and to fast-track them into becoming productive ASAP. We put these new recruits through a six-week boot camp and established a three-year training and growth plan with certain milestones that needed to be achieved. Achieving these milestones, which included relevant industry certifications, resulted in increases in salary for each individual. Thus, our hires could earn salaries way above the market. The speed of achievement was up to them.

What made this program special was that we selected a broad range of personality types that could spread across all the roles within a team. In the boot camp, we split the group into teams and got each team to obtain the requirements from the same set of users or product owners to create a solution. The product owners were asked not to volunteer any information unless it was asked for. The teams would present their designs for the system to be built in the first few days of the boot camp. It was no surprise that each team’s presentation for the solution was vastly different from the others.

The teams would then be combined to build the system using RUP. They were left to self-organize and build the system. People gravitated to the roles that we had thought best suited them based on their personalities, and at the end of the project, we did a 360-degree review. Inevitably, every member agreed that they were most effective in the roles that they had chosen. These boot-camp graduates were then trained up according to their chosen specialty, which resulted in people who were excellent at their work. Furthermore, the retention rate was superb, as people not only got to do the things they loved, but also were encouraged and rewarded to learn and become experts in their fields. This approach also spurred the growth of the business, as the graduates moved into more senior roles earlier than they would otherwise have been able to do.

I welcome your comments about this Advisor and encourage you to send your insights to

[For more insight from the author on this topic, see ”The Central Role of Personality in Agile Success.”]

Source: This article was published on The Cutter Consortium’s website and was written by Themi Themistocleous, :

About Themi Themistocleous

Themi has over 30 years’ experience in the software industry, and, as a seasoned entrepreneur, brings a unique blend of expertise in marketing, strategy, technology and finance to DVT. He is a qualified CA, and holds numerous marketing and technical qualifications. He has long been on the cutting edge of software innovation, and is a passionate promoter of Disciplined Agile Delivery (DAD). Themi’s credo is an uncompromising commitment to doing something properly, or not at all. Themi is currently the business unit head for agile business at DVT.