Make Agile Great Again
Daniel James Gullo
Over the last 2+ years, I have seen the topic“scaling agility” become the hottest new buzzword and market trend.
Everyone from executive leadership to people on development teams are wondering: “How do we scale?”
What they really want to know is: “How can we eat all the cake, ice cream, pizza, and other garbage we want, never go to the gym, and actually LOSE weight???”
They want to know how to improve their organizations without making a single trade-off.
They want absolute certainty that what they are doing will yield a certain return on their investment BEFORE they make the investment.
Time and again I advise organizations that if they want to improve, they need to begin with making smaller investments and conducting shorter experiments. They seem to be willing to do “anything”, except…
Have Dedicated Scrum Masters for EACH Team
We have thousands of professional sports teams in the world who are the best athletes in their sport. They know the game, the rules, how to win. Yet, every team has coaches… in fact, some teams have several coaches for ONE team.
If we want to have a high-performing Scrum Team, then we need a dedicated, full-time coach for each team whose sole job is to ensure the team has everything they need, looks for ways to improve, resolves issues, etc. and who doesn’t have the conflict of interest represented by coaching multiple teams simultaneously.
THAT is the ScrumMaster.
I have seen countless organizations who try to cheap out by having a Scrum Master “manage multiple teams”.
*FACEPALM!*
“You just don’t get it…”
Then, they blame Scrum because they aren’t getting the increased Velocity that they expected…
*DOUBLE FACEPALM!*
I have also seen some organizations who take the Scrum Master role very seriously and those organizations have slowly but surely improved over time.
Have Dedicated Development Team Members For EACH Team
“QA is a bottleneck.” said every organization I have ever worked with who has 5 Developers writing code which ONE person tests…
“We are stuck. No one from the [DBA / DevOps / Documentation / UX-UI / etc.] Group is available right now.” said every organization who has so-called “shared resources”. (Calling people “resources” is offensive, btw.)
When Development Teams lack a critical skill set, there is bound to be trouble.
Imagine an military unit that doesn’t have any medical capabilities. “We don’t have wounded people all the time. We can’t afford to have someone who is dedicated to rendering aid for each unit.”
It’s ridiculous, right??
Instead, why not invest in training so that EVERYONE on the team knows enough about [database / documentation / UI / testing / etc.] to get the work done? If there is still the need for an SME, then hire that person… and train them in other skills so that they can do other stuff when they aren’t performing in their speciality.
It’s just common sense, folks.
In fact, I think the entire Agile Manifesto could be simplified down to one statement:
USE COMMON SENSE
However…
“Common sense is not so common.”
-Voltaire
Have Dedicated Product Owners
People love to bring up edge cases and exceptions as if they were the rule.
I am often asked: “Can someone be the Product Owner for numerous smaller projects?”
I usually answer with a question: “So, these smaller projects aren’t really important?”
Sure, if there are a bunch of small systems/applications that are very far along in maturity to the point where they don’t require any real significant changes and the systems/applications themselves are not critical to the mission of the organization, then, I suppose a single person can be the caretaker of those decisions and modifications.
However, when this answer is given, the logic is applied to “projects” that ARE main lines of business for the organization. I see Product Owners who are responsible for 4-5 different mission critical products and then leadership wonders why these products are failing.
“Is it any surprise that the products are 20% successful when you have a single person acting as the Product Owner for 5 products??”
The Product Owner is the most misunderstood role in Scrum. I haven’t seen many organizations who truly get it. It’s a tough role to play, in all honesty. The person needs to be talking to customers and stakeholders daily. They need to be using the outcomes from those discussions and using the information to refine the Product Backlog. They need to be learning how to define small increments of value, which are elements of the solution a customer is looking for; aka Features. They are monitoring the financial health of the product; answering questions that the Development Team has; and even verifying that the product is accepted throughout the Sprint.
There is plenty of work for 2-3 people to do, if the role is properly understood. I seldom find products that are flourishing where the Product Owner is responsible for other products as well.
If the organization makes the investment in having a full-time champion for the customer and product, then it is bound to be successful.
Everyone Knows
I am trying very hard to spare you from my Leonard Cohen impersonation here…
Everybody knows what it takes to be successful.
Dedication. Sacrifice. Trade-offs.
The goal is not to see velocity increase. The goal is not to aim for a certain ROI that a product is expected to make. The goal is to balance delighting the customer with what makes sense for the organization.
That requires constant conversation, experimentation, learning, etc.
“Aim small, miss small.”
-unknown
That is, focus on making things work great at the team level before you start worrying about how to “scale” patterns of dysfunction.
Daniel has been a well-known and highly regarded servant of the Agile community for many years. His tireless dedication and effort has earned him the distinction of The Most Valuable Agile Professional award for 2015.
As founder and principal of Apple Brook Consulting®, he has first hand experience about what it takes to make business work. A lifelong entrepreneur, Daniel’s portfolio of clients is long and distinguished: ING Direct (CapitalOne), NAVTEQ, IRS, PayPal, ADP, US Postal Service, GM, US Treasury Department, T. Rowe Price, GE, and many other high-profile organizations.
He is the founder of and chief advisor to Agile Delaware and a frequent reviewer, volunteer, and speaker for the Scrum Alliance, Agile Alliance, PMI and other organizations. His experience includes delivering keynote addresses for conferences such as Scrum Gathering – India; Scrum Gathering – Rio; Scrum Gathering – China; et al.