Managing Dedicated Scrum Teams: A Guide for Product Owners

A leader is always central to any culture of transformation. Agile development and Scrum teams are no exceptions. Today Agile, DevOps and Scrum are no longer just marketing buzzwords; these methodologies & approaches have proven their merit in reducing waste, quickening time-to-market and providing greater opportunities for customer feedback and improved collaboration.

As a product evangelist and scrum master, I have built digital products for over 15 years, and along this journey, I have witnessed Agile and Scrum growing from their modest beginnings to emerge best practices in IT projects. Having managed a variety of agile scrum teams ranging from 1 to 30 team members, co-located and distributed across multiple time zones, what I discern is that Agile and Scrum practices would prove the holy grail of continuous and efficient software delivery only when a leader is capable of creating adequately empowered, collaborative and self-organizing teams.

There is no silver bullet. There is no ‘one size fits all’.

In my opinion, there exists no particular style, which any effective manager would use as a standard yardstick. Instead, one should consider leveraging multiple styles and use the one that looks the best fit for a given situation. A real scrum master knows that following agile in true spirit is when you are willing to commit in a servant-leader format. This style is not about telling teams what to do and how to do things but about effectively removing roadblocks and impediments that obstruct efficiencies. Having said that, at times, you might be required to be authoritative nonetheless & lead from the front; whereas, at times, you may want to choose to be a disciplined follower. Succinctly put, one needs to act as a mentor and as a coach, ensuring proactive guidance and empowerment to teams to deliver their best.

As a true leader of a scrum team, you must have adequate emotional as well as intellectual agility, which helps navigate your team through choppy waters & turbulent phases.

If I am to delineate select best practices for digital managers to lead their own product development scrum teams, then it would comprise of the following 8 sequential steps:

# 1 CLARITY ON EVERYONE’S ROLE AND RESPONSIBILITIES

Although many organisations are embracing agile and scrum methodologies, I do remember coming across many stories of failure, where more often than not, it was the lack of role clarity as well as role conflicts that slowly led the project its way down the vicious spiral towards abysmal failure. It is therefore important for scrum masters or digital managers to act as people managers and not just as project managers. Needless to say, no two organisations are same and hence how each business adapts to specific roles when they embrace agile environment differs; this could feel very different from how the business and IT define these roles. Lack of clarity in roles and responsibilities, if not addressed at the right time, can often result in team members and stakeholders feeling frustrated, as they inadvertently end up stepping on each other’s toes. An effective remedy to avoid such a mess is to prepare a well-defined org chart, which provides adequate explanation of roles, accountabilities and specific ownership to each team member.

# 2 CULTIVATE THE CULTURE OF TRUST

Increased trust among coworkers / project stakeholders is the net outcome of scrum project and agile thinking. Taking a departure from traditional “plan and control” approach, scrum introduces a fresh and more pragmatic cultural mindset, where teams go on creating incremental value sprint after sprint. This also helps replace stereotypical review process with a more collaborative analysis what has been achieved collectively by the scrum team at the end of every sprint. The best part of forming scrum teams and agile projects is that everything is underpinned by the spirit of collaboration. Scrum teams are trained and expected to embody the values of commitment, courage, focus, transparency and respect, and this helps strengthen pillars of collaboration and adaptation, resulting in building of immense mutual trust and skills driven dependency among team members.

# 3 ENABLE TEAM MEMBERS TO EMBRACE FAILURE OPENLY

Failure is a lesson learned well for any organization and it holds true for any project, and scrum teams & agile projects are no exception. Yet, too many companies and leaders still get it wrong. There exists rigid views that believe lean transformation & agile projects can’t fail. I find it both amusing and rather naive. Failure has been debated and discussed as a valuable catalyst in fine-tuning strategies and thinking to deliver better success. And when it comes to scrum teams, people tend to place significant emphasis on innovation and experimentation, which may experience some hurdles and even a few failures. It is for a leader to see that failure should not dent the confidence of his or her scrum teams. Sometimes your team might be either falling behind in delivering certain KPIs or might suffer an unexpected failure. In such situations, one needs to rise more like a coach and a mentor. As a coach you should be directive, provide specific insights and actions for the team and individual team members. Among other alternatives, one should also consider restructuring teams and replacing or assigning team members to different duties. You should do enough to be seen and trusted as a mentor, so that your team members feel enabled to confide in you, and eventually this helps bring out the best out of them.

# 4 MAKE INDIVIDUALS ACCOUNTABLE FOR ACTIONS

This is not to be confused with confronting people with aggression. Beauty of scrum projects lies in the fact that it brings together silos of specific expertise. But many get stuck in siloed thinking instead. In the context of scrum projects, a leader must realize that while decentralization is important, integration of roles and accountability are also critical components. For example, successful attempts in digital transformations require that businesses must ensure that the IT department is looped in and held accountable for the delivery of sustainable, integrated outcomes that meet the company’s needs pertaining to time-to-market and agility. Let’s understand this with a more practical situation in a scrum project. Consider a scenario where you are expected to serve as a scrum master and tasked to develop a demanding web application. Now, the incumbent standard policy at your company is that development is to be done using a specific language, backend with another specific tool and content is to be managed using a specific web experience management solution. Your have a small yet motley team, with each member bringing unique expertise in his / her own domain.

For example:

1. Coders
2. Testers
3. UX Designer
4. Web Experience Management solution developer
5. Business Analyst

So, you have a cross-functional team, which is collectively capable to produce incremental and shippable sprints. But the sixty-four-thousand-dollar-question is, how do you ensure that your team doesn’t fall into the siloed thinking. The ‘UX guy’ will take care of UX design, the ‘coders’ will do front-end and backend and the ‘tester’ will do the testing. But, if the ‘UX guy’ can’t get his work done on time, it will impact the tasks that follow the UX work. And since team members can’t offer the required help to each other, it will cause further delays, issues and prolonged interruptions, eventually impacting the entire sprint. And this can unknowingly sabotage mutual trust too. Trust and accountability are two closely related concepts and remain mutually intertwined for the success of scrum teams. Defining clear accountabilities, fostering culture of learning and collaborative thinking is therefore instrumental in making agile projects truly agile.

I, therefore, recommend this as one of the first few things to be done by scrum masters. Rules become habits and habits develop a culture. Hence when forming a new team, it is very important to establish ground-rules for accountabilities from the very beginning. Some of the best practices e.g. unit testing, code commenting, TDD, etc needs to be enforced as unbreakable rules of accountabilities at the very start when the team is small. Once the team starts growing, these best practices will become the norm for the team and eventually the team culture.