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:
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.
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.
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.
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.
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.
I would like to reiterate that accountability is never the root-cause; trust and inclusion are key elements that help foster commitment and conviction. Granting adequate flexibility to decide the scrum squad is another decision that can catalyze great results with increased trust. On many occasions I have observed a dynamic relation between “how one works” and “with who one works”. Self-organizing scrum teams do tend to aspire for certain degree of autonomy in having the opportunity to choose how they get to work with. Sometimes it’s not about people with different skills working together but more about people with similar mindset collaborating for a shared goal.
While it important to establish a clear vision for goal settings, I have studied many cases where there is poor alignment between agile or scrum training or initiatives and annual objectives or appraisal metrics. These things need to be in tandem. And instead of following metrics that don’t add up, it is better to devise ways that encourage adding genuine influence and impact from each scrum team member. This can be achieved by setting district SMART parameters for teams as well as individuals alike, also ensuring they are constantly followed to track progress and to embed feedback in action. Each goal statement should have a simple yet clear corresponding performance dimension/measurement, with some extra guidance on potential weight age it should carry.
In addition, as a product manager, you would have your product related KPIs to report. Eventually, the success of the team hinges on the success of the product and hence these are the top-level KPIs the team should report on. However, the team should have their own team related KPIs too. These could be scrum related like i) team velocity ii) accuracy of estimations iii) sprint burndown iv) release burn-up, etc. Additionally, you can have culture related KPIs e.g. i) Team happiness index ii) Confidence (in product/company) Tracker iii) Team’s leader-board for any game (e.g. foosball, pool, etc) the team plays.
Celebrating every successful sprint has to be done religiously. Especially when your team’s resources are heavily burdened and going the extra mile, you need to do more as a coach. An overachieving and highly driven team needs bigger and better challenges. And when they exhibit tangible commitment and acumen to win such challenges, such accomplishments should be rewarded with fitting recognition, which may also include more challenging tasks. This helps boost team’s morale as they feel encouraged to deliver excellence. At the same time, think of having a retrospective conversation with your team at the end of every sprint. And when you do so, call attention to all of your milestones. Dedicate a few moments to bask in all of that glory — your team indeed deserves a pat on the back. You may find it necessary to draw attention to a list of items that warrant some fine-tuning or priority action, but also don’t forget to delve on the positive takeaways too. Share your thoughts on the things that worked well, and acknowledge your appreciation for anyone who helped along the way.
Simple as it sounds, this holds the real essence to build and leverage collaborative scrum approach. Feedback when discussed in the context of scrum teams and agile projects, is very different from the traditional concepts of quarterly or annual performance reviews, which are largely linked to static goals & compensation activities. In contrast, building self-organizing agile teams requires constant & uninterrupted feedback, which needs to be extremely focused & analytical. This helps connect dots and fill gaps. Moreover, how one structures his or her feedback also matters. Instead of being subtle, try coming up with more comprehensive and detailed feedback that offers useful information to address a specific problem area. So, choose the right tooling and the right approach to enable a more intuitive and simple to consume and simple to track feedback. Treat every feedback just like an Agile task and set performance goals with each feedback you intend to share. Lastly, don’t forget to act like an effective coach, and make an effort to objectively articulate the impact of past events or behavior and offer your opinion on how the situation could have been dealt with better.
Also, consider providing a safe environment where people with different traits can effectively practice sharing feedback. Encourage your team to practice role-playing sessions.
For my money, these pointers can help digital managers effectively manage their scrum teams. Think of it like a work in progress, but eventually you will get the hang of maximizing the potential of your scrum teams.