As I work with people to use agile approaches, I see many organizational constraints.
I’ve been trying to find a visualization for what I see. I don’t know if I’ve got it yet, but here is my sum-of-the-parts image.
The organization’s culture drives decisions (or not!) about the strategy.
Strategy, with any luck, creates clarity about which products when (the project portfolio). Those decisions (and the ability of a team to release) helps the organization acquire and retain customers, which leads to revenue. The more change in the market or what the customers want, the more often the senior leaders need to re-examine the strategy and purpose.
Inside the product/portfolio decisions, every project has constraints:
In projects, the organization often wants to constrain the project cost (funding). Too often, the organization constrains the people (who have both technical and non-technical expertise). And, the organization will define the approach, and too often, the tools the people can use.
Inside those constraints, the people can deliver features (the what), in some time (when), and with some defect levels (good).
Push a team to deliver more features too fast, and the defect levels will increase. Decrease the funding, don’t train or decrease the staff, and the team can only deliver what they can, when, and how good.
Project constraints live within the next set of constraints: how the people in the organization manage the strategy: defining the products and the project portfolio, so the organization can acquire/retain customers and receive revenue for their work:
- The more the organization understands and clarifies its strategy product strategy, the more clear the project portfolio decisions are.
- When the organization has clarity, we can expect some form of customer acquisition/retention.
- That customer acquisition/retention, along with the product strategy allows us to predict and recognize some form of revenue.
- Depending on the rate of change in your market and with your customers, you may have more or less predictability.
I’ve shown this as a bounding box because the projects live within these constraints. I’m not sure that’s the right image.
However, culture is really the organizational constraint:
When we understand what people can discuss, how people treat each other, and what the organization rewards, we can understand how the constraints interplay.
I’ve worked with organizations where the culture said, “We’re a happy family. We can discuss what a family discusses. We work here for the fun of it.”
That meant that we couldn’t discuss the irrationality of the project portfolio, the lack of product strategy, the fact that they rewarded people for heroics, and more. We were just like a family—a dysfunctional family.
If we realize that the organizational culture constrains how we manage the product strategy and the project portfolio, we can see the effects on customer acquisition/retention, and revenue. If we don’t understand how fast or slow our markets or customers want us to change, we can’t refine our strategy/purpose. I guess this should be a circle, but to me, it feels like a bounding box on all the projects.
I’m experimenting with these images. I would love feedback from you so I can improve them. If they make sense to you, or if they don’t, please do let me know.
I find that when I understand the organizational constraints, I’m more likely to be able to live within them—or challenge them successfully. Understanding your organizational constraints might be part of what could make your agile transformation succeed.
| Published on Java Code Geeks with permission by Johanna Rothman , partner at our JCG program. See the original article here: Visualize Your Constraints Opinions expressed by Java Code Geeks contributors are their own. |
