Today is Wednesday, and I am on my way to the bi-weekly sprint meeting with our team from ICB in Sofia, Bulgaria. Currently, we are working on task management routines in our web and mobile application, so this meeting will be focused on adding the final features to this epic, and hopefully, we will kick off another epic if we see that time limit allows this.
The most important principle of the Agile Manifesto is to value individuals and interactions more than processes and tools. Since these are individuals who bring in impressive result by contributing unique value to software development project.
Indisputably, valuing processes and tools is important as it gives clearness and understanding, and you have a written record of communications about the project. Nonetheless, you can benefit much more from focusing on individuals and interactions. Here are the most evident advantages:
- Communication is clear and effective.
- Communication is quick and efficient.
- Teamwork is better coordinated as people work together.
- Development teams can self-organize.
- Development teams have more chances to innovate.
- Development teams can customize processes if necessary.
- Development team members can take personal ownership of the project.
- Development team members can feel deeper job satisfaction.
Of course, it is very important for development team members to be inventive, responsible and involved. In order to be able to contribute to team’s work it is crucial that team members can let go of their ego, which is not always the case. But these obstacles are minor in comparison with those which can have place while valuing processes above people:
- Concentration on processes can overshadow searching for optimal ways to create good products.
- There is no one universal process for all teams since different people have different work styles.
- One process doesn’t fit every project.
- Communication within the team can become ambiguous and time-consuming.
To overcome these drawbacks it is very important for any team to become more socially proactive!
If you want to get to know your team better, the first thing you might do is ask the members about their past experiences, their passions, and their intentions.
But while such a discussion might be of some value in order to understand why people are on the team and what they are planning to contribute, it will scarcely provide any details about their personality or about their individual preferences and prospects.
To develop deeper relationships and to improve your understanding of colleagues you are working with, to see what drives them, it is important to enhance social interaction inside the team, to improve the teamwork!
Agile visionaries believed that teamwork is essential in delivering great software and that great agile teams embody “we” rather than “I.” Nothing is more rewarding than sharing the adventure of building what truly matters together with engaged teammates.
You can frequently meet opinions of agile project managers and team leaders who emphasize the importance of team development. For example, though taking a process angle, Ricki Sickenger, nevertheless, comes to the importance of a good team in a post on his Syntax Meditation blog:
Agile is great, and methodologies like Scrum, TDD and XP can be good facilitators for getting from concept to release. But they do not explain the fundamental dilemma that a bad team fails no matter what process it uses.
… the process doesn’t matter so much as the people using and creating the process. The tools they use don’t matter as much as the individuals working together to create the process and create, or use tools which support their endeavors. Having a process is important, but not as important as the people in your organization using your process and adapting it to suit their needs in order to attain the principles of being Agile. Having tools is important, if they’re the right tools, but not as important as how you use them and what you use them for.
Agile is a person based methodology, and it is crucial for its functioning to engage teamwork and socialization inside the team.
Returning to our team from ICB in Sofia, Bulgaria, I hope we will have some time for socializing at the local pub just a few steps from the office. Just keep in mind, “All work and no play makes Björn a dull boy”.
Within the Scrum social circle three roles are defined:
- Scrum Product Owner
- Scrum Master
- Scrum Team
Each of these roles has a defined set of responsibilities. And only if they meet these responsibilities, closely interact and operate together, can they complete a project successfully.
The product owner
Product owners are the champions for their product. They are concentrated on understanding business and market requirements, and prioritizing the work to be performed by the engineering team accordingly.
Effective product owners:
- Build and maintain the product backlog
- Closely cooperate with the business and the team to guarantee everyone understands the work items in the product backlog
- Give the team precise guidance on which features to address next
- Determine when to ship the product with the predisposition towards more frequent delivery
The scrum master
Scrum masters are the champions for scrum within their team. They coach the team, the product owner, and the business of the scrum process and look for ways to fine-tune their practice of it. An effective scrum master profoundly understands the work being done by the team and can help the team optimize their delivery progress. As facilitators-in-chief, they schedule the needed resources (both human and logistical) for sprint planning, stand-up, sprint review, and the sprint retrospective.
Scrum masters also look to resolve difficulties and prevent distractions for the development team, protecting them from external interruptions whenever possible.
The scrum team
Scrum teams are in charge of unceasing development process. To be effective, the scrum team should be tight-knit, co-located and to consist of 5 to 7 members. Efficient team members are better to have various skill sets so that they can cross-train each other, which guarantees that no one becomes a bottleneck in work delivery. Strong scrum teams approach the project with a clear “we” attitude. All members of the team provide support and assistance to one another in order to reach a successful result of work.
Taking into account all mentioned above, one can notice that agile methodology is always spinning around personal interactions of all stakeholders. No wonder the frequent result of such interactions is certain misunderstanding or difference in opinions on some issues. Thus, the team social mediation is far and away a crucial point. But it is much easier to address team-related issues when you have an established social interplay within the group. It’s easier to get attention and have productive dialogues.
Social interplay entails the development of team interaction norms. Team norms exist always no matter whether openly stated or not. One of the ways to turn heterogeneous groups of employees into efficient teams is to develop a social contract — a detailed agreement laying out the basic principles of team members’ interactions. Such contract conventionally covers topics such as how members will interact, assist each other, make common decisions, and share information. In this way, social contracts clearly outline standards of team members’ interaction.
Social contract theory, nearly as old as philosophy itself, takes its roots in a statement that human moral and/or political obligations are a subject to a contract or agreement between individuals called to form the society in which they live.
The gist is to involve and engage individuals, citizens, or groups. When being engaged, there is more chance of adopting a positive attitude toward the issue, and even taking ownership and being a driving force of the issue (“issue” here relates to epic or feature in the agile scrum, for instance). If individuals perceive the environment as alien, it is less realistic to expect that members take ownership, and it is quite easy to predict that they will rather prefer to take the least resistance route. This may end up in a negative spiral, weakening the team “value”.
Even though sometimes performed in a simplistic manner, social contracts should represent a bulk of the group’s opinions. A great set of questions to cover is, “What expectations do team members have with respect to each other? What does good performance within the team stand for? What does bad performance stand for? What and under what conditions should the team start doing, keep doing, and, no less importantly, stop doing in different situations that might occur?”
Behaviors outlined in social contracts may include any positive behaviors that the team wants to encourage such as: be honest and transparent with no hidden agendas; help each other and do not hesitate to ask for help; have forums to discuss tough issues; collaborate rather than compete with team members. Such policies may be very effective, as in the case of an executive team of one of the leading financial services companies, which has recently profited from its social contract when analysing their sales slump. It prevented them from pointing fingers at each other for inefficiency, instead, they managed to work together as a team to find solutions to improve the company’s results.
Social contracts may also seek to reduce negative behaviors. In a recent team-building session, one executive highlighted a dysfunctional behavior which created oppressive atmosphere on a work place: “When a team member speaks publicly in a negative manner about another employee, it just sucks the life out of the team. We all wonder who will be the next target.” When crafting its social contract, a team can mitigate these types of harmful behaviors by simply including phrases such as, “Don’t speak negatively about other employees in their absence.”
Social contracts, if implemented correctly, have many benefits, such as giving employees a feeling of control and security in their relationships with their leader and teammates. These contracts also introduce a sense of obligation, accountability, and support among team members. For the leader, these contracts help inspirit well-behaved workers and prevent dysfunctional behaviors without coercive monitoring.
For social contracts to be of use, the team members need as well to set down up-front how members will handle violations and how they will hold each other responsible for the observance of the social contract, since, as it comes from research results, disregarded violations of formal or even informal social contracts can have such negative consequences as employee dissatisfaction, lower trust of the leader and/or teammates, and even decision to quit the project. It is important for teams to develop procedures that would help to provide honest helpful feedback, address discrepancies, and be sure when to engage the experts to get the team on track.
Social contracts can be an indispensable tool for a team, but only in case the leader does not mandate them. All members of the team must develop and share the contract collectively. The contract won’t work unless the leader and team members believe in or buy into it. And, of course, the leader should work as a role model for the desired behavior as presented in the social contract, and both the leader and the team members should care about each other and the success of the team. Only under these conditions the social contract will have real power in helping a team move down a winning path.
The behaviors that were mentioned above could lead to the concept of Team interaction.
Agile Team Interaction
Are you as a team member contributing or gaining from being involved in respective meetings or discussions? If not, let the scrum master know and leave the topic. We all have much to do and involving too many developers, managers or stakeholders only complicates decision making and progress.
There is a special term in agile for team interaction – Ground rules. This rules can be presented in the Social contract.
By definition, Ground rules are a list of behaviors and rules a squad finds useful for working together as a team in a productive and respectful way.
Ground rules, otherwise sometimes called working agreements, can serve as an incredibly advantageous tool for influencing group interaction. They help to establish such an environment where team membes can bring up hard topics and have challenging negotiations. We call this discussing the “undiscussables”.
For example, one team’s ground rules:
- No creepy stories (i.e. Don’t let more stuff “creep” into a story than defined in the acceptance criteria)
- Set up early for demo and prepare
- Never ignore anything! (Such as bugs “solving themselves”).
- We never say “no”. We say “sure, just chuck it on the product backlog. It’ll get prioritized later.”
- Be on time for meetings!
- Make sure everyone gets heard
Another team’s ground rules:
- Each sprint must have a goal
- Stay focused on the goal / top stories
- Make sure daily goals are clear (we know the steps we need to take to achieve them)
- We make decisions together
- We email documentation to everyone in the squad
- We need to show what we have done to the business people impacted, not just our product owner (when appropriate)
Our team ground rules can be described in several paragraphs:
When arranging, or being invited to meetings and discussions, ensure that there is a clear framework around the setting by having a predefined agenda and a clear expectation for the outcome of the meeting. Don’t allow meetings to turn into workshops. Always come prepared to meetings, it is not the time to touch upon the presentation or to add the final lines of code during the other participants’ contribution. Be engaged, ask questions – don’t allow yourself to leave a meeting without understanding what was discussed.
Take ownership of actions assigned to you. Engage your co-workers, but don’t assign dependencies to others – you are still the owner. Be sure to manage issues and dependencies when they appear, or at least as early as possible. Understand that your success depends on your co-worker’s progress.
Key of making a good delivery is not to deliver according to specs, but that you have a satisfied client. Make an effort to understand the customer and don’t make assumptions. Engage the product owner or customer in conversation if the feature request doesn’t make sense.
In order to have an aspiring team it is vital to respect your colleagues, team members as well as observe the established routines and work patterns. Don’t ignore methodology just because it makes no sense to you – it makes a huge difference for someone else.
That’s it for now, look forward to seeing you again next week 🙂