Real Agile brings real benefits to everyone involved in software development, from business to development teams.
Currently, there are fewer and fewer teams working in methodologies other than Agile, while the level of their maturity is very diverse. So are they Agile, or are they only Agile in a name? In this article, you will not find the definitions used in Agile methodologies, but you will find out what we think is important for a team to be Agile.
Agenda
Methodologies
In our daily work, we use agile methodologies such as Scrum or AgilePM. We derive the best from these methodologies, which makes us work better and better with each sprint. We know what is important and what is not, what problems the business world has in the IT area and how we can solve them. There are many publications thoroughly describing each of the methodologies we use, but look at how we see them at glance…
Scrum
The scrum methodology is characterized by the pursuit of the scrum team towards a common goal in an iterative approach. The team gains knowledge and experience with each successive sprint, which is the basis for further improvement of both the effectiveness of the scrum team and the resulting product. Scrum gives the opportunity to focus and constantly focus on the business need, or to ensure the right speed of adaptation to the changing environment and market, which is crucial for the project’s success. "Gives the opportunity" was used consciously, because scrum alone does not solve anything by itself. It only gives the framework in which the teams operate, while the effectiveness depends only on the level of maturity. It is important to understand that the true value of Scrum is not measured by running scrum events or by producing artifacts, although they are very important. The real value of scrum is when the team takes full responsibility for the implementation of a given business initiative from start to finish, supporting it with all their experience and knowledge. The success of the project is the success of the team. This is the essence of Agile.
AgilePM
After the first fascination with the Scrum methodology, part of the business world saw that, from a formal point of view, Scrum alone is not sufficient to manage projects. Therefore, as a result of evolution, a methodology was created that combines the Agile world with the features of classic methodologies such as Prince2 or PMBOK. In such project management, the intensive participation of business in the process of creating a solution is important, often it is a person delegated to such work. It actively participates in the production process. On the one hand, it facilitates faster decision-making, and on the other hand, it is the allocation of additional resources. AgilePM is, however, quite well scalable depending on the situation and the complexity of the project. The main goal is to meet the business need, reduce the excess of formalities, and deliver on time. Below are the main differences between the Classic and Agile approaches.
The development team has an impactful and important role and a lot of freedom of action. Priorities set with MoSCoW are defined for a given analytical session within Timebox (like Sprint in Scrum). The work is divided into individual Timeboxes (defined by the manager), which make up the increments and, as a result, complete the project. The team is as follows
3 Magic roles
Our scrum team consists of three main roles that have their tasks. Each of these roles in its way contributes to the final success while taking care of other aspects, such as efficiency, transparency, quality, etc. So, see how the following roles work in our scrum team.
Scrum Master
Team mirror. He makes sure that the team is agile and applies good practices. It presents situations that took place in the team’s work along with their consequences, without judging anyone. All the time facilitates the team to strive for excellence and keep the business need in sight. The Scrum Master sees more than others, it can catch events and behaviors, both positive ones that need to be strengthened and negative ones that need to be eliminated.
Product Owner
Ruler of the backlog. The main activity (apart from creating a backlog), which the Product Owner contributes to the final success, is the appropriate prioritization of backlog items, taking into account many aspects, such as business value, production complexity, or hard KPIs such as RoI. He listens to both businesses and reacts to their needs, through the appropriate organization of the backlog, specifying the scope of the MVP, as well as the development team, ensuring the effective use of the team’s power and the greatest possible functional gains. Product owner combines the development and business worlds.
Development Team
Main productive power. To obtain a large increase in the business value of a product, our team is properly motivated and focused on the business value of the generated increment and has all the necessary competencies to implement projects. The development team calibrates its way of working in terms of meeting business needs as effectively as possible. It does not focus on his work in isolation from business needs.
Power of Definition of Done
One of the factors that can tell a lot about the team is their definition-of-done. It often happens that in order to meet definition-of-done, the team has to leave its comfort zone and perform non-standard, unconventional work, often uncomfortable and difficult. Only teams with the highest level of awareness can do this uncompromisingly. It is thanks to the fulfillment of DoD that the final product is reliable, scalable, and above all meets specific business needs. Our definition-of-done, which we have developed over the years of our development work, is as follows
Power of iterations and empiricism
Adjusting backlog
in Agile, the backlog is modified on an ongoing basis, along with the changing business and environmental conditions. This is a huge advantage of this approach, as it allows for corrections to the original functional assumptions. Such a correction may occur both as a result of research and feedback from the market from the end customer. In the waterfall methodologies, after a certain time from the start of the project, it often turned out that the final product is no longer valuable because in the meantime the conditions and business needs have changed, which has not been reflected in the product. In Agile methodologies, the functional scope can follow the business needs on an ongoing basis, so at the end of the project, we can assume that the product will meet the vast majority of current (at the end of the project) business needs and its functional scope will be up-to-date.
Improving efficiency and workshop
After each sprint, the team verifies how it contributes to meeting business needs. This is the time when he looks critically at his way of working and technique. If something works well, it strengthens those actions, and if something doesn’t work well, it introduces corrective actions. Such activities may consist, for example, of the use of other tools, better suited to the production process, or the expansion of the team’s competencies.
Well-sync development team
A well-focused development team is aware of the importance of applying appropriate work standards. Thanks to them, we achieve many benefits that are visible from the first sprints. Thanks to activities such as the following, our team is responsible for what it does:
-
automatization CI / CD with pipelines,
-
automatization cloud infrastructure building
-
using standards and best practices
-
static code analyze with quality gates
-
test code coverage> 70%
-
automated e2e tests
-
multiple environments building including dev, stage, and production
-
no crons, no nightly builds, no manual activities, no potential failure points, no manual tests
-
realization compliant with definition of done
-
etc. etc.
Summary
Check how our team works and what is important to us. Remember that only a well-motivated and focused team will do a lot of valuable work for you and take over many responsibilities. Only in this way can we build long-term relationships.
OCPP v2 in eMobility