When will my agile team self-organize?

Great! Your business has decided to move from a Waterfall paradigm to Agile Scrum and now you’re waiting patiently for the benefits to kick in. You’re hoping your Scrum teams start self-organizing soon and are inventively solving customer problems faster with better efficiently. You’re also waiting for the team to become major contributors to the business decision process based on their intimate knowledge of customers and their pains. And you’re waiting … Still waiting …

You ask yourself what’s holding the team back. The Scrum Master has trained the development team on the agile manifesto including the principle:

“The best architectures, requirements, and designs emerge from self-organizing teams.”

The Scrum Master has also trained the development team on self-organizing as described in the Scrum Guide:

  • defining the Scrum Team: “The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. … The team model in Scrum is designed to optimize flexibility, creativity, and productivity.”
  • defining the Development Team role: “Development Teams are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness.”
  • defining the Scrum Master role: “The Scrum Master serves the Development Team in several ways, including: Coaching the Development Team in self-organization and cross-functionality.”
  • defining the Sprint Planning Meeting: “The Development Team self-organizes to undertake the work in the Sprint Backlog, both during the Sprint Planning Meeting and as needed throughout the Sprint…By the end of the Sprint Planning meeting, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment.”
  • defining the Daily Scrum: “Every day, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work together as a self-organizing team to accomplish the goal and create the anticipated increment in the remainder of the Sprint.”

It’s clear the Scrum Guide expects the Scrum team, and more specifically, the development team, be a self-organizing body. It’s also clear that training people that they should be self-organizing isn’t always enough. The organization must want and the businesses actively support the team becoming self-organizing.

Setting Expectations

Getting a Scrum team to self-organizing is hard primarily due to the fuzzy nature of what ‘self-organizing’ actually means. If you were to ask 5 people to define what a ‘self-organizing’ software team is you’ll probably get 5 different answers. But even in that result some truths are seen, it’s not how I define self-organization, it’s how the team defines it.

In Nitin Mittal’s Scrum Alliance article, “Self-Organizing Teams: What and How“, he describes 5 essentials of self-organizing teams:

  • Competency: Individuals need to be competent for the job at hand. This will result in confidence in their work and will eliminate the need for direction from above.
  • Collaboration: They should work as a team rather than as a group of individuals. Teamwork is encouraged.
  • Motivation: Team motivation is the key to success. Team members should be focused and interested in their work.
  • Trust and respect: Team members trust and respect each other. They believe in collective code ownership and are ready to go the extra mile to help each other resolve issues.
  • Continuity: The team should be together for a reasonable duration; changing its composition every now and then doesn’t help. Continuity is essential for the team.

I was once Scrum Master to a team during which I did training on the advantages of setting priorities, of sharing work, and of getting stuff done. The team was very good at their jobs and helped each other out whenever asked. However, I didn’t realize helping out had a limit until one day at the daily standup when the person working the most important story, the highest priority story, was out. I asked who could pick up the work to move it forward? No one raised their hand. One of the quietest people then said it was massively inefficient to have someone else pick up the work. For me personally this was a sad, sad day. After talking priorities, talking of sharing work, talking of getting stuff done, and talking how the team best works together, the team couldn’t let go of their own personal task responsibilities. The team couldn’t find it in themselves to embrace a team responsibility of getting the most important work done first. A self-organizing team would have kicked into a self-managing mode and re-allocated work so the highest valued work could continue. At the end of the standup, team members felt a stronger bond to their own work in areas they were most comfortable with than to the whole. It wasn’t competency but rather motivation that was holding the team back.

What makes it so hard to motivate a team to feel responsible for the whole? When a business pushes individual roles & responsibilities over team commitments or when survival and blame permeates an environment, it’s very unlikely that the team will move beyond the ‘forming’ stage (team members sticking to what they know best individually and doing what they feel most comfortable with).

In some business environments, the dip in productivity while transitioning from ‘Forming’ to ‘Storming’ is unacceptable. This would be especially true in a strong hierarchical or Command & Control environment where those in the hierarchy are held responsible (accountable) for team performance.  If the business is clinging too tightly to a hierarchical and Command & Control environment, the likelihood of birthing self-organizing teams is diminished. At one company I was at, one of the most senior software engineers was a team lead. The team was always seeking his approval for any decisions and if the manager thought otherwise, the team changed their ideas to conform. This wasn’t the worse thing to happen but it was heavily reliant on the team lead always being right. A consequence of this was lower scores on the company’s engagement evaluations especially around empowerment and feelings of trust.

It’s worth the attempt

Adopting Agile and Scrum will not automatically cause people or businesses to change. For Agile and Scrum to make a positive impact, people will need to see that they need to change their own behavior. It’s possible to see that in an environment where individual knowledge or individual skills are the most sought after commodity, Agile may not be the right tool. In a business where rigid hierarchies and Command & Control are dominate, it may be a long journey to establishing self-organizing teams but certainly worth the effort.

David Ticoll in his Harvard Business Review article, “Get Self-Organized”, states that, “It would be difficult and risky—even foolhardy—to try to wholly transform a hierarchical business model into a self-organizing one. But the potential of self-organizing systems to enhance competitiveness is becoming clear to managers of some conventionally structured businesses.”

David Tricoll further states, “Today, the ability to stream complex, real-time information to the front line gives hierarchical companies greater power than ever to exploit self-organization.”

One approach might be getting the team to participate in business events such as creating business plans, working with customers and users, and respecting them as contributors to business success. Teams with greater insights to business and customer problems are more likely to be engaged with solving these. To be quick and competitive, businesses must relinquish control to the teams in the front lines and the teams must be willing to accept the responsibility. When the business leaders and development teams shared these insights, I’ve seen the development teams rise beyond their own specialties to rally around both the customer and the business.

For a team to become self-organizing, it will take more than a business to want and support it, it requires the team itself to see advantages in self-organization. If you’ve ever seen how an assembly line worked in days gone by, you’ll see an environment where self-organization would have been detrimental. Your job was to put nut ‘A’ onto bolt ‘B’ period. Repeat this for 8 hours a day, 5 days a week and you got paid pretty well for what to some people would be the most boring job on earth. The business wasn’t holding out hope that the workers would self-organize and the workers had no motivation to do so. In the factories, piecework was common. Workers were told what to do, how to do it, and when to do it. Software development is not piecework, if it were, robots would be doing it today. It is knowledge work where thinking both inside and outside the box are assets to the business.

In the situation above when a team member is absent, the moment the remaining team members decided that doing and completing individual tasks is more important, all advantages of self-organization were lost. Instead of adding value for the customer and business, the team had elected to follow a plan. The decision essentially comes down to: I have my own work to do and don’t have time to do yours.

To some, this kind of dedication is how you advance in the company. However, if the company were to emphasize customer and business value of work being done, it would cause a fundamental shift in team thinking, from doing tasks to getting the highest value work done quickly. When the business puts emphasis on value, the team is more likely to devote their combined efforts to achieving value. It would come to pass that even when one of their numbers is absent, progress won’t stop, although it may slow down. If the team is accepted as a fully participating business team member, not just a partner, the team will genuinely feel the success of the business is also their own success and act accordingly.

To me, one of the principle tenets of Agile is the team. The great power of Agile comes from a group of intelligent people working as one. Collectively they are more knowledgeable than any one individual although the shared experience may be less. To ignite the team requires the business to openly give the team responsibility and accountability for the outcomes of each iteration. For the business to move forward and empowering the team, they would need to establish safe boundaries from which the team can safely operate in.

When business leaders, product owners, and scrum masters attend the daily standup, what’s more important than hearing team members say,

I completed task <x> yesterday”,

is hearing them say,

we added <some> value to the product yesterday”.

The role of managers and customers on the self-organizing team

In an InfoQ interview, Rashina Hoda cites two environmental factors needed to be in place to enable self-organization to emerge. These are:

  1. Senior management at the teams’ organization must be able to provide freedom to the teams so that they can self-organize themselves.
  2. Customers must support the teams by being actively involved in the development process through providing regular requirements, clarifications, and feedback as required.

“Self-organizing Agile teams … require organization structures that are informal in practice, where the boundaries of hierarchy do not prohibit free flow of information and feedback. In an informal organizational structure, the senior management is directly accessible by all employees (maintaining an ‘opendoors’ policy), and accepts feedback—both positive and negative.”

– from “Supporting Self-Organizing Agile Teams What’s Senior Management Got To Do With It?” by Rashina Hoda, James Noble, and Stuart Marshall


For the business leaders, giving development teams insights to both business and customers plus giving development teams space to operate, will motivate teams to accomplish amazing things. When the business states these are our goals and asks the team to solve it in the best manner possible, you’re likely to see a team self-organize to meet the goals. No one goes to work hoping they fail.

When the business has a strong hierarchical and Command & Control environment, moving a team toward self-organizing is made more difficult but not impossible. Building a bridge of trust and respect is essential. By establishing a strong partnership between the business and development team, followed by full membership, the team can exercise their collective knowledge and capabilities to contribute to business successes.

In the end, it’s a mutual effort on the part of both management and the development team to become self-organized. It will probably be a bumpy ride along the way but with a clear goal as a guide, both should arrive at the destination together.




Make Agile User Stories Personal With Personas

Feature image “Proto-Persona” by visual.ch (CC BY-SA 2.0)

When a product owner or product manager helps create user stories with the development team, does the development team walk away feeling empathy for the customer? Can the development team and business benefit if the team ‘feels’ for the customer? Most businesses are pushing their development teams to produce all the time, from project to project, so developers eventually get used to this pressure and find their own behavioral niche within the organization. So why would a team suddenly begin doing more work in less time than any project before?

At a previous company, we had the advantage of being able to know the names of our customers and potential customers. This didn’t always happen but when the development team knew a customer’s name it was magical. During the daily stand-ups, the development team talked about the next bit of work they’d tackle but they’d also talked about the customer, “Is that what Bill (not the real name) wants us to do?” Management also talked in terms of the customer when speaking to developers. The development team knew their stuff and were top developers but they looked at the work with an eye equally on their customer’s wants and needs. The team spoke the customer’s name so it was clear they knew exactly who they were working for. The team’s productivity shot way up and they even worked weekends to get the right product into “Bill’s” hands sooner. This was a dream team for the business and would be the envy of most companies doing Agile. Or Waterfall.

Now that’s a nice, feel good story about a development team’s awareness of their customer but this is probably the exception. E-commerce businesses flourish these days with thousand upon thousands of customers so it would be difficult if not impossible to get a development team rallying around a single customer. The next best thing is a persona representing a customer, a customer segment, or a user profile. I first learned about personas from Alan Cooper in his book, “The Inmates Are Running the Asylum”. At the time we might have missed the mark sometimes because our personas were very detailed in things that nowadays would be considered unnecessary and less helpful in aiding product decisions. However, personas can help development teams feel a closeness to their customers and be more empathetic towards their customer’s pain.

What I generally notice is companies have personas but they’re often used only in Marketing. The idea is to get these personas out to everyone involved in product development and steering the full product team’s thinking towards personas as real people. I was at a great presentation by Atlassian product manager Sherif Mansour who spoke at Agile Australia a couple of years ago on the topic, “Do Agile Right – Lessons Learned From an Atlassian Product Manager“. This easy to listen to video touches a bit on using personas and journey lines. Atlassian uses personas as the backbone of their product development. If you’d like more information on creating personas, see the end of this article.

User stories by Mike Cohn

Connextra is credited with the most popular user story format, “As a <blank> I want <blank> so that <blank>“. This is a simple yet elegant way to capture “who”, “What”, and “Why” for a software requirement. But it’s Mike Cohn and his book, “User Stories Applied“, that really made user stories come alive in the Agile community. Mike Cohn does suggest that the ‘why’ is optional but I think for teams early in their Agile journey, this will be very beneficial as it helps new Agile teams understand the customers’ problems better.

A good user story can provide an innovative and imaginative development team all the necessary information to begin their task of talking with stakeholders and the product manager in order to figure out how they’ll do the work. The goal of the user story is to provoke conversations to get more details rather than writing a specification.

So does this happen and if it does, how often? My experience shows this in fact rarely happens. Yes we write user stories using the format, “As a <blank> I want <blank> so that <blank>”, but we’re really following a cargo cult software engineering ritual without really understanding the purpose of the user story. This is exactly where personalizing the user story can reap great benefits.

Personas in user stories

A lot of user stories I see look like this:

“As a user I need to see an error count so I can track whether the number of errors exceeds my reporting threshold.”

This story was constructed for the “user”. Unfortunately “user” is such a general term doesn’t tell us who the story is for; is the story for an 8-year old or 80-year old grandmother? Is the story for men or women? It’s going to be hard for someone to read the story and be empathetic toward the “user”. There’s no human connection to this story so no one should expect much in the way of human feeling toward implementing the story. The development team is just as likely create a display item that shows a simple error count because that’s the easiest and fastest way but is it the best way or is it what the customer really wants? What’s missing is the personalizing of the story which can be expressed in the form of a persona. By personalizing the user story, the question the developer asks is, “is this what ‘Grandma’ wants?” instead of, “does this meet the acceptance criteria?”. If the whole product team, (finance, marketing, sales, support, development, and product management), are behind helping Grandma out, it’s just that much more likely to happen.

Personas and visibility

Now someone reading this is saying, “but we said who the user was at the grooming session” and that’s great but now you have a story that only a small handful of people knowing who the story is for. This shows a certain complacency within the agile team and not being transparent to the business. By avoiding tying the story to a specific business concern in the form of persona, other parts of the business are in the dark as to the real value provided to the business by delivering this story. How easy would it have been to put in persona “grandma” instead of “user”? The Product Owner and Development team owe the business this insight and should always be aware of what they’re communicating to the business. If the agile team is looking for autonomy and empowerment, what better way to earn this than by being open and showing they are striking at the heart of business concerns.


The real advantage of personas will come from the development team as they create solutions in quick and caring way. Even if the development team only increases value delivered by a couple of percentage points, the product manager, the business, and the customer win. This can happen if the development team’s interest, excitement and commitment can be inspired by using personas. Atlassian treats their personas as people and the company talks about their personas as real people. This is not too far from the experience I spoke of earlier in this piece where the team talked about their customer.

There are as many styles of personas as there are customers. If you link a user story to a specific persona and that persona maps to a business or customer segment, then it will be easy for the business leaders to quickly see the potential value the team is planning to deliver. It also gives the development team a chance to relate their work to the goals of customers represented by personas.

Learning more

I am assuming most people reading this are familiar with creating personas but for those less familiar, here’s a site to get you started with personas.  There’s also help from Roman Pichler who, in his article “From Personas to User Stories“, provides a template for developing personas. An example of Roman’s persona template is shown below. Roman suggests that personas and their goals begin their appearance in the larger, epic, user stories and flow all the way to sprint ready stories. This will help focus the team on solving problems for a semi-living customer and it will also make user testing easier because the goals of that customer are defined in the persona.



A Development Team’s Agile Journey

If you’re working in a Scrum software house, ideal development teams are self-organizing, empowered to make decisions, and engaged as a full partner in the business as it relates to the product. But what are the essential first steps that will begin the development team’s Agile journey to get there?

We’ll take a quick look here at some steps I think are necessary for that journey to occur:

  • The business gives the team space to make decisions by defining the boundaries
  • The business empowers the team to make decisions within these boundaries
  • The team actively takes on the responsibility for all work by building skills within the team
  • The Scrum Master, team lead, and managers help the development team by practicing behaviors they wish the development team to adopt

The challenge

When a Scrum team first forms, it’s built from the remnants of the previous methodology, usually Waterfall. This is fine because the team starts off knowing something about the product and code. Still, a freshly hired team might have the advantage of not having preconceived ideas about their roles, responsibilities, and teammates. This sets up a change issue that needs to be overcome during the development team’s transformation to Agile: reset the thinking team members have about roles, limitations, and responsibilities. If possible, the Scrum Master tries to reset the development team so they start their Agile journey knowing their specialties and interests but without any other preconceived ideas of roles or responsibilities. Resetting and changing team member views of roles will be challenging but not impossible. Maybe.

When I was introducing Scrum to a team, I had a problem with getting everyone on the team to contribute to the testing effort during their very first ever sprint. The developers had always done code & unit test but they were never asked to do acceptance and system level testing, that is, until Scrum showed up. The situation arose when the single professional tester on the team became overwhelmed with writing and running tests. The developers were sympathetic but their only advice was for the company to hire more testers. The team lacked imagination and work experiences to even entertain solving the problem themselves.

Instead of listing out options from simple to hard, they fell back on their past experiences and decided that the way to solve the problem, the way they’ve seen it done in the past, was to throw bodies at it. For the developers, the simplest solution was to make it someone else’s problem, In this case, the managers needed to hire more talent. This had been a learned reaction by the developers over the years doing Waterfall and you couldn’t fault them too much.

There’s a high likelihood that while the developers were under the Waterfall umbrella, their work was specialized. It’s also likely the project manager’s task assignments in the project plan was based on these specialties. For example, a back-end developer would probably not be asked to do front-end display work and no developers would be asked to write the system level tests when there was a perfectly good team of QA testers available. The idea of development team members knowing one thing super well and to continue perfecting that one thing, is pounded into them from the first day.

With the Scrum development team, we still celebrate each team members’ special skills, the skills that made them valuable to the company in the first place. These skills will continue to be valuable when adopting an Agile mindset. So there’s really two things we want to change in the development team:

  1. Get the team to feel that development and delivery problems are theirs to solve even when it requires work outside your strengths and
  2. Develop stronger team thinking skills for problem resolution.

And the way to change how development thinks starts with management.

Management support of Scrum means tough love

Getting the team to acknowledge that our test situation was their problem to solve took a bit of time but they eventually did accept it. That there was a problem was obvious and this was not in dispute. We needed to get the development team to see that the old way of dealing with this kind of problem wasn’t an option. The journey’s first step was begun by senior management.

I was lucky that the General Managers of Development and Product were supportive of Agile and Scrum. Both these managers told the developers that there was no chance to hire and train new testers for the team given the delivery date. This was brilliant in that they didn’t simply say “solve it yourself” but gave the developers a real constraint that required the team to find an alternative.

The Scrum Master and Team Lead needed to lead change by example

The next thing was the development team needed a slight nudge in the right direction. This was done by myself as Scrum Master and by the team lead. Together we both began doing some testing tasks. We provided by example, a way forward for the team. This setup everything for the next step.

Get the team to be involved with a passive approach: get volunteers

At the next daily stand-up, we both gave our accomplishments from the previous day but asked for help from the remaining team members. As with any good group of people, when they’re asked for their help they provided it. Our team sat down after the daily stand-up and took on all the outstanding testing tasks. The reality was that testing didn’t take too much time, a day or so, and the value of finding problems during the sprint meant we could provide a higher quality product at the end of the sprint.

Behavior change starts with how we think

Positive team thinking usually starts with the confidence that the development team can solve their own problems. This means that the team must be empowered to solve a problem and feel confident that they have the necessary tools and skills to solve it. Building these two attributes won’t happen overnight. Making a strong deliberate effort to achieve both makes good business sense, especially if you think about the reduction of waste and a newfound enlightenment of the team.

One goal of Scrum is to harness the power of the team to make quick and better decisions. One foundation for this is the team’s confidence in itself to make decisions without relying on outsiders too much. This means the team working together to make choices on architecture, design, and implementation based on their collective product knowledge and within boundaries set by management. Fear usually exists and swirls around things we don’t know about. We are reluctant to make decisions while in the dark about a subject (most of us anyway). To build this decision-making capacity we start with building team knowledge so we can leverage the cumulative power of the team.

Team empowerment

Before the team can become self-organizing, they must first be and feel empowered.

We’ve all worked in offices where the business declared teams are empowered but this lofty claim does not jive with reality. Should you expect the company to say, “do what you want, when you want to do it”? No, of course not. What the Scrum Master or Agile Project Manager need to do is get the business to establish boundaries from which the development team can operate. Give the development team some space to operate independently in.

I’ve recently worked closely with a manager to help him move from the company’s Command & Control model to following a Servant Leadership model. I used two tools, a camera for filming his interactions with the team and listening to the conversations he had. Using these two tools, I was able to show him how he made most of the decisions, big and small, for the team. He hadn’t realized how often he was making decisions, he believed the team made the majority of the decisions. But the camera doesn’t lie. To change this around and give the team decision-making power, he followed the practice of pushing decisions to those who had the necessary information to make it. In this case, the development team. He followed the “intent based leadership” style of David Marquet, author of “Turn the Ship Around!: A True Story of Turning Followers into Leaders“. When a team member discussed options or choices with him, he recognized that they were actually asking him for direction. He found that he could answer most questions with, “what do you think?” This got the desired effect of team members now talking among themselves to discover the best way forward.

Establish boundaries for the team

In management’s role of supporting Scrum, they pass to the Scrum team business rules and establish boundaries for teams to work within. Part of empowering the team includes whatever limits the business feels comfortable with. In general, a Scrum team is given a free hand to build a product that solves the business or customer problem. However, there might be business or technical restraints, (non-functional requirements), placed on the team. For example, the Scrum team can’t arbitrarily decide to stop supporting a certain web browser because they don’t like it. It’s possible the company will go crazy with rules and restrictions but this should be balanced by having the team and managers drawing up the boundaries together. This is how our Servant Leader above created boundaries with his team to great effect.

Team strengths & weaknesses

It is sometimes thought that Agile development team members strive to become generalist but this is a false goal. It is not about everyone on the team learning how to do everyone else’s job but it is about everyone on the team feeling equally responsible for getting all the work required done, even if it isn’t your specialty. A good team acknowledges their individual strengths and plays to their strengths. While playing to the team’s strengths, a weakness might be uncovered. For example, if only one person on the team can code in Ruby, the potential weakness in the team is when Ruby work is required but the one person who knows it is sick or otherwise not available. In the past, the absence of one person could lead management to acquire another Ruby programmer from a lower priority project or, more likely, Ruby work would be postponed until the right person is back.

The Scrum Master can use a portion of the team’s retrospective to bring to light any shortcoming of skills or control noticed during the sprint. The team can together develop the appropriate actions to make this weakness go away or at least mitigate it.

Reduce waste by reducing hand-offs: Building T-Skills to make work-flow more fluid

When the development team worked within the hierarchy of a Waterfall environment, their job was to get tasks done as quick as possible. Once the unit tests passed, they would release the code to the test team. However, if you were to apply Value Stream Mapping techniques, you’d almost certainly discover that there are many zero or non-value adding periods within the Waterfall lifecycle. This would be most evident in the hand-offs between specialized teams. In an Agile team, these hand-offs can still occur: when the teams’ work moves from one specialist to another, when decision points are reached and the team cannot independently make the decision, or when one person has a particular skill and the team waits for that person’s availability. The solution is for the team to improve their ‘T-Skills‘. This will probably ruffle some people because their own sense of self-worth might be centered on a unique skill they alone have.  Here’s where the Scrum Master works their magic.

Building ‘T-Skills‘ means we don’t slight or forget the person’s key skill (the vertical line of the T). The goal is to create the capacity of having a second opinion when necessary and to still move work forward without the specialist. We want the team to have enough skills to step in and do the work if needed, even if it takes 3 times longer (the horizontal line of the T). The point is that work does not stop; it might slow down but it doesn’t stop. To build T-Skills will require a skills matrix.

The team goes through all the skills within the team and answers yes or no the these three questions for each skill:

  1. I am an expert
  2. I want to learn more
  3. I’m not interested

If you use a skills matrix similar to the example above, there is probably a need to address any skill that does have two or more people rated at 3 or above. When I’ve done this in the past as Scrum Master, I would arrange for any external training or setup an internal training session for those who wanted to learn more. The skills matrix is the beginning of an action plan to build ‘T-Skills’.

Here’s one example: With sufficient T-Skills, when code and unit test are done, the same team member begins higher level testing. They do this not as a specialist but as someone who can contribute. Once the test specialist is available, the testing will proceed faster. This practice removed the hand-off and made the transition from code to test fluid and easy.


These ideas don’t guarantee success because once started, these behavioral changes must persist forever or until the next best thing comes along to replace Agile. It is far too easy to fall back on old habits, ask anyone who has quit smoking for the fifth time. The best thing to do is create metrics and monitor these for continued improvement or a relapse.

Empowerment and team boundaries can also erode over time. Once the team and management have defined boundaries, everyone should sit down once a month or once a quarter to re-work these. In the normal course of experience and time, team boundaries should be seen expanding. This indicates a growing trust of the team and the team’s growing understanding of the business. If the boundaries are shrinking then there’s probably a [big?] problem.