How to Not Be Agile: 3 Classic traps That Will Keep You Stuck Where You Are
“We do Agile but I update the Gantt based on daily tasks...”
“...this is the first I'm hearing of this change!”
“We set this list of deliverables five months ago, we want them delivered next sprint!”
How many times have you heard these phrases and ones similar spouted in “Agile” organizations today?
The Agile manifesto, crafted in 2001, provides a set of principles for developing what was then software products, and now relevant and applicable to a variety of industries and products. However, as with Waterfall before, and whatever Lean/DevOps/Agile fusion that comes next, there is always a difference between theory and practice. Those that are able to actually apply the principles of Agile will find themselves far ahead of others that just say they are Agile.
So where do most people and organizations lose the trail on their quest to be productive and reactive in today’s fast-paced economy?
- Beware Getting Stuck in an ‘Agile Framework’!
The consortium of different Agile certification providers has established an ecosystem that almost certainly will lead to toxicity in the real-life implementation of agile within your organization. Now don’t get me wrong, there is value in obtaining certification and having these in place as you go through your transformation to more nimble and focused practices.
But these must, Must, MUST only be considered as possible starting points for actual practice.
Scrum, Kanban, XP, SaFE, etc. are all great areas to begin your introduction to the world of Agile but that's all that they are: an introduction. Agile is more than just a framework that helps managers feel safe at night. Agile practices within an organization should be embraced as a personal passion that never ceases to evolve. Scrum provides the rules, but after a while, you start finding that you need to break some of these rules to allow your journey to continue.
Just like the technology we develop, Agile operations in an organization is ever evolving and if you think you have found yourself at the end of the journey, it's time to learn something new.
2. Avoid Overegging the Planning and Reporting Omelette
I get it. The CEO gets his update from the CIO, CTO, and CRO on Thursdays. So the CxOs need information on Wednesdays. The Directors and SVPs collate status on Tuesdays. This is why the Program and Project Managers are asking for updates on Monday. Then once the PM has their update they now field the same questions from every one above them and now we are doing updates on Tuesday, Wednesday, Thursday, and Friday to match the schedules above.
The following week is rinse and repeat. Want to know how to drive valued developers and employee’s away? Hint ^^^
“We plan, but recognize the limits of planning in a turbulent environment” — Jim Highsmith, History: The Agile Manifesto
Agile approaches such as Scrum, and to a minor part Kanban, are built around the Sprint. This is a dedicated period of time when an entire team (devs, managers, facilitators and even customers if they are about) produces against an agreed upon prioritized backlog of functional increments.
The frequency of your sprints then becomes the smallest unit of measurement that an organization can contemplate i.e. if you have weekly sprints, then (worthwhile) reports cannot come more frequently than that!
This frequently gets forgotten. Even if the capacity of a development team in a sprint is measured by units of time (if you do this please contact me, we need to talk), the way that progress is measured, reported, managed, planned and coordinated should almost never be viewed in shorter increments than the sprint.
“But how do I plan if I cannot know what each developer is doing throughout each day?” —Every Client Ever
Remember: change happens all the time.
When a change to the current priority is requested, it is the development team that knows the effort required to create functionality better than anyone else. In turn, managers can solicit feedback from the customer much more accurately. The Directors and CxOs are now able to base progress off the customers’ feedback, rather than status updates!
Our job is to create space for the development team to define the technical pathway to achieve the functionality requested through feedback. Enabling the team to scope functionality that is prioritized by the business is sufficient for a plan that balances requirements versus future uncertainty.
The dirty secret here is that organizations believe they can predict the future and that that's what they are paid for. In reality, certainty is much harder to come by than anyone would like to admit.
Plan accordingly!
3. Do You Trust Your Dev Team...Or Try to Control Them?
Do you find yourself asking the development team what they have accomplished every day? Are you looking to guide the team to success through structuring their ability to produce? Do you have meetings to discuss meetings? Do you report information in different ways depending on the “message” you want to send?
These are all efforts in creating a controlled environment. In looking to control someone else's behavior we are signaling that we do not have trust in that person or team. Establishing an environment in which trust is the main pillar of support provides the dynamic for the team to meet and exceed expectations.
These expectations, set by the business and, more importantly, the customer, are what drive the development team to perform and achieve. These change over time, which might cause you to lose sight of the business objectives vs. the task at hand. By focusing on the task rather than the objective you will be quietly but inevitably deviating from your business goals (while feeling like you’re making progress!) and may be tracking and communicating the wrong information up the chain as well.
As an example, say that at the start of an engagement you identified that your customers require container orchestration in ten months’ time. You also settle on Kubernetes as the most appropriate management solution.
Suddenly, at month five, the business decides it needs the functionality by month six. The team is able to identify a solution using AWS EKS that would provide the same capability in the short term and can evolve into a full implementation of managed Kubernetes by month ten.
As the leader providing the environment for success you really only have two choices here:
1) You focus on the team and micromanage why the team was unable to provide a Kubernetes implementation in half the time and carefully examine every assumption and guess made at month one.
2) You engage the team in their decision and ensure that this is fully communicated to the customers in an established fashion, perhaps through workshops or demonstrations. You work with the team to see how the introduced change might have affected the current outlook and know that things will continue to deviate from the originally set outlook and schedule.
We aim to develop systems that are tolerant of change in an organization while still structured to provide the predictability needed for planning. Building the divide between objectives and deliverables keeps the focus on the outcome of the sprint and not the day-to-day actions of the team. The second choice above allows for the balance of functionality and predictability needed within the organization.
Day-to-day status updates and multiple reports each week display challenges in your approach. Establishing goals, providing authority, and trusting your development team will provide the environment needed to allow you to begin learning how to plan and strategize.
Why Does This All Matter?
In today's economy and technology landscape, tech talent seeks an environment to thrive and excel in. If you as a leader, or organization, do not make the effort to modernize and encourage the success of your teams you are falling behind. Technology can provide a solution and fix to problems you currently have. But by working with your people and building trust and communication, you prevent problems you haven’t had yet.
