In this article, we will discuss my notes regarding the pragmatic teams, what are they and why you should strive to build a pragmatic team or become a member of one.
Why build a pragmatic team?
First of all, this article’s title is influenced from the excellent book about software engineering best practices from Andrew Hunt and David Thomas, The Pragmatic Programmer: From Journeyman to Master, which I read recently.
In addition, I strongly suggest not only to read, but also take notes and think about the ideas and the engineering culture this book suggests. As an illustration, it covers topics ranging from personal development and career decisions to architectural patterns and software development methodologies, so most readers will find something interesting that applies to their current situation.
What are pragmatic teams
The first thing to remember is that a pragmatic team is not a team which is formed under some vague principles. In contrast, it is a team that consists of pragmatic developers working in an enabling environment.
Most noteworthy, the authors of the aforementioned book promise that once a group of pragmatic developers is formed, the group will define their own team dynamics that best suit them.
Pragmatic team dynamics
We should build our pragmatic team on some distinct unconditional values. In general, all members of the team internalize these values and are always seeking to improve, evolve and adapt.
Quality
Teams should not tolerate small bugs that no one fixes. All team members should take responsibility for the quality of the products the team is shipping.
Monitoring
Make sure everyone is able to monitor and actually monitors the project for changes. Monitor things such as:
- Project scope
- Time issues
- Feature requests
- Any requirement changes
Communication
Developers must talk to each other. Pragmatic teams communicate clearly:
- They hold structured meetings
- They produce consistent documentation
- The team speaks with one voice and understands humor
DRY(sic)
The well-known development rules should be respected and followed in the context of a team too. The point of this strategy is that all team members know to whom to talk about their project issues and to eliminate duplicated work.
Assimilation
Team activities can’t happen today in isolation. In detail, people from different backgrounds can offer valuable insights into a problem domain they are not experts.
Call to action
To summarize, the pragmatic team notion really helped me grow as an engineer and as a valuable team member.
From my experience, before we can start discussing building our culture, refining our methodologies and expand our teams we should fulfill our own personal duties.
All things considered, we should strive to build an enabling environment. Furthermore, learn to celebrate the power that comes from individuality. Rather than fear anything not technical, focus on how to ascend beyond the engineering tasks.
Most of all, adopt a growth mindset and grow as communicators, problem solvers, and social beings.