If we look at how most branded approaches for software development are pitched, we see that there is little active consideration for the team that will be dealing with that new approach. One could cynically suggest that this is because these approaches are being hailed as silver bullets that are independent of the participants, but I think it goes deeper than that.
There are several reasons for neglecting specifics about the human element, but also some deep challenges in failing to do so.
First, the complexity of dealing with the human element when we are dealing with teams and processes can be daunting. Teams come in all shapes and sizes, and there are at least as many different motivating factors for participating on projects as there are people. There are many complex emotions that come into play, and this entire mix is constantly changing. It would be impossible to capture the essence of this complexity and to provide a generalized solution on par with a description of practices and team behaviors. In order for the description of the approach to be attractive, it needs to be simple enough to be easily assimilated without losing the audience’s attention.
Secondly, most of these branded approaches got their start with a handful of people who had success on a handful of projects. While there may be some discussion of elements such as trust and fearlessness, these are generally dealt with through hand waving and generalities, not explicit practices that are defined. For the most part, concrete emphasis is on the practices themselves. In almost any retrospective I have been a part of, discussions about what worked and what needs to change focus almost exclusively on the team practices. Things like defining scope and planning, design practices, implementation and validation approaches. Even if symptoms of dysfunction such as the team not getting along are raised, the solution space generally consists of practices we see as within our control – those same team practices described above.
Implicit in the success of most teams is the relationships that have developed among the team members. Indeed, when you are asked to think back and describe the approach used on a project that you would have considered successful, there is a good chance that you would describe elements like a change management process, or nightly builds, or test-first development, or tactical access to a customer. If you look deeper, though, and consider how the team worked with one another, you will find other, more important elements. The team surely cooperated well with one another, demonstrated a level of trust and shared a common goal. Everyone felt like they belonged, and actively participated in working toward that project's success. In working with teams, the one common element that everyone has identified as part of their successful project experience was that they had fun.
Nothing about tools or technology, nothing about lifecycles or methodologies. These are necessary, but insufficient. Success is primarily dependent on the relationship between the team members. This does not simply go without saying. It is absolutely critical, and needs to be consciously managed. As a team member, it is all about you.
There will be relationships between team members whether or not these are consciously observed or managed. Regardless of our selected approach for developing software, people will have to interact with one another, and each of these interactions will be successful or not based on the trust, respect and shared vision of the participants. If all of this is left to chance, how much of an impact can one selected approach have over another?
If we really want to improve the way we develop software, we need to start by understanding the team itself - what each participant brings to the table. We need to bring all this out into the open, discuss our goals, reflect on our cultural distinctions, celebrate our combined strengths. The better we understand each other on the team, the stronger our trust will be, the more genuine our relationships will be, the more effective our interactions will be. With a consciously managed inventory of our skills, experiences and attitudes, we are better equipped to select which approach will be most effective for completing our projects, and indeed how we should deploy this refined approach with the team.
This all takes time, to be sure, but consider the cost of miscommunication, disappointments, broken trust and other forms of interpersonal dysfunction on most projects. In that light, the effort to better appreciate everyone involved on the project starts to look much more like an investment after all.
Take advantage of special member promotions, everyday discounts, quick access to saved content, and more! Join Today.