"Experience, Empiricism, Excellence"
Please share with your colleagues and friends

As software development practices have evolved people have specialized into specific roles such as:

  • Developer
  • Designer
  • Architect
  • Tester
  • Requirements Engineer
  • Etc.
This is further compounded by processes introducing roles, some process frameworks have 10s of roles! The problem is that as people specialize and go deeper into an area of specialization they increasingly abstract away from actually building software. Sometimes “professionalization” is the enemy of progress.
One of the drivers for these specializations occurring is the scaling of hierarchical organizations. The supporting functions around the core of problem solving have evolved new practices and tools becoming “special”. In turn they become separated from “development” due to organizational size, further encouraging their specialization away from collaborative co-creation. As organizations grow these separate areas grow in size and separation. Often this leads to status, power, “empire building” reward and recognition in the hierarchy, encouraged by Human Resources practices that emphasize responsibility in terms of numbers of people and size of budget under control rather than skill and application of that skill. This has led to a significant vested interest by old power hierarchies in maintaining this status quo, reinforced by traditional business consultancy. 
 
This is one of the reasons why a small team can run circles around a large organization. Small teams have agility built in, large organizations often have specialization, separation and excessive management built in. We recognize that this point may be difficult reading for people who’ve specialized and abstracted away from development. But consider the following questions, even if you recognize yourself in one of them consider the others:
 
How many architects do you encounter that can’t build the software but spend time drawing diagrams?
 
How many testers do you encounter that don’t realize that platform-as-a-service needs testing but spend time test planning?
 
How many Project Managers do you encounter that don’t understand modern software development but spend time planning it?
 
How many developers do you encounter that think testing is someone else’s job?
 
A well rounded developer knows how to test, how to elicit requirements and how to design software. A professional developer is skilled in all of these areas, and more. These types of people are called “cross-functional developers”.
 
Of course, there is also room for expertise. Practicing experts, who are masters of their specialism and yet still up to date with development and technology can bring expertise to teams and organizations.  The best types of experts are those with both breadth and depth, sometimes called "T-shaped people". They understand the various disciplines involved in software development reasonably well but have specialist expertise in one or two areas. Few people are experts in all areas! Often niche specialisms such as high end security or information assurance professionals simply don’t exist in enough numbers to have one embedded in every team and so we see specialists float between teams. We recommend using the Team Forming practices in the People view to help identify the need for specialists, and help them become part of a team on a part time basis.
 
For testing specifically, we often see a separation between developers and testers, or worse separate test teams. Separating the concerns of development and test splits responsibility for quality. Splitting verification into a separate role de-emphasizes prevention of problems and often leads to personal conflict. We’ve seen many testers taking a wider view of quality than simply testing which then puts them into a process management role, often resented by other team members. Alternatively, we’ve seen developers feeling in direct confrontation with testers who are constantly attacking their work. 
 
Specialist professional testers are skilled in test techniques and can act as leaders and/or mentors in test activities but we recommend that teams collectively work together to achieve the required levels of Done in whatever manner best suits the team rather than a rigid adherence to roles. At higher levels of integration, especially as part of Product Families, there will be less "coding" and more "testing" required to draw out integration issues. Integration Scenarios and their acceptance criteria are the primary source of requirements for testing at this level where more specialist professional testing skills are required over cross-functional or developer-tester skills.
 
Architecture professionalism often seems to grow out of the top end of development mastery but frequently leads into drawing more and more abstract diagrams about solutions that aren't useful to the development team. Again the balance between coding and spiking vs. diagram drawing is often more towards the coding end for system architecture and conversely towards the diagram drawing end for Product Family development.
 
We recommend that teams are solely responsible for producing products according to their required Definition of Done – that means they need to do quality activities as part of their workflow. We recommend against the use of separate test, architecture or other specialist teams.
 
Internally, teams may be comprised of cross-functional developers and a number of single specialism people. We recommend using the Team Forming practice to create useful teams from these mixes. We encourage everyone to be involved in producing, designing, testing and building the software, taking the guidance of experts where necessary but learning as much about the holistic business of software development in the process.

These specialisms tend to emerge in large organizations but startups rarely recruit requirements engineers, instead they need smart creative cross-functional people.

When hiring new people, we recommend:
  • Hiring experts in their field, with recent practical experience of general development.
  • Hiring cross-functional developers
  • Avoid hiring junior specialists
 

Please share this page

Submit to DeliciousSubmit to DiggSubmit to FacebookSubmit to Google PlusSubmit to StumbleuponSubmit to TwitterSubmit to LinkedIn