top of page
Search
  • Writer's pictureSavita Ferguson

What does Agile even mean?

Updated: Jun 24, 2021

There's no shortage of opinion and ideas about Agile; there the manifesto and tons and tons of articles on Doing VS Being Agile. Yet still so many companies following these methodologies don't reap the benefit is purports to bring. I believe that's because too many teams focus on the act of being agile, and lose sight of the outcome they are trying to achieve.


Agile means adapting the approach TOWARD a GOAL.


Do you know what your goal is?

For engineering teams, the goal is often a balancing game between competing objectives like:

  • Building the right product

  • In a way that customers are happy

  • To the right quality and security standards

  • Quickly, so it can be released to market soon

  • Without too many maintainability concerns

  • And at low cost to build, maintain and if possible, to extend upon in future

  • All while keeping the development teams happy

Eye on the prize always. When your team is thinking about something that's not going quite right, it's important to question how this affects your overarching goals. Quite often you'll find yourself with more things to fix than you can fix in a reasonable amount of time so you will have to prioritize them. Use an Impact VS Effort matrix to figure out which ones are worth tackling first. It is always better to tackle fewer and complete them than to have too many in progress at once.


Question everything

Does this meeting give us value? Is this documentation in the right place? Should we do a demo of this feature? Reflecting on routine things is an important skillset to develop so that you can figure out what needs to be changed and what is working fine. Encourage your team members to do the same. Remember to keep the outcomes you are seeing at the core of your reflection - does this meeting help us build the right product / make customers happier etc. If you are finding your team spending time on things that aren't really valuable to your specific outcomes, either the activity or the list of outcomes needs reviewing. That's what it means to be agile.


Do you know your options?

Brainstorming sessions can be divided into 2 segments - Divergent and Convergent. When you're looking at drift from your goal their are often a multitude of options which can help you get back on track. Explore these ideas as much as possible before you narrow down your approach, and then keep these discarded ideas stored somewhere for future reference. Preserve as may options as you can, incase your approach doesn't quite work out the way you expected you'll have alternatives available at your fingertips.


How much autonomy do you have?

Ideally the answer to this is lots, and you are actually empowered to fix the problems, or take advantage of the opportunities that you see. If not, are there things you can do to get more autonomy? Or, can you get an ally to help you push through your ideas? Is there a way you can split the idea up into smaller components which are easier to accomplish bit by bit? I fully recommend upping your game when it comes to persuasion skills - these go a long way when it comes to making changes in an organizational setting. Oftentimes the first step to becoming agile is ensuring you have a mechanism by which to effect change.


It starts at the top

In order to truly harness the power of being agile, it is critical that the team leadership are on the same page with the teams - that is, to try to implement an Agile culture at the IT level is to expect it to fail. At its simplest, the business leaders need to be open to seeing a minimum viable product that we can use to validate assumptions without freaking out about the features that are not there. But quite often, because of the planning cadences of senior leadership, engineering teams are limited in the amount of flexibility they have.

I recommend trying hard to get your leadership on board.

Discussing Agile may be the wrong way to do that given how many people have heard the concept before and believe they understand it.

Instead try to understand what you need from the leadership, or where they are preventing your team from truly being Agile and ask for that. For example, if your leadership expects long term roadmaps, consider asking them to support your implementation of a methodology like ShapeUp - every two months there's a pivot point where leadership can bet on the work to take on next.

And always make sure that you are satisfying the needs of leadership - most often they ask for visibility and efficiency - ensuring they are getting what they need to do their job buys your team the autonomy to do things a bit differently.



28 views0 comments

Recent Posts

See All

Comments


Post: Blog2_Post
bottom of page