Benefits Of Agile For Businesses

What is the point of Agile for businesses?

For 8 years of my career as a software engineer, I have always worked in Agile. Its meaning is in the flexibility of switching priorities and allocating for improvements. This helps to focus on my main goals and decrease time-to-market. Nowadays small and medium businesses can't survive without Agile practices, since the market is constantly changing along with political and economical situations.

With Agile the business gets the ability to reconsider priorities and goals at each agile iteration and correct the development of particular features. Agile iteration with Scrum takes usually 2-3 weeks, with Kanban, there are no iterations, development is kind of linear but demos and retrospectives may be scheduled recurrently. With Kanban, the team should have a board with development phases and members move stickers on the board to always have visibility of progress and impediments.

It is also worth noting that with Agile, customers or a business iteratively sees what is being developed on demos and gives feedback. At such meetings, everyone from the development and business team may be involved in the discussion. In such a way, there might appear new vision or ideas, also may be provided instant estimations and ideas feedback since all involved parties are there. I think such a process is much better for the team than getting requirements from the top management and find out that it can't be implemented due to some restrictions or gaps.

Can Agile development methodology bring additional profit or save money for the business?

Agile allows you to start a project with lots of unknowns then discover and define them later, while the first part of it will be already in development. Nowadays business cannot survive without a timely response to the situation around, like industry changes, innovation, best practices, political and economical situations.

Sometimes the emergence of some new technological capabilities that were not predicted at the beginning can change the target audience and application architecture of the future system. For example, such changes are important for introducing e-commerce products, whose users are very demanding since new technologies appear every month. In the case of a Waterfalls methodology, such flexibility and speed of response to the needs of the user and client are not possible.

Working in Agile as a company, you will adapt and roll out new changes at the usual pace without problems, while the Waterfalls way will drown in broken processes when it is necessary to drastically change something.

Moreover, such methodology allows experimenting directly in the production for example conduct A/B testing to test hypotheses and choose from alternative options the scenario that receives the best users reaction. Such knowledge produce changes which lead to economic effect even before the project is completed.

Can Agile become a problem for a team and why?

This may become a problem once involved parties do not follow methodology rules.

For example when businesses or customers decide to increase the already committed scope of features which increases the scope of development work. This leads to decreasing quality and test coverage, stress, broken deadlines, and tech debt. After multiple months with such a pace project will slow down in development since to add new features team will need to rewrite half of the project due to crutches everywhere and production bugs due to lack of testing automation.

To decrease communication effort the definition of done must be defined for all stages, such as requirements ready, story ready for grooming, story ready for development, task ready for code review, task ready for merge, feature ready for merge, testing completed, deployment done, ready for demo. Each involved party must do the right work with the right quality. 

Are the Agile teams very effective?

Indeed, for some time during several sprints, while the team is working, efficiency increases then it followed by a period of usual productive functioning. Actually, this is not only with Agile.

Typically for small or midterm projects, the team is stable from start to finish, but when developing a product, everything is a little different. The life of the product is much longer than the project, and in real practice, the Agile teams that worked together disintegrate within 1-3 years, reorganize as people  grow, and want new tasks, a change of environment or rotation. And then new people come to the team which decreases the efficiency and development speed. So when planning long-term projects or product development it worth taking this note into account.

In the case of scaling the development team, it should be split into squads by 3-7 people and placed on different product areas to decrease communication effort and merge conflicts. This may require having separate backlogs.