We as a DevTeam

DevTeam consists of generalists specialists (T-shaped skill set) who can perform all work to create product increment as envisioned in the Sprint Goal. The size of DevTeam is 6±3. There is only one role in a DevTeam – Developer. Each member of DevTeam may have a specialization (say QA, front end, back end, database, etc.) but everyone is responsible to achieve the sprint goal. There are no sub-teams within DevTeam. DevTeam members follow good engineering practices. DevTeam members self-organize to achieve the sprint goal. DevTeam is a long running team and members are full time allocated to it. All of DevTeam members follow same norms and rules.

As a DevTeam, we own Sprint Backlog. During Sprint Planning Meeting, devTeam negotiates with Product Owner to keep its commitment for the sprint. Sprint Backlog represents the commitment of devTeam for a sprint. DevTeam members participate in Daily Standup and share their work and impediment if any. DevTeam is responsible to deliver product increment at the end of the sprint. DevTeam presents items to PO as soon as acceptance criteria is met. DevTeam members collaborate to complete the work. DevTeam only accepts the work as envisioned in the sprint backlog.

As a DevTeam, we participate in scrum ceremonies.  DevTeam actively participates in refinement activities to keep Product Backlog healthy. DevTeam estimates PBIs. DevTeam evaluates the technical feasibility of PBIs. DevTeam is responsible for all work to be done to deliver as committed in the Sprint Planning Meeting (in the form of Sprint Backlog). DevTeam participates in Sprint Review ceremony to collect feedback from stakeholders. DevTeam conducts Retrospective in the end of each Sprint with PO and SM to reflect on self. DevTeam helps PO to conduct Demo.

As a DevTeam, we strive for automation to keep effectiveness and productivity (velocity) curve upward. DevTeam adopts Agile engineering practices to keep the quality of product high. DevTeam members strive to learn new tools, techniques, technologies, and skills to develop T-shaped skill set. DevTeam members work closely with PO and SM to deliver consistently and effectively.

As a DevTeam we strive to deliver value with sustainable pace. DevTeam remains in conversation with PO throughout a sprint to get clarification on the Sprint Backlog Items. DevTeam has the clear understanding of Sprint Goal. DevTeam not only focuses on HOW but also knows WHY and WHAT. DevTeam is responsible for continuous delivery of valuable outcome. DevTeam is empowered to make the decision about the HOW part to complete the work as listed in Sprint Backlog. DevTeam manages information radiators. DevTeam continuously communicates with users.

As a DevTeam, we continuously educate ourselves and share learnings with technical, Lean, Agile and Scrum communities. We organize and participate in technical, Lean, Agile, and scrum oriented community events to facilitate understanding of technical, Lean, Agile, and scrum values and principles.

Teamwork fable

I hope you all know the old story about the race between a tortoise and a rabbit.  Rabbit used to boast about his speed and agility. To his surprise, the tortoise challenged him for a race. Rabbit made fun of the tortoise, but agreed for the race. As the race began, the rabbit raced way ahead of the tortoise, just like everyone thought. Somewhere mid-way, the rabbit realized that he is way ahead of the tortoise. He decided to take a short nap. After a while, when rabbit woke up, he realized that he is already late, and the tortoise is almost on the finishing line. The rabbit ran fast as he could but still lost the race. Now it was the turn of the tortoise to boast.

Slow and steady wins

But story is not finished yet. After this win, confidence of the tortoise was high and rabbit was in shambles. When the rabbit came back to his senses he analyzed the cause of his failure. Rabbit again challenged the tortoise for a race. Tortoise was over-confident and readily accepted the challenge. In this race, rabbit did not take any rest and focused on running. Rabbit won the race by a huge margin. Now it was turn of the rabbit for the glory. 

Fast and consistent always beat the slow and steady

Now it was turn of tortoise for introspection. Next day, the tortoise challenged rabbit for yet another race. Rabbit agreed immediately. Again race started. Rabbit was consistent and fast, so he was way ahead of the tortoise. But mid-way there was a river in this race which rabbit was unable to cross. Though tortoise was slow, he still won the race.

Know your core competencies

After all these races, the rabbit and the tortoise became good friends and decided to have one more race. But this race was different. Here they decided to cooperate, and not compete. In the first half rabbit picked up the tortoise and reached to the river banks in no time. Now it was turn for the tortoise to carry rabbit and cross the river. The race set a new record.

Teamwork is better than individual performance

Now it is your choice to pick the lesson.

Agile team – empirical vs scientific methods

As we all know that human behavior does not follow strict rules. At most some statistical model can be used to model approximate human behavior. Complexity increases exponentially as more people enter into and environment has many dynamic known and unknown dimensions. On the basis of statistical model if someone attempts to predict behavior of a team member, naturally lot of probability come into play. Instead of such a scientific method, empirical analysis and model fits better with human behavior due to cost and time factors.

For any successful team (scum or not scrum), I prefer to use analogy of navigating a yacht which requires continuous adjustment to reach a destination even in calm water.

In any sufficiently complex software engagement diverse skills are required. This requires team to be consisting of generalists and specialists. This specialization breaks scrum on surface which assumes that team members have broad skill set. This may not be true when team gets formed. Team members may not have T shape skill on day one but certainly can develop (provided team sticks together long enough). If work required high level of specialization, Spotify like model (guild) may be helpful.

How to integrate DevOps and Agile Teams

o   Convert development teams into scrum/Kanban mode

o   Convert support and maintenance teams into Kanban mode

o   Merge support and dev teams

§  Cross train ream members ( T shape skill especially w.r.t. Dev and support work)

§  For small development work/project DevOps team will be loaning members

§  For big projects, if devops team cannot supply all members required, few members are supplied.

How to coach team on agile philosophy/mindset

·         Remember – Forming, storming, norming and performing

·         Focus on being agile

·         There is no one solution which fits all

·         Pragmatism over purist

·         Delivery over advise

·         By example

·         Contextual over standardized

·         Showing how to be an example

·         Focus doing the correct and then doing it correctly

·         Keep positive outlook in face of failure

·         Encourage to defend its autonomy and respecting others

·         Encourage individuals to make agile transformation personal

Metrics for a team in agile environment

In agile environment, there is some dilemma about how to measure team’s performance. Yes, it is PERFORMANCE not productivity.  My first advice is not to measure performance of team.  Even then due to old management adage – If You Can't Measure It, You Can't Manage It, HR department still want to measure team, what are the different measure. There are few:


*Consistent delivery of value

*Reducing amount of repeated tasks (simply automating repeating tasks)

*Velocity has upward trend (assuming no tinkering in assigning story points to stories)

*Downward trend in technical debt

*Downward trend in defects (severity might be a consideration apart from number)

*Reduced number of spikes (assuming no new drastic technical requirement)

*Reducing number of intra & inter team issues/challenges (if any)

*SM becoming redundant in team

*Consistent actions on retro items (I have my own doubts on this item)

*Team members are happy

*Customers have only good words to say about team