Self-Organizing for Success

Owning the Work

In my previous article, I explored several areas of the Scrum framework I believe are important to achieve true “Agility” and better project outcomes.

Self-organizing / self-managing teams, however, I believe is worthy of its own discussion.

In the corporate world, many of us are simply assigned, directed or placed on a team or project. What project you are on is sometimes a simple math equation:

• Project Demand - Resource Capacity = Project Team Member Placement

This traditional way of assigning teams to projects is in contrast to what Agile methodologies recommend. Per the Scrum guide:

• “Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.”?

This is important when you consider one of the main theories of Scrum – adaption to changing project, stakeholder, and / or business environments. Again, from the Scrum Guide:?

• “Adaptation becomes more difficult when the people involved are not empowered or self-managing. A Scrum Team is expected to adapt the moment it learns anything new through inspection.”?

Practically speaking what does “self-managing” or “self-organizing” really mean? I like to define them as follows.

?Self-Organizing Teams Can:

• ?Request, add, and / or rotate members throughout the project
• Select members from the entire pool of resources best suited to accomplish the goals of the project - not just those immediately within the department

?Self-Managing Teams:

• Decides what tasks they’ll take on and what they’ll postpone (backlog)
• Determine and decide the pace they could realistically move at (their velocity)
• “Swarm” to get the work accomplished, regardless of title, rank, experience, etc.
• Create their own tasks and / or milestones they are trying to achieve vs. having them imposed upon them

In sum, a self-organizing team succeeds or fail in its goals, continuously looks at ways it could improve itself, and is fully in charge of how it accomplishes its work.

Why we would strive to grant such freedom to teams I cover in the next section.

When Ownership = Motivation

From the Agile Manifesto, points #5 and #11 are quite relevant:

• “The best architectures, requirements, and designs emerge from self-organizing teams.”
• “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

While entire articles could be written on these two brief sentences alone, I can briefly sum them up as follows:

• Self-organizing teams take full ownership of their work, usually leading to better project results

Essentially, if the team self-organizes and self-manages, it makes a commitment to itself that any work it takes on it will accomplish to the best of its ability.

If the team misses its mark, in most cases, it can’t blame an outside party as the team - not "someone else" - decided what it could accomplish.

In sum, self-organizing teams tend to be self-motivated teams.

Self-Organization and Needed Resources

One of the additional benefits of team self-organization is the ability to reduce the administrative burdens that typically go along with any project.

This may resonate well with anyone that’s worked on large projects for large organizations. When you need something now to be successful, having the right team members who knows how to navigate the system could mean the difference between making a milestone | deadline | commitment or not. For example:

1. Intake Processes: Paperwork + approval required to start new areas of work
2. Department Change Requests: may be in addition to project change requests
3. Resource Assignments: While you may know someone that could help on your project, it’s usually not as simple as just asking that person to come and support

Each organization + department + process is different. I invite you to think back to your last project and some of the processes could have been:

• (A) simplified or
• (B) expedited

If you had you could pull in the correct person then and there when you needed support.

A lot of times, it’s the project manager, that these tasks fall to, which depending upon how experienced (or available) they are to make that specific request(s) could mean the difference of getting those resources in time to meet a deadline or not.

While this sounds great, then why don’t more organizations allow teams to self-organize and self-manage? There are a lot of different factors I explore next.

When Self Organization Isn’t Possible

Some of main reasons teams are not allowed to self-organize and self-manage are as follows:

?Organizational:

1. A true Agile mindset hasn’t been fully adopted by the organization
2. The organization is heavily hierarchical, structured, and / or “command and control”
3. The organization itself is small, e.g. the same 5 resources work on 100% of the projects think startups companies or “startup departments”
4. Individual performance, as opposed to team performance, is rewarded
5. Management is adamant about being able to forecast enterprise wide initiatives
6. No bench strength, e.g. resources are assigned 100% capacity at near 100% of their time
7. Work is “siloed” as opposed to integrated, handoffs between roles is expected, e.g. developers make feature that passed off to QA to test

Mindsets:

1. Mistrust – teams that are self-managing will create their own rules and will ignore or deviate from standard operating procedures
2. Misunderstanding - of the Scrum framework and the concept of adaptation
3. Misconception - that the highest performing individuals will join team “A” and team “B” will be left with “everyone else”; team “A” projects succeed team “B” projects fail
4. While individuals team may succeed, this “can’t be replicated at scale”
5. Team members in large organizations used to having goals cascaded to them may not know how to succeed with such newfound freedom
6. In a similar vein, team members accustomed to being managed or having their tasks handed to them by traditional managers may not be able to come up with workable plans on their own

The lists could go on from here.

Sufficive to say, creating an environment where self-organizing teams can truly flourish is not easy but it is possible. For more information about the difficulties relating to self-organizing teams, this is a helpful article from PMI (Project Management Institute).

Given the above challenges, many organization have not yet reached the point that allows teams to self-organize / self-manage.

However, I believe as Project Leader – you can still create an environment which gives your team members ownership, authority, and sense of purpose over their own work.

Create a Sense of Purpose and Direction

I try to empower individuals to be master of their craft and teams to be owners of their work.

I believe it’s ineffective to take a group of highly talented and skilled individuals and steer their passion away from developing quality outcomes towards achieving unrealistic schedules.

I’ve found ways to create self-organization / self-management within my teams – even if dates are imposed upon us, milestones are created for us, and client obligations must be met.

How is this achieved? For me, it’s daily behaviors that embracing and encouraging an “agile mindset” even if we aren’t working in a 100% agile environment.

?A few practical examples:

• Vision: Fully briefing the team on the big picture of their involvement with this project – not just their individual parts within it.
• Adaption: Taking the lessons learned created from previous work and asking them to think how and where this applies on the current project.
• Eliminating Layered Conversations: When knowledge from outside the team is needed (e.g. business operations) I encourage free dialogue. I facilitate introductory calls as these are typically the hardest to setup for busy team members. I find out what recurring schedules that work and don’t work for each person - and then ensure direct conversation between the teams and other SMEs.
• 90-10 Rule: When conversation is needed within the team: 5% of my time is setting the stage and core concepts to be discussed, 5% is wrapping up what was discussed, 90% is spent active listening + encouraging team members to speak. (There may be some [or many moments] of awkward / uncomfortable silence if you are new to practicing this.)
• Resource Requests Anyone?: Ask often and frequently what resources (people, technology, knowledge, time, etc.) are needed to resolve the problem at hand.?
• Generate Options, Let Them Select: Ownership doesn’t mean the team will have the answer to every single problem. When I get the sense the team is stumped, I try to generate 3 to 4 well thought out courses of action that could be taken, propose it to them and let them select.
• “Room for Growth” Project Plans: One of the most successful tools I’ve found – building plans that allow for growth in what the team can and likely will discover along the way. This is worthy of its own consideration as many plans need to be baselined. (Baseline is not the same as “include every possible task.”)

While there is more I could describe, in sum, none of what I mention above are big and sweeping management process changes. Rather, they are a summation of small, everyday leadership behaviors that allow teams to feel empower to:

• Speak up
• Ask for what they need
• Discuss amongst themselves
• Take control of their work
• Bring in outside knowledge

?The Beat of Their Own Drum

In closing, there are a lot of different terms that are thrown out when roles and project timelines are discussed:

• ?Team can be “assigned” work
• Individuals can be “accountable” for work
• Managers can be “responsible” for outcomes
• Leaders are there to “direct” teams

However, “ownership” of the work is a term that I would like to see more of.

My experience is that empowering team members to “own” their section of the project plan, leads to more enthusiasm and dedication towards them completing it.

As project leader, I view part of my job as creating an environment where team members feel they can “self-direct.”?

I’ll set the stage of what needs to be accomplished and suggest reasonable courses of action to achieve that. When it comes to the specifics of “how” the work is going to be achieved that’s when I stop talking, start listening, and be there to support.

Small changes in leadership style can foster better discourse amongst team members to come up with ideas, solutions, and timelines they feel they own and are willing to standby.