Agile project management methodologies are abundant in the software world. If you’re buying strategic software design and development services, you are bound to hear someone talking about using an “Agile” approach. But what does that even mean? And what does it mean to be a client in an Agile project?
Many projects today are run as “waterfall” projects. This methodology progresses in a linear fashion with subsequent phases. It assumes each phase is complete before we start work on the next phase and you can’t make changes to a previous phase. It also assumes we know everything there is to learn about the project or product up front; there is no space to pivot or adapt as we learn. The project plan might look something like research > wireframes > design > front end development > back end development > QA > Launch.
Again, there is no option to go backwards and no overlap between phases. This works well when you are building a house – you need to have a foundation before you build walls and the project is scoped out in blueprints. But it doesn’t always work out when you are building software, especially around a new or complex idea. We need room to learn, experiment with users and iterate to make the best possible product.
The answer to this can be a bit confusing – mostly because you can “be” Agile but you can’t “do” agile. Agile is just a set of 4 values and 12 principles. If your organization believes in them and works to achieve those values, you are Agile!
There are many methodologies that have been developed to run projects that fit within the agile principles. Some common examples of these include Scrum, Kanban, and Extreme Programming. At Paper Leaf, we typically use Kanban. This system prioritizes completing the most important item first and limits work in progress. We occasionally will run some projects using Scrum if it fits the situation and project.
As mentioned, there are a lot of different methodologies and ways to work in an Agile manner. Here’s what you can expect when partnering with an Agile agency.
Agile prioritizes the production of working software. This means that you’ll get something working and be able to play with it early in the project. It won’t be perfect or be 100% everything you want it to – the interface might not even be in your brand colours to start.
For example, the team might work on and complete a sign-up process. It might be simple at first: you can make an account using an email address and a password. Following this initial scope, the team may add subsequent steps to this workflow in upcoming periods of work (depending on the priority of the items) – adding the ability to sign up using a Google account, for example. This is often called iterative or incremental work, which means starting with the simplest version and building on it.
Here’s an example: let’s say I want to get from my house to the Paper Leaf office. The simplest method is for me to walk there. I will get there, but it’s not convenient. The next iteration might be that I can take a bicycle there. I’ll get there faster, but it’s not the most comfortable way to go. The next iteration might be for me to buy a small compact car and so on.
While you might be used to getting the whole design of a product upfront so you can approve it, Agile favours working software over documentation. That means there isn’t a a separate design phase or any other phase; the priority is getting working software in the hands of users as soon as possible. Using the transportation example above, we are prioritizing a method of transportation (a bicycle) and not on completing a wheel or a steering wheel. We want to produce something that works and achieves the objectives, test it with users and iterate based on our findings.
As much as we like to think everything is important, there are generally 1 or 2 central goals our product should be achieving. As the saying goes, if everything is important, then nothing is.
When we’re working in an Agile manner, we always want to work on the most important thing first. If you’re building a mobile application that allows you to assess vehicle safety, you want to be able to actually perform the assessment. That’s the most important thing. The next most important thing is being able to see the results of your assessment. Does it matter if someone can log in to the mobile app if they can’t do an assessment or see results? We work on the most important thing first and add new items to a backlog (a list of all the things we want to do). The backlog can change as we learn new things which is why…
A key feature of Agile practices is accepting that we don’t know everything up front. This means that the scope of your project is variable. We don’t know 100% what we are building yet, even if we’ve done a discovery phase. The only way to truly measure the value of a feature or product is to get it into the hands of users and have them start using it – that way you can see if it’s delivering value and potentially start to shape the next iteration of the product.
Seeing someone interact with your product will likely result in a feature, function or improvement for the product that you never thought of in the first place. This can feel really frightening. However, why should you sign a scope of work that doesn’t give you the exact details of everything you will get?
The answer isn’t simple. You can sign a fixed deliverable scope of work like that, but it doesn’t give you any space to learn during your project. It assumes you and your partner firm know everything up front but, to put it bluntly, you don’t and won’t.
The only way we can know what work to prioritize (and if we are on track to build the right things) is to have you and your stakeholders involved in the process. After all, no one knows your business better than you.
We typically tell our clients to expect to spend about 5 hours per week on the project. We will have questions about how your business works, what we can push to new heights and what we can’t, and we will discover a bunch of new things together. The best way to get the best product is for you, your stakeholders and your business to participate in the process. We both want the product to be the best it can be and you’re spending lots of money on it; you should plan on being there for the ride.
This might sound a bit scary and different, and you might be asking why you should work with an Agile firm.
There are a few things that help you determine if this type of project is right for you:
There isn’t any one right way to run a project or build a product, but it’s always valuable to work with users early and often. And the best way to do that is with working software. Methodologies based in Agile can help you do that more efficiently, and also leave room for change in the project!