We may be at peak "Agile" in the industry.

This was probably inevitable, but like many things of real value, once they reach the mass market, a bunch of people make a grab for money by slapping the name on everything.

If you’ve worked with a team that was “agile” and didn’t like it or it didn’t seem to work there is a good chance you’ve been victim to one of these hucksters. Honestly, they mostly mean well, but often haven’t quite grasped the basics and instead are following an overly strict set of rules hoping that good things will just happen.

Chances are that today, if someone says agile they actually mean Scrum, or possibly Kanban. But these are “just” frameworks that seek to give a process to follow in managing projects in a roughly agile way. They can both be amazing and can also be so completely mismanaged that you will think they are worthless. We’re sorry if you’ve had that experience.

Without saying we liked Agile before it was cool, it is worth digging into the principles behind it to understand the original foundation. And just maybe, get back to some purity of purpose.

The principles of agile software development have been around since probably the late 1950s but were crystalized in 2001 with the publication of the agile manifesto. You can still go read the site. Be prepared, it is like using a time machine because it looks like it hasn’t changed since then. We’re going to briefly go through each of the principles that contribute to this manifesto and give you our take on it.

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

The value of this first principle is twofold. First, it focuses things back on the reason we have a career in software. We are in the business of meeting customer needs. There are so many voices and priorities that it is easy to fall into the trap of misplacing this. Barely a day goes by without seeing an article on why some framework is going to fix all your problems. Hosting giants pump untold millions into pushing their new architectures to industry thought leaders. Patterns rise in popularity and cause developers to build things in a way for fear that they are being “left behind”. This plants an anchor back at the real goal, to satisfy the customer.

Second, it is continuous and iterative. The longer you wait to start getting real use out of your project the more risk there is of failure for various reasons. By delivering at regular intervals incrementally you both reduce the risk of completely missing the mark and missing the industry moment. There is so much that can be said here but there is huge business value in this model.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Agile is specifically advantageous because it accommodates change. This is where the name quite literally comes from. Agile - able to move quickly or easily. If you think things might change between the project kickoff and completion some form of agile will be hugely beneficial to you over discreet project phases fully planned from the beginning.

We say that we welcome changing requirements partially as a reminder to ourselves. Changes are hard, but we value it when a client gives us feedback. It is hard to be told something isn’t right, but it is better to be told early when you have invested a bit of time rather than at the end once the budget has been fully spent and there is no ability to change things.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

This goes along with the first principle, but further explains the recommended cadence for delivering software. It also adds the word “working” because marking things complete that don’t work is worth calling out. This is a common trap for agile teams and less experienced developers. Just because the acceptance criteria didn’t cover something, doesn’t mean you shouldn’t at least ask about it.

The shorter timescale might feel like a no-brainer in our decade, but in 2001 many projects still had multi-year release cycles. If you enjoy getting updates to your software every month or so, you can probably thank this principle for that benefit.

Internally we also push for automated testing and CI/CD pipeline setups. If your project is out of proof of concept the work to set these up at some level can be well worth the initial investment.

4. Business people and developers must work together daily throughout the project.

We know this one is hard, and maybe impossible in some situations. However, projects where there are more frequent and valuable conversations, tend to be more successful than ones that don’t.

This doesn’t mean just a daily standup will do. Standups can be great, but without some serious discipline and experience, they can devolve into a worthless ceremony with no collaboration. This is a reminder that each side brings value to the overall project and communication is hard. If we aren’t getting on the same page regularly we are probably drifting from the target in some ways.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

This one may or may not make sense if your team is really small, but it goes a long way. There’s an expression that a lover will outwork a worker every day. If someone has the skill AND the desire to head something up you want to pick that person to be in charge of the thing. You also have to provide cover and support. If your business has a lot of bureaucracy then this cover is increasingly important. Businesses far on the non-structured end of the spectrum can also suffer in a very similar way. At the end of the day, projects are hard, and having someone who loves the work will provide dividends in the long term.

As a side note, one of the questions we always ask developers when we interview them is how they got into the industry. Almost all of the successful ones tell me they’ve just always been fascinated by technology. These are the people we love to work alongside and the kind of person you are looking for to build your software.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

We live in the communication age, but communication is still really complicated. All the tools we use provide opportunities like never before but also have shortcomings. Face-to-face isn’t always possible and as a hybrid company, many of our team members never see true face-to-face communication. A video call is probably the closest thing to this. Text only can lose so much context that critical feedback can often be misunderstood. Too many sources can make it easy to lose feedback. There are some excellent reasons to prefer other communication modes at times, but this one is hard to beat for information density and effectiveness.

7. Working software is the primary measure of progress.

Yep! Like several other items this short principle anchors us back around the end goal of our work.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Most companies don’t want to intentionally burn people out and most people don’t intend to get burned out. I believe very few people are intentionally out to abuse and misuse others. But it happens anyway. One of the things to love about working in an agile way is that there are many safeguards built into the process specifically to account for common ways that projects go wrong. It is human nature to be overly optimistic about timeframes. People who want to serve often take on too much work. Smaller timeframes and scopes make it way easier to notice these tendencies and adjust.

On the flip side, if you are frequently saying, we just have to make it to the next goal and it will get better, this is a sign things are not sustainable. Projects that are going to be successful have to carefully manage capacity, scope, and timeframes to stay on the rails.

9. Continuous attention to technical excellence and good design enhances agility.

We have a saying, slow is smooth, smooth is fast. We didn’t come up with that one, but basically, take time to set things up right and it will reward you with speed later. For software partly it means we have to stay up to date, but also that we don’t ignore technical debt. We may still choose to have some tech debt strategically in collaboration with the business, but we don’t just ignore it.

10. Simplicity-the art of maximizing the amount of work not done, is essential.

There is a meme going around that says, “I’m going to do what is called the developer move and spend 10 days automating something that only takes 10 minutes a week to do manually.” It’s funny because it is true. Often developers love the process so much that they get carried away. We strive to provide oversight to our newer developers and instruction to simplify things down to the simplest.

Another common pitfall is over-engineering. Are you REALLY into microservices for an application that will only have a few dozen users? Is valuable time being spent to build a feature that MIGHT be used next year? Are you polishing a feature that hasn’t had any user testing yet? There are a lot of ways this goes wrong, but we push too hard to keep working on the most valuable tasks.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

More heads are better than one. Teams that are motivated and given proper autonomy produce the best results. It is really hard to figure everything out upfront. Working with a team to establish goals and requirements and then figure out the details in between is like the difference between pants off the rack and a pair custom-made for you.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

You can’t improve what you don’t measure. It is vital to project success to regularly reflect on what is working and what isn’t. Keep Stop Start lists can be used for this, as well as, retrospectives, or other tools. What you use doesn’t matter nearly as much as ensuring you check in and adjust.

It is really important to have the right people in this meeting and to keep making progress. If the wrong people are there it can cause some on the team to feel intimidated to share what isn’t working. Likewise, if you don’t ever fix or address anything people will eventually stop sharing.

At the end of the day, a lot of processes can encompass and enable these values. Don’t get too stuck on one, but look to apply these basics as much as you can. These principles are instructive and still hold a ton of value for anyone in the software space. Hopefully, a few of these spoke to you and will help drive your endeavors towards greater success.

‍