Role of Managers in Agile

In today's competitive marketplace, organizations are under increasing pressure to continue to deliver value to key stakeholders that include shareholders, customers and employees - the value delivered to these stakeholders being, respectively, revenue and profits, great products and service, and happy and engaged employees. Numerous organizations are also adopting Agile and Scrum methodologies to deliver this value at a rapid pace.

In this post, I talk about some of the key ingredients that can make managers successful in an Agile environment, and therefore, help them become effective agents at creating value in multiple ways. People managers are in the middle of all the aforementioned stakeholders, and are the bridge between two very important parts of an organization - strategic thinkers or leaders and the teams responsible for execution and delivering results at the grassroots levels. 

I think there are four key areas that managers can heavily influence in driving successful teams, and thereby generate value. Below, I enumerate these in no particular order or importance.

Uphold and foster Agile principles

• Help Agile understanding
• Help streamline Agile ceremonies (go to at least 1 standup/week per project, attend demos, don't miss out on sprint retrospectives if invited by Scrum team)
• Believe in team empowerment
• Do not second guess team decisions
• Assist in impediment removal, especially in relation to other teams that the Scrum team works with

Evangelize and socialize

• Uphold, evangelize and spread the word about Agile best practices
• Include multiple audiences – vertical (both up and down) and horizontal (peers in same department as well as cross-functional and cross-stream)
• Share success stories to improve organization wide Agile adoption

Believe in and live by good behaviors

• Understand
• Encourage and Enthuse
• Assist
• Resist process destroying behaviors and actions
• Empower
• Believe
• Mentor
• Respect and have compassion

Train, coach and mentor

• Consider becoming a Certified Scrum Master
• Encourage senior team members to become Certified Scrum Developer/Master/Professional
• Encourage everyone in the team to get Agile fundamentals training
• Proactively coach and mentor team on good Agile principles

Managers who focus on the above areas are bound to successful in managing Agile teams.       

Be a ScrumMaster

I also feel that a manager should be a ScrumMaster for a project, at least for some time (a few sprints or couple of releases). Some believe that this is not a good idea as there could be a clash of interest; a manager may potentially push the team too much and take away team empowerment and autonomy in some way. My take on this is different. A manager who does not effectively understand Agile is likely to cause disruption in an Agile SDLC anyways, irrespective of where he or she is a ScrumMaster or not. On the other hand, being a ScrumMaster makes a manager more aware of how they can help Agile teams. It is a great exercise that can help managers become better as they get to live what a Scrum team lives every day and see how they can play their manager role more effectively in creating a more robust Agile culture. For obvious reasons, it is important that the manager put away his or her manager hat when they put their ScrumMaster hat on.

To summarize, I believe that managers, being in the midst of action and connecting everyone together, are uniquely placed to play a very important role in driving success in Agile organizations. Successful Agile managers take their teams to new levels of achievement and fulfillment; in the process, they create happy employees that deliver better products and services.

Agile Misconceptions

Everyone is doing Agile these days. Everyone. Not everyone understands the philosophy of Agile though. I come across many teams who profess that they are doing Agile, but some inspection often reveals that they are far from Agile, either philosophically, or operationally, or both. 

In this post, I want to share some of the popular misconceptions I see prevalent amongst the community that thinks they are Agile adherents, but in reality are not. These are in no particular order.

"If you are doing a daily standup, you are doing Agile"

Whilst a standup is an essential part of an Agile/Scrum framework, just doing a daily standup does not constitute following an Agile approach. Teams that do not follow the principles of team ownership, enhanced collaboration, pair programming, continuous integration, releasing a potentially shippable product every sprint etc, but do a daily standup religiously are far from being Agile. In fact, all the core essentials of an Agile framework are far more necessary than just the ceremonies themselves - as an example, some teams choose to skip standups, for instance, on Fridays.

"Agile means no design"

This one particularly pains me (yes I am a technologist). I come across this a lot. Some people assume that doing Agile means not doing any design. Software without design results in accidental architecture, which, as we all know, leads to brittle codebase that is hard to maintain and hard to grow. Of course we do not want to produce reams of documentation as part of our design documents, but 0 design is just not the right way to do software.

"Agile means no documentation"

Agile needs documentation. Not as much as waterfall, but without documenting anything, communication suffers and decision making loses focus. Agile teams should invest in diagrams and flowcharts et al versus too much verbiage. A picture is worth a thousand words, and is easy (and more fun) to grow and change as requirements and software evolve. No or desperately minimal documentation leaves too much to imagination, and since we all imagine differently, chaotic results often ensue.

"Adding resources will always increase velocity"

This misconception can often be high on the management favorite list. Throwing more bodies on a task is not a guarantee of faster execution. Good Agile teams go through a hardening process whereby team synergy and strong teamwork develop over time. They win together, and lose together. A high degree of synergistic maturity develops as team members build trust in each other, back each other up and support common team goals more than their personal goals. Addition of new members to established Agile teams will almost always result in decreased velocity for some time as team dynamics change, and the team needs to go through an adjustment phase. Not to say that training, personality or philosophy differences etc can also contribute towards a longer than expected adaptation period.

"A team with higher velocity is better than a team with a lower velocity"

Velocity is personal to a team. One team's velocity cannot be compared to that of another. The fundamental reason for this is that different teams estimate work differently. What is important is that a team use a consistently understood baseline or reference model in their estimation. Baselines for different teams are bound to be different, and hence their velocities will naturally be different as well. It is usually management that does not fully understand Agile that succumbs to inter-team velocity comparison to deduce relative team performance. A team's velocity should only be compared to its own from the past, and not to velocities of other teams.

"High Level Estimates need to be as accurate as possible"

Organizations that miss the core philosophy of Agile display belief in this one. Estimation is what the word means - estimation. It is not a promise or a guarantee of delivery. It is purely a tool to plan and start work. Once work starts, Agile teams more often than not learn new things which change their original estimates. What is important is that the team continues to become more and more productive as team synergy increases. Charting dates based on estimates that cannot be 100% accurate is a sure recipe for disaster.

"Agile involves no planning"

Many believe that Agile involves fast action without planning. Almost everyone used to do waterfall before they came over to Agile. People who felt burnt with extensive planning and documentation felt they could get away without any of those activities. Agile teams plan. The key difference is plan the verb versus plan the noun. Agile team "do plan" instead of following "the plan". In fact, Agile teams plan every day - course correction at daily standups being the most granular form of daily planning.

Stay away from these Agile misunderstandings and misconceptions, and power your Agile teams to hyperproductivity and success!