3 Ways to Keep Your Agile Development Project Moving Forward

Does your project feel stuck? How often are you communicating with your team? How often are you communicating with your users? When was the last time you reflected on your process? In this post, I will take a look at three ways to keep your project moving forward.

Before you start reading this post, I recommend you go check out the agile manifesto, and read through the agile principles. Even if you’ve read them both before, they’re quick reads and I’ve found that both articles are a good reminder of what agile practitioners should be striving for.

Three Approaches to Try

1. Continuous Feedback Between Developers and Business People

One thing that stood out to me while reading over the agile manifesto principles was the idea of continuous feedback through effective communication. Here at Quick Left, one way that we communicate effectively with our clients is daily stand-ups. This is so we can share what we’re working on now, what we have been working on, and any blockers or problems that have come up. To facilitate our stand-ups, we almost always use Google Hangouts, both because we can see people’s faces, and because it’s easy to share someone’s screen.  Talking over the phone is fine, but we’ve found that face-to-face (or via webcam) is better because it adds an important human element. Stand-ups are also an opportunity to talk about anything taking longer than was estimated at the outset. Then, if necessary, reprioritization can happen.

In project management, the ‘iron triangle’ is frequently talked about in regards to project constraints. Here is an example of what it looks like:

Iron Triangle

Two of the three sides are fixed. Maybe the team is restrained by time (which typically translates to cost) and quality, which means that they need to be flexible with scope. Or, time and scope are fixed, which means that quality won’t be as high. It could also be that you want a high quality product and the scope is fixed, which means that the time the project will take to complete needs to be flexible.

Since there is so much potential change involved, communication within the team is key. If a feature takes longer than expected to develop, or an unexpected problem arises, something needs to give. Do you spend more money to get all of the features you talked about at the beginning? Or do you cut out a feature or two to keep quality high and delivery on time? These decisions will be specific to your situation, and need to be communicated with the team so that your developers aren’t wasting time building features that will get cut from the final scope.


2. Continuous Feedback Between Product Team and Users

The safest (and cheapest) way to make sure you are building something that your users want is to get your product out there! Communicating with your users early and often means that you will only spend money on things that provide value for them, which saves you money since you don’t need to build that expensive feature no one will use. As soon as you have a minimum viable product (MVP), get people using your app. As a product owner, you minimize risk by having your product tested. 

After you watch people use your app, you should be able tell if your app is intuitive, and if it is solving a pain point. It never fails that people use your app differently than you think they will. But, the beauty of software is that anything can be changed. So take input from your users and change things! All this feedback will keep your product moving in the right direction.

snow winter train plowing

3. Reflect

Reflecting is one tool that adds a lot of value when done well, but it gets cut from the process too often. Take time periodically (weekly or bi-weekly) to think critically with your team about the previous iteration. What went well? What didn’t? How can you change what didn’t go well? In this setting, actionable, specific, and kind feedback is important; this shouldn’t be a place to point fingers or place blame. I’ve also found that it’s critical to keep these meetings to an hour maximum, or else people start getting antsy, bored, frustrated or a mixture of all three. 

There are any number of ways that you can go about reflecting, but be sure to cover what went well, what could be improved, and what your team should stop doing over the next iteration. Then, make action items and make it a priority to change the things that didn’t go well. I’ve seen it done effectively using both Google Documents and whiteboards.

Wrapping up

I hope you found some tools in this post to help you more effectively engage with the people who run the business side of your product, developers, and your users. It’s important to look at your process, product and people to determine what is right for you. However, I highly encourage you to add continuous feedback and reflection to your process if it’s not there already.

P.S. What agile principles do you use to keep your product moving forward? We’d love to hear about them in the comments below!