Agile is one of the most popular buzzwords that permeates across different industries. The one thing that agile implementations have in common with one another is that there is always an element of software development.
While everyone seems to know what it is, there is a general lack of real understanding of how it works and how to implement it. We’ve all been there at some point in our careers, only to develop a love-hate kind of relationship with the process management methodology.
For some, agile and continuous delivery feels like a marketing gimmick to get the boss to agree to certain things. For many, it’s implemented incorrectly and often results in headaches, heartbreaks, and hate for it.
But it doesn’t have to be that way, because that’s not how it’s supposed to be.
The current state of agile
There’s a common misconception that agile is just another form of waterfall — chopped up and delivered in pieces to satisfy the need for continuous delivery. This came about because that’s how agile is often described — a project that is delivered in parts rather than a big bang whole in order to keep progress in check and take a product to market faster.
The point of partial delivery is to give the business the ability to test market demands and validate ideas before spending too much time and money on a product that may not work. Agile is often coupled with the idea of delivering MVPs and releasing only based on the bare essentials to kick start the feedback loop.
While there’s nothing wrong with these ideas, it’s the implementation that is often the root cause of the real issue behind agile. The process often starts in silos, with each team doing their own thing and then coming together to produce a product. This is often where things go wrong, as bottlenecks and conversations get lost in a sea of bureaucracies and in-between management. The ideas behind agile aren’t the issue, but rather it’s implementation and how teams are composited together.
Agile isn’t just agile
Agile is often talked about as one word but its not. The process began its roots in software and has always been software-centric. Yet developers are often the last group to be consulted, if they are consulted at all. While everyone else seems to have a say in the processes and everything in between, developers are often tacked on at the end to create something out of visual plans that may or may not be feasible.
Then there are those attempts at agile that requires developers to start coding when nothing is quite decided on yet. Because why not? If waterfall is the epitome of over-planning and attempts to micromanage tasks, then the opposite approach is to deconstruct the process and just let developers code.
But that’s not how software works.
Building sturdy and functioning software is akin to building a house. You can’t just tell your builders to start building and call it a day. Developers are also more than just builders of software. They are also your architects and engineers — two very distinct and additional roles in software development. Multiple moving parts need to be coordinated and delivered in a particular sequence for agile to delivery its best possible result.
Getting it right
Agile software development can increase your business’ velocity when implemented correctly. But what does correct look like?
It’s a hard one to pinpoint exactly, but the common traits which exist between successful teams are that they are small, cross-functional, multi-skilled, self-sufficient, and have a high level of meaningful communication between members. While skills and tasks may be assigned based on a domain of expertise, each member is consulted throughout the process of software creation. Members of an agile team tend to have cross-functional skills that allow them to move between the different parts of the agile release and enrich each other by expanding the edge of their knowledge base.
The more members there are in a team, the slower your final delivery velocity will be. When your agile team is flat and small, there is less complexity to deal with when it comes to feature creation. Software is already complex enough without the additional layer of human and organizational based complexity.
Planning is still required before developers start coding. However, rather than having every possible feature written out with full specifications and then stuck onto a board, only a select few are placed in the current and impending backlog with a clear idea on the business’ vision, strategies, goals, and how the software is going to support it.
The importance of meaningful creation in agile
When it comes to agile software development, meaningful creation is the key to driving delivery. This means that a clear and concise goal must exist as fuel. The point of agile is to assist the business, but to do this, the business itself needs to know what it wants. Without this, the team cannot adequately make independent decisions and respond to demands and changes.
To achieve this, everyone on the team needs to be clear on what an agile sprint is doing to benefit the business and its strategies. Only then can each member align their skills and knowledge in a beneficial way. Everyone has their domain of knowledge, and the alignment of these skills to produce software that has a purpose can result in a highly effective and creative release.
Understanding of the business’ vision and strategies enables teams to create meaningful products to support this.
Final words
Agile isn’t about the number of people in a team or a set of requirements delivered in parts. It’s about the relationships between team members and how their work contributes to the betterment of the business.
It is also about forming a highly cross-functional skilled team that can move between different domains of work without feeling like a fish out of water. While everyone still has their core expertise and jobs, the ability to move between the different domains means that the team can speak the same language.
Communication is one of the biggest factors for successful project delivery — next to the team understanding exactly what they’re doing and where they’re going with it. Agile is a journey of creating meaningful software that helps the business achieve its goals. Each completed delivery is a step forward — except the biggest difference between agile and waterfall is that the latter has a clearly defined and set path that allows for no deviation.
Agile is more a scenic route than a set route. It has a larger band of flexibility and can lead the software down a detour if the destination and path towards it are not carefully monitored.
