The Four Steps Towards Giving Up Control

 

In one of my previous short notes, I’ve mentioned the importance of autonomy and Agile 5^th principle “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done”

Giving Up control is the first step towards building autonomy. It is wise to extend freedom to your team, but it's not easy. The urge to control your people and team’s is irresistible and it echoes continuously to managers and leaders which effects the team morale continuously.  

Empathy and building autonomous team is not something which can be achieved overnight, especially when you have grown up in command and control, carrot and stick or an opaque environment. It is in-deed a journey and a conscious effort has to be made every day to build autonomous teams.

I am listing down few techniques, which I’ve used and has given me success in building autonomous team and give away the control.

Collaborative goal setting

An imposed goal, target or decision is unlikely to be believed and team merely executes that out of fear and most of the time they are not successful. These targets may be a quarterly sales target or a deadline of delivering a product/feature.

A considerable body of researches have shown that individuals are far more engaged and passionate when they are pursuing goals, they had a hand in creating.

So, get your employees and partners together on goal settings and get surprised, often people have higher aims or better alternatives.

Personally, I highly recommend the use of PI-planning in SAFe ( for collaborating goal settings and alignment of teams and management. Use noncontrolling language and pressure words.

Use noncontrolling language and pressure words

In my experience, uncountable times, I’ve heard and read emails at school or work which directed me to finish an activity by certain time or ASAP. You might have similar experience as well. Think about your true feeling at that point of time. Next time you are using pressure or controlling language (should, must, have to) consider using collaborative words with right intent. Anxiety and Anger are the common outcomes of a controlled team.

Some of the common pressure words used at workplaces are listed below:

·      I need this ASAP
·      We have to do this…
·      I need this by 11 am tomorrow morning
·      We’re counting on you to do this

Every time we have used similar sentences, we made our people stand on the edge, teams or individual feel more constricted irrespective of your intent and thus resulting in low morale of individuals.

Be approachable

I remember my school days when my teachers announce in the class that students are free to visit them in staff room at a specific hour of the day or week to clear any doubts we may have.

I’ve always enjoyed the out of classroom interaction with teachers/professors. We got an opportunity to learn both ways and shared a common understanding on subject.

Similarly, take a cue and have a fixed time slot reserved for employees, so they can walk-in and talk to you. You will be surprised to learn from your team.

Blame a process not person

When something goes wrong, people are punished. We often hear and read in news that a bureaucrat was transferred, or a politician has to resign because of a certain issue. Resulting in shame and low morale.
However, little efforts are made to improvise the process. This whole culture of blaming person restricts the culture of reporting gaps due to fear of being singled out.

Know where you stand

It is remarkable sometimes to conduct an autonomy audit in your team on Task, Time, Team and Technique, refer details on danpink.com and run an autonomy audit in your team, teams or organization.

Scrum Guide revision, Section by Section

Introduction

I bet, by now you know enough about the recent scum guide revision. It has taken us years to adopt to Scrum and some of us are still understanding the adoption process. The new scrum guide is more powerful and provides you more opportunity to derive value from it. Like SAFe, Scrum guide is relatively less perspective and focus is on whole team accountability.

The purpose of this article to highlight the changes on the scrum guide section by section, I'll leave with the readers to articulate the changes. I've attempted to make a section by section comparison on a high level. Please post a feed-back or highlight any changes which needs to be captured here.

Scrum Guides

You can download both versions of scrum from here https://www.scrumguides.org/download.html

How to read

For ease of reference, I have added snippets of 2017 and 2020 guide and color coded them. Here are the legends

Green – Unchanged text

Orange – New Mention

Red- Deleted

Left hand side has screenshot from 2017 guide and 2020 is on the right had side

 

Definition of Scrum

What continues

1.       The focus on scrum being light weight and simple is continued in 2020 scrum guide.

2.       The guide continues to state that it is purposefully in-complete and non-descriptive.

3.       The focus on relative efficacy is continued for the continued improvement.

What is dropped

Scrum 2017 guide mentions scrum as Difficult to master but this is dropped out from the new scrum guide in 2020.

New mention

This section calls out the role of Scrum Master, Product owner, Scrum team and              focus on inspect and adopt process

Uses of Scrum

 

What continues

This content and essence of this section are elaborated in other sections of 2020 guide like “Purpose of Scrum Guide” and “Scrum Team”.

What is dropped

Only the heading “Use of Scrum” is dropped but essence is maintained.

 

Scrum Theory

What continues

Empiricism, Scrum pillars of transparency, inspection, adaptation and iterative approach

What is dropped

Only the heading “Use of Scrum” is dropped but essence is maintained.

New mention

Scrum foundation includes lean thinking along with empiricism.

 

Transparency

What continues

Focus on common understanding and visibility in the processes.

New mention

1.       Emphasis is on increased value and reduced risk due to transparency. Decisions taken with low transparency result in lower value and increased risk.

2.       Due to introduction of Lean in scrum theory, relationship between transparency waste is highlighted.

Inspection

What continues

Continued the emphasis on frequent inspection.

What is dropped

The 2017 scrum guide focused on the (skilled inspector) actors who perform this activity.

New mention

Focus of execution of inspection process is left to the 5 Scrum events unlike an actor or skilled inspector unlike earlier guide.

 

Adaptation

What continues

The code of Adaption is continued and no major changes.

What is dropped

NA

New mention

Scrum guide focuses on Management 3.0 concepts like empowerment to team

 

Scrum Values

What continues

The core scrum values of commitment, courage, focus, openness and respect stay the same

What is dropped

The specific verbiage personal commitment is dropped, and team commitment is introduced.

New mention

Team commitment is emphasized to complete the sprint goal and team’s primary focus is highlighted which is to perform most progress towards sprint goal.

 

The Scrum Team

 

What continues

The structure of the scrum team and its’ attribute of self-organizing and cross functional continues.

New mention

The definition of scrum team is more specific, following details and attributes of scrum team is listed

1.       Size of scrum team and recommended size

2.       Scrum team responsibility for collaboration, verification, maintenance, operation, experimentation, research and development or anything else

3.       Highlighted the accountability characteristic with respect to creating value and useful increment.

 

 

 

The Product Owner

What continues

The overall attributes of the product owner continue and no major changes on the roles and responsibilities.

New mention

In new scrum guide the product owner become accountable rather than just be responsible. For example

1.       The Product Owner is now accountable for maximizing the value rather responsible.

2.       Similarly, product owner is accountable for the product backlog

 

 

The Development team

What continues

The focus on set of people who are committed to deliver values.

What is dropped

The term “The Development team” is replaced with “Developers”

New mention

Developers means the entire scrum team and not just people “who do the work of delivering a potentially releasable Increment of “Done””. The focus of the developers is not only responsible for work but being accountable as well.

 

Development team size

This section is dropped and moved to the Scrum team section of new guide

The Scrum Master

What continues

The scrum master continues to play role of coach to understand the scrum.

What is dropped

The teem “Servant-leader” for the scrum team

New mention

1.       Accountable for the outcomes rather than just responsible.

2.       True leaders for the scrum team and organization

The Scrum Master service to the product Owner

What continues

Accountability and Responsibility to-wards goal, scope, product backlog and empirical product planning.

What is dropped

1.       Facilitating Scrum events as requested or needed

2.       Understanding and practicing agility

New mention

1.       Facilitate stakeholder collaborations as requested or needed, rather facilitation of scrum events.

 

 

The Scrum Master service to the Development team

What continues

Coaching aspect to the team continues

What is dropped

1.       Coaching the development team in organizational environments in which scrum is not yet fully adopted and Understood.

2.       Facilitating scrum events.

New mention

1.       Ensuring scrum events have positivity, productive and productive

The Scrum Master service to the Organization

What continues

Leading, Coaching and planning aspects of scrum adoption and implantation of scrum in organization.

What is dropped

1.       Causing change that increases the productivity of the scrum team and

2.       Working with scum masters to increase the effectiveness of the application of scum in the organization

New mention

1.       Training and advising

2.       Remove barriers between stakeholders and Scrum Teams

Scrum Events

What continues

By and large details about Scrum Events continues with no noticeable changes other than verbiage and details.

 

The Sprint and Cancelling a Sprint

What continues

Sprint duration, goals and details in the sprints follow the previous guide.

What is dropped

New mention

1.       Specific mention of Product backlog being refined during the sprint.

2.       Cancelling the sprint is included in the Sprint section itself, and not calling out separately.

3.       Focus on use of various practices like burn-down and burn-ups.

Sprint Planning

What continues

1.       Collaborative work continues to plan the sprint.

2.       Sprint time-box is maximum eight hours.

What is dropped

1.       Scrum Master make sure that attendants understand the purpose.

2.       Scrum Master teaches the scrum team to timebox the event.

New mention

1.       Product Owner make sure attendants understand the purpose.

2.       The Scrum team may invite other people to attend the Sprint Planning to provide advice.

 

Sprint Planning (Continued…)

What continues

1.       What can be done this sprint?

2.       How will the chosen work get done?

New mention

1.       Why is this sprint valuable?

 

Sprint Goal

What is dropped

1.       This section is moved out and is embedded in product and sprint goal sections in new guide.

 

 

Daily Scrum

What continues

1.       Cadence and time box of 15 mins.

2.       Purpose and benefits of the Daily Scrum.

What is dropped

1.       Specification on following

a.       Examples of the question’s development team may answer.

b.       Development team meetings post daily scrum.

c.       Ensure the development team participate on daily scrum

d.       Training development team on Daily scrum

New mention

1.       If the Product owner and Scrum master are actively working on items in the Sprint Backlog, they participate as Developers.

2.       Developers can select whatever structure and technique they want, as long as their Daily scrum focuses on progress towards the Sprint Goal and produces an actionable plan for the next day of work.

Sprint Review

What continues

1.       Cadence and time box of maximum 4 hours for a one-month sprint.

2.       Purpose and benefits of the Sprint Review.

What is dropped

1.       Various low-level details around following topics are removed

a.       Development team responsibilities during the Sprint Review

b.       Product Owner and Scrum master responsibilities during the Review

c.       Topics which needs to be discussed (like budge, plan, etc)

New mention

1.       Purpose of the sprint review is called out specifically.  “The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations.”

Sprint Retrospective

What continues

1.       Cadence and time box of maximum 3 hours for a one-month sprint.

2.       Purpose and benefits of the Sprint Review. 

What is dropped

a.       Scrum team responsibilities.

b.       Scrum master responsibilities.

c.       Topics which needs to be discussed

New mention

Specific purpose is added “Sprint Retrospective is to plan ways to increase quality and effectiveness” rather then just calling out “ Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.  “

Sprint Artifacts

What continues

1.       Product Backlog.

2.       Sprint Backlog

3.       Increment

New mention

1.       Product Backlog, Commitment: Product goal

2.       Sprint Backlog, Commitment: Sprint goal

3.       Increment,  Commitment: Definition of Done

 

Artifact transparency

What is dropped

This section is dropped from new scrum guide.

 

Conclusion

There are quite a few changes on this guide, I will let you interpret the summary, by the way - if you google you will get to know various articles explaining these details.

The 5th Agile Principle, leaders must enable teams

            Build projects around motivated individuals.

    Give them the environment and support they need,

            and trust them to get the job done.

Think for a moment about Indian Cricket team, India won “One day International Cricket World Cup” twice – in 1983 under the captaincy of Kapil Dev and in 2011 following the captaincy of Mahendra Singh Dhoni. I bet no one told these winning teams: “To start practicing at a certain time of the day or to play shots using only a specific technique or focus on only an area”. The very idea is absurd.

In-fact, they were all motivated bunch of individuals and had freedom to execute the job in hand with utmost precision with autonomy. They truly represent a self-organizing team.

Leaders, captain, support staff and sponsors played a vital role in building the environment for winning team. Whether you’re fixing a car, learning to ride a bicycle or launching a satellite, Autonomy plays a vital role for all of us. Autonomy, Mastery and Trust explained by Daniel H. Pink, author of the book “Drive; the surprising truth about what motivates us” is closely knitted to Agile principles.

The 5^th Agile Principle is for leaders who must bring following attributes to the project environment:

1. Be available and approachable to resolve day to day impediments and celebrate success along with team.
2. Bring transparency in budgets, timelines, project road map and make it accessible for everyone visually.
3. Encourage culture of continuous constructive feedback, cheer conversations, advertise courage and care.
4. Develop deep understanding of business goals and objectives among teams and this "Shared understanding” ensure that teams heads in the same direction of common goals.
5. Provide tools and resources to boost team effectiveness.

Accountability during autonomy

For leaders, it is vital to not lose focus on element of accountability when we entrust team with autonomy. Per Motivation 2.0 “people by-pass responsibility when they have autonomy”, however Motivation 3.0 presume that people want to be accountable. Explained by Daniel H. Pink, author of the book “Drives”.

Too much freedom may result in chaos and it is a space leaders must avoid, and it is a continuous uphill struggle to strike a perfect balance especially in complex project environment, where execution of tasks by autonomous teams is challenged by the need to coordinate and align work with multiple experts, sponsors and other units in the organization.

Let’s look at three frameworks which provides appropriate eco-system to maintain autonomy among teams, we they all stick around together and utilizes the true power of Autonomy.

The 5^th Agile Principle “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

1. With-in Scrum framework, values of Commitment, Courage, Focus, Openness and Respect are catalyst to the Agile delivery model and bringing Autonomy, Mastery and Trust in complex project environments. The agile ceremonies especially Retrospective and Sprint Planning keeps up the morale and trust with-in the team.

2. In LeSS (Larg Scale Scrum), the problem of potential chaos by many autonomous teams is solved by having several teams work on the same backlog and avoid creation of multiple self-organizing teams.

3. In SAFe (Scaled Agile Framework), Business Owners create a boundary to the autonomy of the teams by determining the goals of product development and the event PI planning sets the right tone for team, everyone is involved in planning sessions not just Managers and Architects and sense of ownership is created.

Agile coaches and Scrum masters must be careful and understand the needs of different individuals on the team to create environment of creativity and high performance.

They can help team aligned to common goals by maintaining the required degree of autonomy and thus meeting the Agile 5th Principle.

Deriving a backlog for large projects

When executing a large project, that involves hundreds or thousands of people, it’s important to have a vision and a plan for achieving your project goals.

Before initiating a project, following are the essential artifacts which are vital before development team can be introduced.

1. A high-level vision of the end product includes

a. List of capabilities

b. Constraints

c. A set of targeted customer segments

d. Supported scenario or

e. Or an announcement on project end date to key stake holders or a date for major press release.

2. A high-level architecture, lists various components that interact to achieve product vision.

3. A high level schedule

High level schedule consists of milestones, these milestones can be further classified as Internal or External.

a. Internal Milestones are internal to project team and should have dates for key event like finalize user interface, internal stakeholder approvals, beta launch, etc. 

b. External Milestones are key event dates out side the project team, these external milestones could be press release date, conference announcement dates, etc. 

In-short, a high-level vision, architecture and schedule is important for project success, but it can not be overdone. Too much upfront planning tends to be a wasteful, since there are many unknowns and requirements often change.

Once you have initial high-level plan, development team need to know their contribution to the vision, architecture and schedule. This knowledge is essential to derive each team’s work backlog. 

Let’s look at architecture and vision to derive this information.

Here are two approaches to build backlog for each team, refer to figure as well.

• By Scenario, each team owns a different scenario described in the vision (such as book a flight ticket, auto upgrade preferred customers to business class )

The team creates components on need basis, the components get refactored by other team on need basis.

The scenario approach ensures complete end-to-end experience, but it may result in poorly engineered components constructed by too many hands.

Team’s backlog is derived by breaking down the team’s assigned scenario into individual features or stories

• By component, each individual team owns a component laid out in the architecture (such as build library, enhance performance, etc.).

The component approach provides clear boundaries for teams but may lead to in-complete end-to-end experiences. 

Team’s backlog is derived by breaking down the team’s assigned component into individual features or requirements.