Since the Manifesto for Agile Software Development was signed and released in 2001 its worldwide spread is simply astonishing. New approach to the project management made IT companies to adapt to the new reality. Now you must react to the changes in requirements your client makes while you present them with another version of software. It might seem terrifying, but really isn’t. What makes Agile so popular? Why is it so much more effective than traditional waterfall approach?
The main idea behind Agile workflow is quite simple. While many businesses may have an overall idea about what they require from the new software, the details might be difficult to state at the beginning. And this is exactly what waterfall approach required – to include everything in the contract, plan the whole workflow and finish it at the desired point. With Agile, the end might not be where the client initially foresaw it, but much closer to actual needs.
In most cases, it’s the finished product delivery that says the most about your company and how it competes on the market. And when you deliver, the software must satisfy your client. With traditional approaches, you deliver what they wanted at the beginning, not what they want at the end. They did not have a chance to take a look at the product while it was being developed; hence, they had no chance to adjust their requirements.
Agile teams are able to avoid what comes afterwards – the spread of dissatisfaction among your potential clients. It is simply because you give your client the opportunity to participate in software development. You introduce the new versions and feature to them, and react to what they say. Change something? Ok. Add an option or two to the feature? Will be done. At the first glance with Agile approach the development of software might take longer, but it is not necessarily a case.
Traditional approach used iterative development. You would plan, analyze the requirements and design the system. Then you code, test and release the finished product. Should any of the six stages finish with insufficient result, you must roll back and do that step again. Of course, with experienced team you are less likely to suffer many delays for that reason, but having experienced team you would not have delays either while using less linear Agile approach.
To sum up, adopting the Agile benefits your company and improves its competitiveness on the market. Thanks to closer cooperation with your clients, listening to their needs and implementation of the changes in the project they require, you achieve better customer satisfaction. And with better customer satisfaction, your company is able to grow, gaining new clients more easily. Put simply – with Agile you serve your client for their satisfaction, while in traditional approach you leave them alone.
The benefits of adopting Agile might differ a bit depending on the size of your company, the approach of your client (who might not want to be constantly bothered and asked for opinion) or the product you deliver. While Agile proved great for software developers, it is easier to adapt for smaller projects for one customer. If you were to develop an AAA game or a new competitor for Microsoft Office, such an approach might not be that effective, because of the wide spread of your clients and their needs.
That said, in most cases companies that adopted the Agile approach benefit from higher customer satisfaction – you build high-quality products that are well suited to their needs even if they at the beginning were not able to state them precisely. Furthermore, with the process of constant delivery of features that are being checked and tested you significantly lower the duration of beta tests, in result being able to release the product faster.
What is important, with constant feedback from your client you minimize the risk of missing important defects of the end product. Any problems are much easier to spot in such a lower scale, than if you were to overwhelm your beta testers or – which is worse – clients with a huge, finished product. Another positive aspect of Agile is the team management. With self-organizing and collaborative team members, you achieve their better productivity, and their constant interaction reduces the need for documentation.
Back in 2001 the Manifesto for Agile Software Development was released signed by seventeen representatives of different programming frameworks, each opposing to traditional waterfall approach. Such development frameworks as Scrum, Kanban, Extreme programming (based on continuous integration), Lean startup, test driven development and many more are since grouped as Agile. The Manifesto stated four priorities and twelve principles for practical implementation of Agile.
As stated, the signatories to the Manifesto values the item on the right side, but much more they value those on the left:
Those four rules are now widespread and used in a whole variety of different Agile, adapted for varying company size, client requirements and specification of delivered product.
Now it’s over twenty years after the Manifesto was released, and it remains up-to-date, being the most comprehensive set of rules for all the Agile software development best practices. The details can, of course, differ slightly, depending which exactly you have adopted in your company. First, let’s take a look at twelve principles behind the Agile Manifesto:
From this list, we can derive the Agile project management best practices that can be applied. The first and most important would be to closely collaborate with your customer, which helps with continuous improvement of the end product – even if it differs from initial conceptions, it is better suited to the needs. Another of Agile development best practices would be day to day communication of team members, that helps find solutions for problems and keep high levels of individual motivation and productivity.
An important rule to apply in Agile is to promote face-to-face communication, both inside the development team and with your customer. Such approach helps build much needed trust and helps find solutions to the problems as well as new ideas quickly. This is a part of building a self-organizing team, which does not need close supervising, splitting tasks and promoting confidence in team member’s input to the project.
The last one of the overall good practices would be to reflect on team effectiveness and improve. This might be implemented in most methodologies according to one of the best practices in Scrum – where in a team retrospective after development iteration each member suggests, what the team should start, stop or continue doing. When such suggestions are applied, they help improve the performance on next stages of current projects and better organize projects, that the team would realize in the future.
Staying with Scrum for a while, it is good to point out the best practices in this framework. The role of Scrum Master is generally well understood: to support Product Owner in management of the Product Backlog, to help overcome obstacles that the Sctum Team meets and to encourage deeper implementation and understanding of Scrum on all levels of organization. What is sometimes overlooked is that a Scrum Master should excel both in technical and social skills, and be empathetic as well as open-minded.
In Scrum and several others Agile framework, the workflow is organized in short (usually two weeks long) Sprints. Some companies tend to forget, that Sprint Planning should be split in three separate elements, which can be summed up in simple questions: Why? What? and How? Such approach helps team members understand the upcoming tasks and their role in a big picture, which helps in finding ideas and solutions to occurring problems.
Such understanding of a project’s big picture and the role of individual tasks can also be achieved with introduction of user stories. They are intended to describe end-product features from the perspective of its user or customer. You build the story, deciding on its main character, expressing their needs and suggesting what could possibly solve the problem.
Compared to an orderly waterfall approach, where you plan the whole workflow at the beginning and realize it step-by-step, the Agile frameworks might seem a bit more chaotic. They require an active participation of your customer, and the development team must adapt to all the changes and remarks they make. The result is often quite far from how one would imagine it at the start of the project.
But, what really matters, is that clients not always are sure from the start, what exactly they need, or they do not have enough technical knowledge to state it precisely. Such a cooperation that Agile approach promotes helps your company to learn your customer’s needs over time and adapt to them, allowing to prepare a better suited software. It is a great way to achieve higher levels of customer satisfaction.
You should, however, remain careful. One of the often pointed out risks of adopting Agile in a company is that they tend to treat its rules too literally. Hence, they may skip the initial requirements and planning, starting the project in total chaos. They may also be prone to accepting fundamental changes in late stages that would delay the delivery and require a lot of additional work, which could be otherwise avoided.
Agile workflow based on the Manifesto for Agile Software Development is one of the most popular management framework for IT companies. Now it is a whole branch, including Scrum, Kanban, Extreme programming and other workflows, which common point is a close cooperation with your customer and highly independent development team. If you search for methods of improving your company efficiency and provide better end-product quality, try to be more Agile.
Wojciech Czujowski
Head of Program and Project Management
An expert in the field of project management, with software engineering background, working according to Agile values. His portfolio includes R&D projects of embedded systems and software for industries such as consumer electronics, mobile and financial services. Vice-chairman of the Council of the Lower Silesian Regional Group of the International Project Management Association (IPMA). At Scalo, shares the responsibility of the company’s technological development and project management standards.