5 Things Your Project Team Can Do Right Now to Become More Agile

Introduction

Agile is a word that gets thrown around a lot these days. While continuing to be the “methodology du jour”, especially in the complex world of software development, a lot of misconceptions exist around what it truly means to practice agile.

Becoming a high-functioning agile team takes more than simply performing a stand-up every day; it requires a top-down re-engineering of how your organization defines, delivers and measures value.

This process can be difficult under the best of circumstances (enthusiastic management support, proper training, on-going coaching and well-configured tools), and the scope of the change can seem intimidating when business as usual has provided successful results.

To that end – here are 5 things that every project team can do right now to become more agile regardless of where they are on their transition journey.

When gathering requirements, don’t get hung up on the details

It sounds odd, right? We’re all used to requirements gathering as an exercise in collecting minute, sometimes painstaking, detail, but the “less is more” approach really applies here and for good reason. Allow me to explain this with the following analogy:

Our project is to build a house. Now, I can spend six months at the onset of the project working with my customer to define a beautiful set of fully defined, architectural plans for my builders. My trade off with this approach is that means my builders are sitting idle for that time frame, and that is six months of development progress lost towards my ultimate delivery of a fully functional home.

Alternatively, I could work with my customer to define a smaller set of specs for the foundation of the home and a separate set for framing out the first floor and another for putting up the walls. This will allow me to get my builders started sooner and collapse the timeline between project onset and delivery, but that is only half the reason why focusing on fewer details is the preferred approach.

Anyone that’s ever worked on a project team knows that having a beautiful set of specs doesn’t prevent the customer from requesting changes once we’re ready to walkthrough the fully built house. There are simply things you can’t visualize from a set of plans no matter how detailed they are. The customer really needed to experience the space to understand if it worked for their family’s lifestyle, and now I’m stuck with a handful of change requests at the end of the project when change is most disruptive. If I’d have gone with my agile approach, I’d have walked the customer through the home at every step in the process – gaining change requests early when I can handle them more easily.

It’s also important to note here that this goes beyond breaking the requirements down into smaller pieces. Even when defining a spec for the foundation of the home, utilize the 80/20 rule and don’t spend countless hours chasing after process outliers. Gather the basics – what materials are we using, how much weight is the foundation to support – these are critical. The color of the concrete isn’t important right now because we can handle that later without impact to the underlying structure. The tendency of the customer will be to chase those details early, and you’ll need to be cognizant of keeping them focused on the bigger picture at every step.

Understand the difference between good technical debt and bad technical debt

If you’re unfamiliar with the concept of technical debt, here is a brief primer. Generally, technical debt refers to the penalty you often incur in an agile environment to develop something quickly vs. correctly, and just like financial debt, technical debt must eventually be repaid. There are a lot of reasons why an agile team might choose to incur technical debt on a particular work item – reducing time to market, regulatory mandates, or an ambiguous vision from the Product Owner are fairly common – but just like in real life not all debt should be treated the same way.

Let’s stick with our project to build a house. We’ve already established that we’re moving forward without a full set of detailed plans, and we understand that collaborating with our customer and responding to change is to be expected. When we’re building the kitchen, we’re going to want to know where the cabinets are slated to go even if we don’t spend the time installing those cabinets during our first pass. That is good technical debt. We know at some point in the future we’re going to have to come back and install those cabinets, but we’re not going to have modify our existing structure to do that.

Bad technical debt for our kitchen build would be framing out the walls in the kitchen without planning where the major appliances were going to go. Yes, we can come back and add that in later, but in order to do that – we’re going to have to potentially move walls around, patch down new electrical outlets – things that would have been less disruptive if we’d blocked them out in the first place.

As responsible developers, we should always highlight when bad technical debt could be incurred and make sure our customer has a firm understanding of the risks with moving forward. Ultimately, the decision to accept or avoid that risk will come from the person paying the bills, but our part is to ensure that person is equipped with all the information available.

Don’t be afraid to tailor your process to your environment

Every project and environment is unique, and while we want to understand and follow industry best practices where possible, you should feel empowered to adapt the process to fit your real-life circumstances. It’s called “Agile”, after all, and that includes being agile with how you apply the methodology.

I recently experienced this with one of my projects. Agile was new to the organization, and the Product Owner was still gaining an understanding of the day-to-day needs of the role. We began grooming sessions to build up our product backlog, and per industry best practices – we invited the entire scrum team to participate. After a handful of sessions, we found that we weren’t seeing the value of having developers participate in these grooming sessions like we have in previous projects.

The reason for this was due to the content of our grooming sessions. As the product owner was still learning the ropes, our grooming sessions were swinging wildly from broad system requirements to specific, and sometimes not critical, details. The product owner hadn’t yet found that sweet spot between too much detail and too little and needed time to adjust. Instead of staunchly following the process, we decided the excuse the developers from our grooming sessions and instead implement a separate session for team grooming once a block of work was defined to a minimally acceptable level.

By allowing ourselves to adapt the process to our real-world scenario we were able to save on some overhead meeting hours for our developers while still adhering to the spirit of agile.

If you’ve already implemented some agile ceremonies, play with the formats

Are you doing a daily stand-up? Find alternative methods to solicit updates on progress from your team. Have team members give updates on each other’s progress. You’ll be surprised on the different perspective this can give you. Since sprint success or failure is the responsibility of the entire team, this is a great way to inject some interaction and collaboration in your daily sessions especially if you are not co-located.

Are you doing a sprint retrospective or other debrief after project milestones? Use a tool like https://plans-for-retrospectives.com to randomly generate a different format. This will help get people out of their comfort zone and brainstorm a little differently.

Are you doing a sprint review? Have team members demo each other’s work or rotate who drives the demonstration portion.

The point here is, even if you are already practicing agile, you need to always be searching for ways to keep the ceremonies interesting to your team members. This will avoid the rut that can set-in over long-term project and genuinely help bring new ideas and different perspectives to work that might have been missed otherwise.

If you haven’t implemented any agile ceremonies, start including some small ones

Are you about to embark on a build phase of your project? Break the work up into sprints with smaller, measurable deliveries. Implement a daily stand-up to discuss progress and trash your boring weekly status meeting for a time.

Are you gathering requirements? Begin by identifying your major pieces of functionality, or Epics, then break them down into smaller, more consumable pieces of work. Invite your entire team to participate and ask questions of the customer. Remember when it comes to these grooming sessions, the customer/Product Owner owns the “what” and the team owns the “how”. The customer should be dictating the business requirements but not the technical approach to meeting those requirements.

Are you estimating a timeline? Work with your team to assign point values to your requirements and establish a baseline of how many points you can complete in a two-week period. Divide your total number of points by your two-week velocity and create a road-map to completion. Your velocity can, and should, change over time, but start by putting an initial plan together and iterate on it – you know, be agile about it!

Did you just finish a major release or milestone? Hold a sprint retrospective and take inventory of what successes you should build upon and what needs improvement.

The agile methodology is not “one-size-fits-all”, and it a good practice to be agile with your own adoption of a new process. Try things out, see how they fit for your team and environment and then adjust. That being said – make sure to give these new practices time to settle in and stick with them even if they feel awkward at first. Work to keep things fresh and keep refining until you find what works best. Before long you’ll find yourself on the way to becoming a high-performing team.