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!

Importance of Story Time (GTSS) in Agile/Scrum

We all know that Scrum holds certain meetings very important for the process to function smoothly and efficiently. Primarily, the following meetings are essential for a Scrum team to be productive: -

1. Release Planning Meeting – done before a release (spanning multiple sprints) is put together
2. Sprint Planning Meeting – done before a sprint is put together
3. Daily Standup – done every day during the sprint to ensure the team is progressing and impediments are discovered and removed ASAP
4. Sprint Demo – done at the end of a sprint to showcase PBI (Product Backlog Increment) developed during the sprint
5. Sprint Retrospective – done at the end of a sprint so Scrum Team can talk about how the sprint went and inculcate adjustments to the Scrum process

These meetings are essential for the Scrum Team to operate smoothly, and they are, thus, recognized as fundamental to the process. Almost all Scrum teams are pretty good at following the above said meetings (with minor adjustments such as combining the Sprint Demo and Sprint Retrospective meetings).

In this blog, I want to talk about another Scrum meeting that is often ignored by a lot of Scrum Teams. This meeting is called Story Time; it is also called GTSS (Get The Story Straight).

The primary goal of this meeting is to allow the Scrum team to look ahead at stories in the product backlog slated for future work. In other words, this meeting does not entail discussion about stories on the current sprint. Instead, the focus is on looking at future stories. The GTSS meeting must be time-boxed (usually 1 hour every week) so that Scrum team can continue to have a primary focus on the current sprint. The mandatory participants in the GTSS are all active Scrum team participants; this includes Development Team (Software, UI/UX and Quality Engineering), Product Manager and Scrummaster.

The advantages of conducting a weekly GTSS meeting are manifold; I discuss the primary ones below.

1. Constant Product Backlog Grooming

GTSS forces Product Management to always stay on top of the Product Backlog. If I am a Product Manager, and I know I have to present future stories every week to the team, I will have to constantly groom the Product Backlog; this grooming would entail both arranging the stories in the Product Backlog in the correct business priority as well as providing at least high level elaboration in the stories targeted for immediate discussion.

2. Higher Quality User Stories

GTSS contributes to stories with higher quality. Similar to the argument presented above, user story quality tends to be higher if the team is constantly looking at stories much before a Release Planning or Sprint Planning meeting. Discussing stories early helps the team look at the story from various angles, thus contributing to more complete, robust and well thought out stories.

3. Efficient Release Planning and Sprint Planning Meetings

Release Planning and/or Sprint Planning meetings become shorter and efficient if GTSS meetings are happening. If the team looks at user stories for the first time ever in a Release Planning meeting, a lot of time gets spent in simply trying to understand the user story, and meetings drag on and become marathon sessions. In worst cases, teams can spend up to 2 weeks just doing Release Planning. On the other hand, if the team is already familiar with a user story, it is much easier and faster to discuss and estimate the same.

A great analogy to this is the 'sticker shock' paradigm. If you are a merchant, or eCommerce company, you do not want to show a price to your buyer(s) that will change dramatically at checkout time (after including fees, taxes and any other hidden charges). If you do so, you give the buyer a sticker shock, and chances are that you will lose the business.

Don't give your Scrum Team 'story shock'

Do not give your Scrum Team 'story shock'; show them stories early and do not surprise them when it matters!

5. Smaller wait periods between sprints and releases

Since GTSS meetings allow the Scrum team to constantly stay on top of the Product Backlog, they foster much more efficient Release Planning and Sprint Planning meetings. Teams that used to spend weeks on Release Planning, and were used to take 2-3 days breaks between Sprints soon realize that those wait periods are dramatically reduced if GTSS meetings are done every week. As an example, I have run multiple Scrum teams that efficiently execute back to back sprints without taking days off in-between sprints for marathon planning sessions.

6. Enhanced Team Collaboration and Communication

GTSS encourages numerous useful, informal conversations – Agile/Scrum is all about collaboration and communication. Apart from the standard Scrum meetings and ceremonies, bulk of the communication that a Scrum team does is informal. GTSS meetings encourage more informal communication and brainstorming. When the team looks ahead at future stories, lot of interesting hallway/kitchen conversations result; following are some real examples from my experience working with various teams: –

‘That new feature seems cool; we will enjoy building it.’

‘Ah, that story is architecturally significant, and may need us to collaborate more closely with the platform team.’

‘I was looking at our competitor’s site, and I am really happy to see we are taking feature X on in the near future.’

‘Oh that story will need some serious regression, we better start looking at some QA automation soon enough.’

‘This story can really revolutionize our UI strategy; can we ensure we investigate a new Javascript library during Sprint 0 for next release?’

You get the idea. Looking ahead at features generates excitement in the team, and makes people think ahead. It makes teams proactive versus reactive.

7. More Accurate User Story Estimates

As a direct consequence of the aforementioned point, estimates on stories tend to be much more accurate. Since the team gets the time to chew upon stories for much longer and gets to digest them, the chances of surprises occurring later reduce, which results in better, more accurate estimates.

8. More Engaged Team

If the team sees stories early, team members get to provide feedback on stories that may not be fully set in stone yet. This provides two highly desirable benefits - first, the overall quality of user stories continues to go up as more minds contribute to story elaboration, and second, higher team engagement. Team ownership goes up when the team feels and sees that their input makes a difference and is important.

Summary

Given these benefits, it would be hard for any Scrum team to overlook the importance of GTSS meetings and not reap the rewards of this useful process.

Before I finish, I will recap the GTSS meeting for quick reference using the famous Five Ws and One H style.

• What – Story Time, or GTSS (Get The Story Straight) meeting
• When – 1 hour per week
• Who – Scrum team
• Where – Anywhere suitable 
• Why – Constant Product Backlog Grooming
• How – Product Manager presents future stories and team discusses the same

In my mind, 1 hour week spent on GTSS affords Scrum Teams huge benefits that soon outweigh the time investment. I hope you find this useful reading and start benefiting from this very effective Scrum meeting in your projects!