Before we get back to our discussion on Scrum team performance, let’s take a look at a real world example of how agile works versus how waterfall works (or doesn’t).
Coronavirus and Agile
As of this publication there are 9,215 confirmed cases of individuals with the Covid-19 coronavirus in the State of Wisconsin, 1.27 million cases in the United States overall, and 3.91 million cases worldwide. Of the 187 countries with known virus cases, the U.S. is trending at the highest rate for new daily confirmed cases. Why?
The answer is simple: We (Americans) continue to fail to follow the “WE are smarter than ME” approach to solving problems. In this approach we assume that none of us knows everything but if we put our collective heads together, we can solve nearly any problem regardless of its size. And yes, in case you’re wondering, I am referring to the way agile works and why it is so successful.
Instead, we – but primarily the folks in Washington, D.C. – are using the old command and control “shut up and do what I say” approach to problem solving, which does not really solve problems.
∴ Agile is best. Let’s start using it, even in Washington.
Back to Dev Team Performance
In my last article I set the stage for understanding and examining Scrum team performance. I described how the three roles of Scrum – product owner, Scrum master and development team – need to perform in order to deliver maximum value: Value to the customer, value to the organization and value to the Scrum team itself.
I then stated that three things are required to create a high performing development team…
- Rudimentary development skills
- Cross-functional team composition
- Excellent communication skills
I also mentioned that every member of the development team needs to be a committed life-long learner.
Let’s look at the first of these three requirements.
Rudimentary Skills Needed
Keeping in mind that it is not necessary for Scrum to be applied to the production of software, the development team might be better labeled as the “people who understand, decide and execute on HOW to get mandated work done.” Recall that it is the product owner who determines WHAT work is mandated.
What We ARE NOT Looking For in a Team Member
Heroes are persons in nearly every business setting who exhibit one or more of the following traits…
- Strong knowledge of a narrow band of products or services
- A goto person for when anything critical breaks
- Someone the C-Level folks know by name and by reputation
- Work hellacious hours in order to satisfy needs in emergencies
- Depend upon their reputations as heroes for heightened self-esteem
- Hoard information, tips and tricks for perceived job security
They tend to be the ones everyone relies upon to get things back up and running. They might ignore family, friends, colleagues, and even their own needs in order to deliver a heroic solution. What they don’t do is…
- Provide their colleagues with a platform upon which to learn
- Repair or replace code using best practices; they tend to be hackers
- Provide reliable, sustainable help to their own teams. They are often specifically named by many persons across an enterprise who are in no way a part of their own reporting structures to “…just please look into this for us, please?”
↑ This is the antithesis of agile ↑
Heroes’ behaviors are encouraged by companies that are still using command and control management styles.
What We ARE Looking For in a Team Member
Instead, each member of an agile development team must be able to produce something of value to the team as well as something of value to the product. When a new dev team member does not have this minimal level of skill the other members of the development team must become a proxy for the new team member’s trainer or teacher. But having said that, we are all responsible for teaching one another in an agile world.
Consider, for example, the addition of a software specialist to an existing Scrum development team. Chances are pretty good that the new person will have some experience in at least one of these areas…
- UI/UX design
- Front end development
- Back end development
- Quality testing
- Automated testing
- Database engineering and/or administration
- DevOps-related systems engineering
- …etc; not intended to be a comprehensive list
Experience in any one of these areas will probably transfer readily to some aspect of the development required in the existing team. If so, the new team member will be able to participate, learn from, and teach back one or more skills.
What is of greatest importance, however, is that the new person have these qualities…
- A passion for learning
- A strong desire to work with a team; to help advance the team’s capabilities overall
- To learn from others
- To teach others, patiently
WHY? As members of the development team, we owe ourselves and one another the commitment, openness, courage, focus and respect required to bring our team “up” in skills, development capacity and improved communication. The qualities just listed support and extend these values.
So, how must the culture in your company change to encourage these behaviors?
I Thought We Were Talking About Skills, No?
Perhaps you’re wondering why we haven’t discussed specific development skills in this article. After all, members of a development team need to be able to plan and execute some essential duties beginning on Day 1 of their tenure on the team.
The reason is that you already know how to vet a potential colleague in terms of their development skills, tendencies, problem-solving techniques, etc.
But you’re definitely looking for signs of the skills of greatest importance, and good behaviors discussed above.
What’s Next?
We’ve covered rudimentary skills needed in development team members. Next we’ll discuss team composition and the relative value of ensuring that dev teams are cross-functional.
Thank You
I am grateful to Erin Quick-Laughlin of Hoonuit for his insights and excellent feedback on Scrum team dynamics and best practices.
