It’s time to wrap this series. I started asking if you actually need an agile approach in Part 1 and noted the 4 big problems I see. Part 2 was why we need managers in an agile transformation. Part 3 was about how people want a recipe. Part 4 was about how “Agile” is meaningless and “agile” is an adjective that needs to be applied to something.
I suggested various alternatives in the earlier posts and offered plenty of pointers to other readings. This post is about what you can do to create an agile culture, regardless of where you are in the organization.
BTW: One more thing about an agile culture: Many of the people I spoke with at the conference are convinced they need to “scale.” I wrote a series about scaling where I talked about a reasonable progression of how you might work, instead of trying to adopt a framework.
Let’s assume there are various people throughout the organization who do want the cultural change that an agile approach will bring. And, that your products and services need short feedback loops that an agile approach will use. An agile approach to everything will help the business succeed.
Start with management first. How can the managers use agility in their work?
Management Teams and Agility: Flow & Resilience
When I think about management agility, I often think of managers working in flow, especially for decision. What is the cycle time for management decisions? I find too many managers spend months trying to gather data to make budgeting decisions. Some examples:
- Which projects to fund to create the project portfolio. The managers think they need cost and date estimates for “everything.”
- How much of a percentage raise to offer people, where the variation is too often within 2%.
- Which tools to standardize on, so the company saves money on licenses.
Many of these decisions are about managing expenses. I’m all in favor of saving money. And, too many of the decisions take too long to make and are for too long a duration. That means too much money goes down the drain either while managers decide or between their next decision time.
Those management-decision times are not sufficiently resilient for an agile organization.
How can managers make decisions faster for a shorter duration? That would be resilient.
Business resilience means everyone works in flow efficiency, not resource efficiency. It means the managers collaborate with each other, across the organization. Not just for a program, but for business as usual. Yes, the managers collaborate. They also experiment and learn from their decisions. (See Agile Transformation is a Journey, Part 6.)
If your current incentives work against management collaboration, fix that. If you must have individual incentives, your organization can’t achieve management flow and resilience.
Let’s assume the managers are ready and able to collaborate. The managers watch their decision times and see how to shorten those times. Might the managers use a board to create transparency? Sure. They might measure their decision cycle time for various decisions.
When managers shorten feedback loops and collaborate, they work with agility and create resilience. And, they change the culture to one that supports agile approaches.
Once you have management agility, it’s time to think about feature teams. (I know. Almost all the frameworks and accepted ways of thinking start with feature teams. In my experience, agile feature teams are not sustainable unless the managers collaborate.)
Create Feature Teams
Even if you don’t need an agile approach, feature teams will help your product development efforts.
I met several people at Agile 2019 who don’t have feature teams and they’re wondering why their agile approach doesn’t work. They were in the trap of How Long Are Your Iterations? Part 1. Component teams increase cycle time. (See How Long Are Your Iterations? Part 2).
I don’t see how to succeed with any agile approach if you don’t have cross-functional teams who can focus on and deliver a product or a feature set. If you can’t create feature teams, consider solving that problem first. What are the forces that keep the current system in place?
Feature Team Agility
What kinds of problems does your team solve in the organization?
If the problems you solve are not deterministic, consider working with agility:
- Collaborate with the rest of your project team and your customer/customer representative to move one small piece to done as often as possible. If it takes you forever to get to done because of your work environment fix that problem first, or as you proceed. (*See note below.)
- Be transparent in your work. Create a board that works for your team. Your team needs to see all the work and if any of the work is stuck.
- Retrospect/kaizen as often as you finish something. What do you need to remove from the way you work? What would you change? What would you add?
Note*: I am not saying automate all the build issues or the tests that were created before you were born. You might need to do that and I recommend you explain to the PO/customer the delays your current system creates. Instead, do the smallest possible thing to improve your work environment every feature. Repeat.
These are guidelines that enable agility. Are they enough guidelines? Probably not. For example, in Part 3, I suggested technical excellence was necessary for agility. I didn’t suggest any technical practices in the above 3 bullets. I infer the technical practices in the “collaborate to get done” as often as possible.
If you’ve been thinking about your software development/testing work, you know that a clean environment allows you to proceed faster than an environment full of technical debt and cruft. That’s why the technical practices matter.
Notice I didn’t talk about meetings, planning, any of the rituals, except for the retrospective. If you collaborate as a team and with your customer, and if you are transparent with each other, and if you retrospect, you have enough—possibly more than enough—to start working with agility. (Hint: If you keep the team’s WIP (Work in Progress) to 1, yes one feature, you don’t need a lot of meetings. See the swarming and mobbing posts.)
You have the bare minimum environment and teams to experiment your way to an agile approach.
Do you really need an agile approach?
Don’t Use an Agile Approach if You Don’t Need to
If you don’t need an agile approach, don’t use one. You might find a waterfall approach is not as helpful as an iterative, incremental, or combination is. But, if you don’t need an agile approach, don’t make yourself nuts.
If you don’t need an agile approach, read Manage It! to see all your lifecycle alternatives. It’s not just “agile vs waterfall.” You might find an iterative approach or an incremental approach will give you what you need.
You can use “how little” thinking to guide your product development. You can create interim deliverables so everyone can see progress. You can show demos—yes, even if you don’t use an agile approach.
Remember, an agile approach is a cultural change.
You might need to empathize with your managers when you select a lifecycle that fits.
Extend Empathy to Managers
Many managers feel pressure. The pressure might be from cost overruns, schedule overruns, and too many defects. Too often, they don’t realize they, the managers, create the very problems that give them aggravation. They see serious organizational problems and they want to solve them.
There’s plenty of “Agile Can Do This Amazing Thing” marketing nonsense in our industry. The managers have seen that marketing. Because the problems pressure the managers, the managers desperately want to believe the marketing. The managers want the answer (that recipe thing again). “Agile” appears to offer that answer.
If your organization has those problems, and your management has heard anything at all about an agile approach, they not only want, they might need an agile approach to remain competitive.
Here are some options:
- Answer “why” for your agile transformation. Consider reading my agile transformation series.
- Decide on the organizational data you might collect to aid everyone in their understanding of what the organization might need from an agile transformation. Not a lot of data. A little data.
- Explain flow efficiency, and why that means everyone optimizes up, at every level of the organization. That will prevent the managers from focusing on team-based data, which is not what they need to make decisions.
- Focus on the principles behind the Manifesto and see how well the organization can live the principles.
Your managers might not realize if the pressure is real or not. The pressure feels real to them.
However, “Agile” is not the goal.
Agile Approaches Are Not the Goal
“Being agile,” or worse, “Being Agile,” is not the goal. Better business results are the goal:
- Keeping and acquiring new customers.
- Keeping and hiring new people who are excited about the work.
- Deciding when it’s time to retire old products and services and when it’s time to launch new products and services for the customers and the people.
These are not about a direct approach to “increasing shareholder value.” You increase value as an outcome of those three bullets.
If you decide after all this, that an agile culture is right for you, I’m delighted. I’m also delighted if you decide an agile culture is not right for you. You’re thinking, which was my point in these posts.
Thank you for reading. Please check out my books to see if any of them are right for you, where you are now. I encourage you to comment and/or send me an email to discuss more.
The entire series:
- Where I Think “Agile” is Headed, Part 1: Do You Need an Agile Approach?
- Where I Think “Agile” is Headed, Part 2: Where Does Management Fit?
- Where I Think “Agile” is Headed, Part 3: What Is The Recipe, The Right Answer?
- Where I Think “Agile” is Headed, Part 4: What Does “Agile” Mean?
- Where I Think “Agile” is Headed, Part 5: Summary
Published on Java Code Geeks with permission by Johanna Rothman , partner at our JCG program. See the original article here: Where I Think “Agile” is Headed, Part 5: Summary Opinions expressed by Java Code Geeks contributors are their own. |
