A frequent conversation with executives who are entwined with an agile transition is about the often stated claim that an executive cannot tell the agile development team what to do, how to do it, or when it must be done. I ask her from where did the teams pick up these claims? Her response is that she is unsure. She says that it maybe was stated during the Scrum team’s training and that their Scrum Master is claiming this to be true. I ask given this situation how does she communicate status with her stakeholders and boss. After a pained expression, she says that’s why I’m talking to you.
Talk about constraints! My executive friend seems to be the one constrained by her teams and team leaders. Constraints are an “applicable restriction or limitation, either external or internal to a project, which will affect the performance of a project or process”, as defined by CrossLead, an executive coaching firm. For me, teams forcing constraints on executives seems a bit odd and are likely the ugly side of constraints.
So, are constraints good? Let’s use CrossLead’s definition to rephrase this question. Are ‘applicable restrictions and limitations, either external or internal to a project, which will affect the performance of a project or process’ good? Let’s try this example out. Let’s say that we have an agreement with the company’s investors for a specific level of funding for a specified period of time to deliver a capability. Is this a good constraint? I would argue that if reasonable and real, knowing this is a constraint is helpful during teams and leaders’ decision making. Yes, it’s a good constraint, especially, when compared to not having investors or funding.
Other examples of good constraints are: the requirement that one collaboration and work tracking tool is used consistently across all teams, the definition of done for completeness of work, the timing of Sprint standups, planning, review and retrospective meetings, the structure and priorities of various customer and business outcomes in the backlog, the definition of teams/roles across the organization, the offering architecture and design, and the build/devops methods.
These good constraints provide the correct context for teams to efficiently and effectively operate together in creation of high-integrity customer outcomes. In other words, these restrictions and limitations help teams in delivering the desired outcomes together. They act as a binding function bringing teams together. You might consider these good constraints akin to a collaboration framework.
So, what type of constraints are bad? Clearly those that inhibit teams from delivering their outcomes. Many times, these constraints are undocumented, unspoken and/or out-of-date decisions that have become inculturated into an organization’s thinking.
When I hear comments such as, that’s not how we work, that’s against policy, that’s not what our customer is now demanding before they buy, etc, I immediately question where these constraints are coming from and how visible/valid they are today.
My first investigation approach with constraints like these is to ask, ‘where are these constraints documented?’ The answer is more than not that the constraints aren’t documented. I guide the teams forward by asking them to develop the right constraints (if any) that will take their place, document all of the constraints in force, and widely communicate them. If they are documented, then I approach the leadership team to discuss if they are aware of the constraints and if the constraints remain in force. If the constraints are no longer in force, we actively communicate the situation, why the constraint is not in force and what has taken its place. If the constraints are in force, we add it to our constraints and ensure that every team and leader understands the constraint and its reason for being.
Back to the ugly constraints. These are constraints that are half-truths or based in ignorance that are accepted by the organization and unquestioned by leadership. For example, take the three listed my executive friend, an executive cannot tell the agile development team what to do, how to do it, or when it must be done. While partially true, that an executive cannot tell the agile development team what to do, every team has stakeholders and has agreed to a prioritized backlog with customer outcomes and a common definition of done. This is how an executive works with teams to reach agreement with the teams. The executive has to know how the teams decide what to do and has to participate in these methods for everyone to be aligned in what will be done.
The executive cannot tell the team how to do it is a half-truth because it doesn’t inform the executive that she is able to inspect the outcomes at every sprint review meeting as a stakeholder and to inform her of potential changes in what’s desired for the upcoming sprints. If there’s a gap, backlog prioritization and grooming will help bring the stakeholders and team together.
Lastly, on executives not saying when the work must be done is a confusion of constraints. Mature agile teams are able to communicate the rate of completion of customer outcomes, or the velocity of their work, and are able to project potential future outcomes based upon their properly groomed backlog. Mature agile executives should know how to use this information to correctly communicate to their stakeholders. If there are any concerns, the executives and teams have the grooming mechanism to identify and address them together, while maintaining excellent agile methods.
Notice the pattern here, the executives are active in the identification, disposition, communication and articulation of constraints. By doing so, the executives positively affect the performance of their teams.
