Agile development for software engineering

Editor's Notes

• #12 In short, this means we should release early and often to benefit our customers. Iteration and feedback are at the core of what it means to be Agile, referred to here as “early and continuous delivery.” Early delivery is important because the longer it takes a customer to see the direction of a project the more likely it is to diverge from their expectations and requirements. Meanwhile, continuous (and consistent) delivery helps the project maintain a rhythm while allowing for iterative review along the way. As we’ll see in the other agile principles, sustainable development is key to being Agile!
• #13 This second principle means that we should be willing to make changes to stay competitive, and it outlines a common fear to address when becoming Agile. Chances are high that when someone studies Agile they’ll wince when they get to the part about “changing requirements,” but it’s absolutely necessary and one of Agile’s core strengths. Adapting requirements as more information is gathered ultimately leads to the production of an effective and competitive product which is important in the long term. 
• #14 The third Agile principle is likely known even by fringe Agile users, and it boils down to trying to release on a shorter frequency. If you’re familiar with what Scrum is, this would refer to “sprints” where work is planned for one or two weeks after which working code is presented to the team. This shorter delivery time allows teams to get earlier engagement from clients and stakeholders, which Agile uses to adapt to changing requirements (callback to principle 2!). Like the other suggestive agile principles, this one allows for the idea of month-long time periods but puts the priority on smaller intervals when possible.
• #15 Number four can be a major hurdle for becoming Agile, but in essence, it asks that you include both the business and tech groups in daily work. In this case, daily work is considered anything your team does on most days like status updates and the internal discussions that happen between scheduled meetings. By looping in both sides throughout the process – like when making a notable on-the-spot design decision – the communication channels will be open so everyone is on the same page and immediate feedback can be given if necessary. The added perspectives help to make sure that important details receive adequate attention before they get baked into a part of the project. A common rebuttal is that doing this will cost more time, but this should ideally optimize those long checkpoint meetings by dedicating less time to getting up-to-date and more time towards planning the next phase. I am also confident that anyone reading this article has recognized disconnects between their tech and business teams in the past, it’s not only common, but it gets worse when projects get faster or more complex. Recognizing gaps early and often is a cornerstone of being Agile, and with how large gaps can grow between business and tech teams it’s imperative to stay on top of things
• #16 Agile Principle 5 focuses on giving passionate teams room to work. It’s easy for a team to lose motivation – we’ve all been there – but building that passion is great for the project and the people. Using motivated individuals to build a product and giving them the tools to really shine is a great way to turn a project into a work of art as opposed to just another task – this is where principle 5 comes in. You can start by finding ways to plan the project with the team, like adding some leeway to the structure so a team member can show their ideas or section out work based on individual interests. As the project starts to build momentum, follow up with your team to see what they need in order to be successful. This is what most teams do when trying to build motivation, and the closer this is to the project-building step the easier it is to do. Notice how this agile principle doesn’t mention speed or efficiency? This is because being Agile is also about doing things well – why make software quickly if it’s not good?
• #17 Truly a principle not written in 2020, number 6 tells us that information is easiest to convey with personal communication. Email, texting, and other messaging platforms all have their own benefits, but it is usually at the expense of overall effectiveness for relaying information. Effective and efficient conversation comes from hearing someone’s voice and seeing each other’s expressions.  This of course relates to face-to-face communication, but in today’s world companies have noticed (or have been forced to notice) that this can be translated to video calls for remote work. The expressions are there, you can be heard, and you can even record the conversation giving it every advantage for effective communication – unless of course you think smelling someone is important. Communicating clearly is important to Agile and non-Agile teams alike, but given Agile’s frequent engagements this principle warrants special consideration.
• #18 Agile Principle 7 – my personal favorite – is the often incorrectly done task of measuring software in working features. You may have heard of the Ninety-Ninety rule that says when a software task is ninety percent done, the final ten percent takes just as much time to complete as the previous ninety. This makes light of the common pitfall of measuring a task by what’s been developed so far without accounting for testing, things breaking, revisions, refactoring, and all the other reasons we’ve attached to timeline extensions. By measuring the progress of what has been completed, you plant your feet and say “this feature works, and the client accepts it” indicating that your team is now ready to focus on something else. As you can guess, working software doesn’t just refer to the final product, it also refers to the deliverables in principles 1 and 3 in which every iteration should have a working feature to show the client. Tracking outputs is a key way to validate that your Agile process is functioning effectively.
• #19 The bane of any crunch-time enthusiast, principle 8 specifies that an Agile process can be done indefinitely – without the development team combusting. Having to regularly put in extra time to meet deadlines can quickly wear down a team. This kind of pace is sporadic and unsustainable and by definition not Agile. This does not mean you have to work slowly, it just means you have to work at a pace that’s sustainable – be it slow but deliberate refactors, or fast but calculated deliveries. Though a senior project manager would never think of a project’s timeline as indefinite, it’s almost guaranteed that there will be post-production work that can build up over time. Chances are that if you crunched to deliver a project, you’ll be under pressure to address the issues afterwards to stay in line with that precedent of speedy delivery. Specific processes aside, if you want to be Agile you need to organize your process so that it can maintain its pace. If you don’t think your team can follow your processes consistently, changes should be made.
• #20 The 9th principle is hard to commit to for any corner-cutters as it specifies that agility is improved by doing best-practice work. During a software project, it’s enticing to save time by doing something less-than-excellent, despite the fact that it could save time in the future if good design choices were made now. Making your attention to excellence continuous (there’s that word again) improves how you handle complexity in the project, which as we’ve mentioned, is part and parcel with Agile. Committing to good design makes the code require less upkeep and reduces the technical debt which can slow down projects later on. Part of being Agile is making it easier to move fluidly through the entire lifespan of a project, so if doing something now would make development easier going forward, consider doing it.
• #21 the most likely to be on a LinkedIn post, talks about simplifying the scope by identifying what we don’t need to do. This is about working smart, not hard. By recognizing what adds value and what doesn’t, you can choose how to allocate your resources to best serve your project. Aim to identify what is and isn’t necessary, and use that to focus your efforts. Early on in a project, this often takes the shape of a Minimum Viable Product (MVP) – working software that meets the primary use cases of its audience while leaving out the bells and whistles.
• #22 In addition to being passionate, principle 10 asks that your team is also self-organizing for the best product. A self-organizing team is a group that can plan, estimate, and complete work by themselves while proactively engaging stakeholders as needed. This is a tenant that could fill an entire article, so for now, let’s focus on the heart of the principle. Letting a team organize itself can be a hard sell for management but it’s all about saving time over the duration of the project. Managing a team is a lot of work and usually requires sizable meetings to give direction and understanding, but a self-organizing team is simply given a high-level primer and then allowed to run from there. Add this together with Agile’s iterative nature and regular engagements and control comes back because even though the team is managing themselves, you get to jump in more often to redirect the project as needed. This principle is hard to fully commit to right away as it involves trust, but if you want to be Agile you’ll want to give your team some leeway to organize themselves, even if it’s only a little bit to start.
• #23 Finally, at principle 12, we talk about the heart of Agile principles: ensuring teams inspect their process and adapt frequently. None of this will be executed perfectly on the first try, even if you get a professional to implement Agile principles for every team they’ll adapt it to your unique team and business using reviews and retrospectives. Throughout this article we’ve called back to previous principles, but this one can be referenced in every instance of Agile because no matter what you’re implementing, you should make time to inspect what you’re doing and adjust how it works until you’re comfortable.