Agile methodologies have long become a staple in the software development industry. They boast a much higher project success rate compared to Waterfall (42% VS 26%) and a significantly lower rate of failure (8% VS 21%).
That said, the main strengths of agile or lean development cycles are also their greatest weakness: every business process was designed for developers by developers. People from the business side without a coding background simply don’t get how these processes work.
A lot of agile software development principles make unaffiliated people believe that having a team of rockstar engineers is all it takes to succeed. They are, after all, capable of managing themselves effectively, covering their code in tests before deployment, and releasing the product.
Why would a sane person invest in consecutive third wheels then?
Here’s the thing: developers did indeed create the agile manifesto with people who have a tech background in mind. What they did not consider as a possibility is that people who are lacking said experience might misunderstand the statements.
Here’s an example: according to agile principles, a team is self-managed. So, according to plain old logic, there’s no need to hire a manager. And yet, we can very clearly see hundreds of agile projects falling victim to poor management.
Another example: saying that working software is more valuable than comprehensive documentation doesn’t mean there shouldn’t be any documentation at all. Solid documentation is a crucial aspect of scalability when new talents are introduced or a change is to be made.
Responding to change does not mean not having a plan in the first place but rather means iterating the project to fit the initial vision and the needs of the customer in a better fashion.
The same can be said about the roles in an agile team, such as DevOps and QA engineers. They, despite not being software developers per se, are as crucial to the overall success of your project as any other cog in the wheel.
Proper balance and planning are as needed in a lean software development team as in any other business department.
Speaking of the team: who do you need in your lean software development team for the project to succeed?
To understand the value of DevOps, we need to put our finger on the principles of lean software development:
- Increasing customer value as defined by the customer;
- Identifying the perfect value stream or, in simpler words, the order in which tasks are prioritized;
- Establishing an efficient workflow so that the results are delivered without interruptions;
- Stabilizing delivery so the product owner can get the features they need on time;
A DevOps specialist, or a person who combines competencies in development and operations, is there to ensure that the entire process works like a well-oiled machine. They do so by taking charge of a multitude of roles throughout the development lifecycle:
- The release manager: These professionals coordinate the project from development to production. Think of a release manager as a Project Manager who deals with the technical aspects of development rather than the business aspects of it.
- The automation architect: Given that DevOps emphasizes automation, this role is probably the most crucial of them all. Their job is to pave the path for the developers and QA engineers to do their jobs faster and more efficiently.
- The utility technology partner: A utility DevOps will ensure you can implement changes to the product without overcoming strict restrictions that system administrators usually hide the vulnerabilities of their servers behind.
- The security engineer: These professionals ensure that the project is built with security in mind from the ground up rather than test the finished product for vulnerabilities or breaches. There’s an even greater number of roles a DevOps engineer can fill. The bottom line is you should treat him or her as the bridge between two parties looking to accomplish the opposite: developers with their thirst for a fluid, changing system and operations with their need for stability.
That said, you probably won’t need a DevOps engineer for a small project or in a startup environment that has adopted Lean development ages ago.
Quality Assurance engineers are typically seen as people who test the finished product before the release to ensure there are no bugs. This approach is fundamentally flawed as the cost of fixing an error in production can grow to a whopping $10,000 if compared to $100 per fix on the requirements stage.
In simpler words, the role of Quality Assurance engineers in Lean development projects lies in preventing defects rather than fixing them. They will be responsible for designing the specifications of acceptance tests before the development cycle begins. They significantly reduce the volumes of waste (unnecessary work) and save your budget for actually developing and implementing new features.
You can run a successful project without a QA if you have a seasoned veteran PM, Release Manager, and Automation Architect at your side. That said, communicating the principles of acceptance to technical people will still be a challenge.
As mentioned earlier, agile teams are self-managed. This, however, doesn’t mean a team can steer itself towards success without a clear vision.
An effective Project Manager charts the future for the team, but he or she is not what one might call a visionary. The key responsibility of an effective PM lies in identifying and preventing potential impediments for the team. They are responsible for managing the activities of individual team members and aligning them with the bigger picture.
The PM is also the bridge that connects a cross-functional team with the ability to shift efficiently and adapt to such changes as:
- Introduction of new features
- Changes in compliance demands
- A negative (or positive) response from a market towards a feature or a product as a whole
- Financial market volatility Some roles of a Project Manager can be replaced by a Release Manager and an effective QA, but you will still face hard times explaining the business logic, the target audience, and the overall scope of work to the developers. And you will still need a person who can convey the business vision in detail to the team of engineers.
You wouldn’t have your own home built without the perfect combination of architects, designers, construction workers, and security engineers; neither should you start a development project without an appropriate agile team composition.
The same can be said about a lean development team.
Design your team with efficiency in mind, and you will succeed. Or find an experienced and trustworthy contractor so you can entrust team choices to them—as long as they justify those choices solidly in their communication with you.
Previously published at maddevs.io/blog