Agile Coaches' Corner Agility: Difficulties vs. Opportunities in Organizational Decision-Making
This week, Dan Neumann is joined by his regular guest/co-host, Sam Falco! Together, they’re exploring the topic of agility and some of the early decisions that either create difficulties or opportunities as organizations are moving towards agility.
The decisions that you make early on with your organization can strain you in ways that are unforeseen. It’s one of the reasons why agile coaches and leaders often say: “Don’t make a lot of decisions about your product up-front until you get some data back.” In this conversation, Dan and Sam highlight the key differences between the decisions that are made up-front that can impede a team in the long term vs. the decisions that can help move an organization forward in the right direction.
Key Takeaways
Why you shouldn’t make major decisions up-front:
Making a lot of decisions (or major decisions) up-front can often strain you in ways that are unforeseen
You shouldn’t make many decisions about your product up-front until you get some data back
I.e. If you build your entire architecture platform before you deliver any business features, you’re constraining yourself because you’ve built a lot of things that may never get used
The same goes for organizational design (if you make too many decisions about how you’re going to ‘do agile,’ you’ll experience constraints later on
Agility is suited for conditions of high uncertainty, so when you try to apply predictive thinking to an evolutionary approach you’ll run into many challenges
Decisions that are made up-front that can impede a team in the long term:
Avoiding rework (it is sometimes needed/important to revisit decisions you’ve made in the past and fix them)
I.e. If the bone that you broke when you were 10 healed wrong, you’re going to have to break it again to fix it — the same goes for some of the decisions you make in your organization (i.e. re-platforming)
Solution: Take on an experimental mindset and ask, “What would it look like to intentionally take on some rework?”
The key thing to say to clients that are resisting rework would be: “Rework for the sake of rework is bad. But, look at the value you can get and make a good decision based on that.”
Dedicated individuals on a team vs. shared resources across many teams
“We have to have people on multiple teams because we’ve got so much going on.” That’s a problem in itself — limit your work in progress; you’ve got too much going on
Solution: Stop saying, “We can’t do that,” and instead start asking, “How can we?”
Another team-oriented decision that can cause problems later is component teams vs. feature teams
It is better to all work together on the same thing and get it done rather than handing it off from team-to-team
Having one person do two roles (i.e. they’re the Scrum Master and the Product Owner)
If someone is trying to balance two roles they won’t do either well
Solution: Take a look at the roles and make sure that they’re being filled in a way that gives a person a chance to be effective
“Scrum has too many meetings”
Solution: Have everyone attend the same meetings which will eliminate additional meetings for separate teams — transparency and communication are key
New Scrum teams using the thinking of, “Let’s just put all of the items into the backlog, and then we will work the backlog until it is empty.”
This comes from a place of not trusting or understanding incremental delivery
Key takeaways and final tips:
Apply a systems-thinking pattern and an experimental mindset
Abandon the illusion that we can predict the future and that we can control the outcome
Having a forecast of where you’re going is valuable but it is important to realize that it is not certain
Mentioned in this Episode:
AgileThought.com/Events — Visit for AgileThought’s upcoming virtual events & RSVP!
Console Wars: Sega, Nintendo, and the Battle that Defined a Generation, by Blake J. Harris
Want to Learn More or Get in Touch?
Visit the website and catch up with all the episodes on AgileThought.com!
Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!