top of page

Agile: It's about Common Sense

Agile Team Success

One by one companies utilize efforts to become more Agile in their approach. In so doing, I am met time and time again with companies across various industries where people tell me that I just don't understand what is going on in their company. They are different. They are unique. There's no way that this whole "Agile thing" can even work for them. Now early on in my career I may have been inclined to listen to these naysayers and think how do I adapt to what they know and what they think is best. But as you have seen companies and organizations across countless industries, the more you see, the more you realize how similar problems really are for these people and their organizations.

I have found myself saying how Agile is about decisions making sense. And I oftentimes observe the decisions are based on Common Sense. If you find your team is lacking in Common Sense, fret not. You can find it for them at Wal-Mart on aisle 9 about half-way down on the top shelf... obviously it isn't that simple. But when someone is making something more difficult, you need to make it easier for them to see how simple things can really be for them.

There are big problems that I commonly find myself pushing teams, ScrumMasters, Product Owners, Managers and Executives to think more openly about the simplicity behind the solutions to their problems instead of the complexity they have built up to prevent change. It is small and simple solutions that lead to significant change in life, in business and in everything that we do. Let's look at a couple problems that seem complex.

In working with a team recently that comprised of almost 20 team members, I was surprised to see that their daily stand-ups would result in team members zoning out for periods of time during that crucial ceremony. I even noticed a couple team members actively participating in games on their electronic devices (phones) when their "turn" was finished in the daily standup. It had become a status meeting and everyone dutifully walked in and out of the room at the same time every day to participate in the vocalizing of their work duties.

After observation, I asked the leaders situated around the team for their success (ScrumMaster, Product Owner, Project Manager, Development Manager and Quality Assurance Manager) why the team was so large. I got mixed responses about people needing to hear the same message at the same time. As I pressed further with some "Why" questions, I found some concerns about changing priorities, overlap of responsibilities and at the core... not enough time to perform the core duties of prioritizing a Product Backlog to give the right direction at the right time to team(s). Two simple solutions came to mind...

1) Make sure the Product Owner has the time to make decisions on what should be focused on and when

2) Make your team(s) smaller so they are more engaged in the day to day work and find solutions for the problems they are responsible for.

Many people think that it isn't that simple, but it is. When the company made that decision to offload the decision making ability to someone who was in the position to make priority decisions, suddenly the right things were being worked on. After that happened, a revisiting of what efforts were the most important to organize teams around the top priorities ensued. As the teams were organized around features, it didn't take long (2-3 sprints) to notice a significant increase in throughput or velocity to the tune of a nearly 300% increase.

Don't overcomplicate things, look at the principles behind what you are doing and try to adapt towards the path of agility. As you get closer to it, you will notice improvement not because it is more complex or busy but because you have made things easier for yourself by sharing the burden of responsibility and accountability with the team.

bottom of page