8 Signs You Are Only Pretending to do Agile Work
If you’re reading this, you’re probably no stranger to Agile — and the headline caught your eye. If you work anywhere in IT, it’s likely that Agile has been brought to your group at some time during the last one to five years. Agile is a team based way to do development, based on continuous improvement. While it’s ideal for short term projects, it also adapts very well to the rapidly changing needs of the business.
Most companies also have a current rallying cry to do innovation based work. We’ve all been told to innovate faster, execute strategy quickly, and be able to adapt to the customer needs. The flavor of the day at the center of this circle is “Agile”. Organizations large and small have implemented Agile based development over the last few years. Teams are formed, daily stand up scrums are held, user stories are entered, and everybody learns how to do grooming and sizing. Management begins to attend demos and retros, and slowly they adapt to iterative release and the removal of fixed project launch dates. All these things happen and the pronouncement is made “we have transformed into an Agile based organization”.
It seems feasible this is true, as 98% of respondents in the 11th annual “State of Agile Survey” say their organization realized success with Agile. You probably feel that your organization is doing better too (and maybe you are to some measurable degree). I’m sure that you can show all kinds of metrics and burnup and burndown charts that include velocity showing the value that Agile has brought to the company. The question is, have you really realized the true value of Agile, and will that be brought to maturity? Has the company really transformed and adapted to the Agile way of doing work? Or, are you really still bound and hindered by legacy waterfall process principles?
Nobody is saying you are not realizing some degree of success with your implementation of Agile. What I am saying is that (much like human nature), you might only be using 10% of your potential.
Here are 8 points that illustrate how you might be only going through the motions of Agile. You may be missing out on the transformation that could be taking place for the company as a whole.
1. HR Is Not Involved
Transforming into an Agile based company and simply doing Agile based software development work are two different things. Transforming a company means working with the Human Resources department. You may not have heard of “Agile based HR”, but such a thing exists. The reason you start with HR is because if you are going to migrate from imposing standards and controls to innovation and collaboration it starts with the human resources of the company (the people). You may need to change everything from the nature of the reporting structure and organization of teams and departments, to the way that people are trained. You need to transform management from a firing line of taskmasters, to become a legion of coaches. You need to migrate from the old annual review process to a system of continuous year-round feedback for all employees. If HR is not heavily involved an invested in your Agile implementation, you will likely fight Agile growth and adoption from the bottom up and never reach maturity.
2. You Have Annual Budgets
The traditional annual funding system has good intentions, but it encourages bad behaviours. When you implement Agile you should not be funding projects anymore. Management has to adopt a new mentality that you are now funding capacity instead. In addition, by using lean budgeting principles the business obtains funding for milestones rather than normal full project based annual line items. It doesn’t mean you can’t have a roadmap of prioritized features with strategy sprinkled on top to adhere to. It does mean that your capacity planning and iterations should be locked down by quarter. Future quarters (and the roadmap) adjust as the needs and value to the business change over time. This encourages transparency and disallows the normal “gaming” of the normal annual funding cycle.
3. Silos Still Exist (both kinds)
Agile is meant to remove the traditional silos that exist in an organization. Instead of having department silos, an Agile team includes both business and IT expertise. They work in concert and have complete ownership of a product. If someone else in marketing still owns the “customer journey map”, or a manager shows up one day and wants to add new content or a completely new section to your website or app — you don’t have total ownership of the product (and a silo still exists). If your company has truly transformed into an Agile organization, everyone would know who the team and product owner were and old departmental silos would be broken down.
A knowledge silo exists when specific expertise is kept within a team. As an example, maybe a particular team has built up expertise using a coding library. They could share that detail company wide by forming a community of excellence, or a guild. Analytics, search optimization, social media, creative guidelines, customer acquisition data, and more should be made available and shared across all teams so silos of knowledge don’t build up (and roles remain as cross-functional as possible).
4. Not Making Data Driven Decisions
There is a saying that “When you spend more time talking to “internal stakeholders” than your customers, you’ve lost.” The same can be said for prioritizing work based on internal stakeholder decisions that do not align with the actual usage data gathered from customers. Analytics are critical for iterative design and development, because it allows you to validate whether or not you have created value for the customer (and profit for the company).
I have made some assumptions here. Such as having defined your core KPI’s, knowing your customer acquisition cost and conversion funnel, in addition to mapping your product features to that funnel (and the cost of getting any portion of that customer journey). If every Agile team member is not familiar with all of these points, you have even more work to do.
5. You Have a Proxy Product Owner
Many groups assign a “proxy product owner” (PPO) (usually from IT), because the real business stakeholder (who should be product owner) doesn’t have time to participate in the Agile process. The PPO has issues because they don’t have authority to make decisions, which amounts to a lot of rework and waste. Direction and priorities often go by the wayside as well. If you have this issue, see point #3 — because you are definitely siloed as well. They key to a functional Agile team as direct and deep collaboration between business and IT. The lines are blurred, and the business gets much deeper insight in the IT process than ever before, and developers gain business acumen they never had access to before.
6. There Are Dedicated Roles
On an Agile team, roles are shared. Developers and leads and the business can all be testers. Team leads might do some PM or BA work. Marketers might learn to write technical requirements. If your team still has strict, dedicated roles — you’re not truly doing Agile work. Work towards having a cross-functional self managing team where everyone can adapt and collaborate on tasks together.
7. Hampered by Handoffs
This is one of the most difficult obstacles to overcome. What good is developing a feature in an iteration, only to have to hand it off to a “release management” team and for it to go live. There are a litany of handoffs and approvals that could cripple an Agile team — from legal to architecture review boards, PMO, or management steering committees. To truly transform a company to “Agile” means from the top down having the ability to cut through the red tape and reinvent ways to iteratively work and go to market more quickly. It doesn’t mean that all these process go away, but it does mean that the entire organization has to work towards the common goal of consistent regular iterative release throughout the year.
8. Communications Follow Chain of Command
This is the final and classic illustration of how you might think you are truly Agile, but not quite there yet. Every member of every team should feel free to follow a “chain of knowledge”, and not the traditional chain of command. A developer should not be forced to go through a supervisor or lead to talk to an architect. The business should have conversations directly with developers, and anyone should be able to speak with analytics or SEO leads without having to go through somebody.
The main tenet of Agile communications is that all team members should be empowered to get the answers they need from anyone without red tape or repercussions. Within an actual self-organized team, no one should ever feel like someone is “doing their job”, or overstepping their bounds because everyone works together towards a common goal.
If any of the points below hit home with you, there are probably some improvements you can make both within your group and your company. If you find some actionable items — it doesn’t mean that your implementing Agile wrong. It just means if you want to realize the true benefits of Agile company wide, what you’re doing needs to connected and spread evenly across your entire organization.