The agile manifesto has been around for a long time and is old news for many organisations. However, there are still many who are about to, or have just begun, to face the introduction of more agile ways of working with IT development. How does this affect the final result, and does it increase the chances of getting the systems and solutions the business needs?
Here I, will explain some of the problems regarding requirements and needs that I experienced when switching over to agile working methods, and what I think both businesses and IT departments need to consider in order to really achieve the results they want.
Agile methods often mean leaving a classical – possibly heavy-handed – methodology behind, and instead moving the focus towards a more adaptive and situational way of working. RUP was often perceived as heavy, with lots of documentation that were to be generated based on templates, by specific roles and according to defined workflows . Even totally obeying all the instructions would often still fail to deliver solutions that were perceived as good given the desired effects. In addition, many felt that they created a huge amount of documents that were never used. It sometimes became more important to follow the plan than to reach the right goals.
Read more: BI pilot project completed – updated data on customer’s sales and production
Thus, many saw it as liberating to instead focus on individuals and the interactions between them, on functioning software rather than extensive documentation, and on adaptation rather than following a plan. It’s liberating to work in teams that can handle the tasks they are assigned, without being told how to get organized or exactly how to perform the work.
Previously, we spent a lot of time trying to explain the goals, needs and requirements in detail before writing the first line of code. When we delivered the solution, it often turned out that the detailed goals, needs and requirements actually wasn’t completely correct – either because the conditions changed or because we did not really understand them, and therefore made some incorrect assumptions.
Now by contrast, we want continuous improvements that are matched by incrementally developing solutions that provide the necessary benefits. This way, we can adapt and learn more about the goals and needs during the journey, and we don’t run the same risk of taking incorrect decisions early on, which then remain in the final delivery.
The price of freedom
But do we always succeed better just because we take on a more agile way of working?
Of course not, and there are a number of factors that influence how well we succeed with IT projects. The size and complexity of the solution, as well as the access to competent resources still have a significant effect on the success of an IT project, regardless of the methods. If the business isn’t on board with agile work, it’s easy to lose the ability to verify and validate what we deliver. As a result, there is no help to gradually understand the picture of the goals and problems. This leads to losing some of the benefits of working with an agile methodology. If we are buying a ready-made solution or knowing all the requirements right from the start an agile way of working may not be the most effective way to work.
At the same time, I feel that some of the problems we have are due to how we handle the freedom that the agile method entails. The agile working methods are generally freer than, for example, RUP, which means that, for better or worse, we don’t get as much help with how we should work, what to create, or who should do it. Unfortunately, this often means that we forget about the important parts of the development work.
The need for competence remains
In my experience, the transformation into agile working methods and organisations often means throwing out the detailed role- and work descriptions for the project, as well as all the templates previously used. Not infrequently does this freedom mean forgetting that although working in a new way, we still need to perform more or less the same work as we did when we worked according to the classic development methods. A backlog does not appear spontaneously out of thin air, it needs to be well-founded even if all the details don’t have to be in place before we start developing. In addition, it needs to be adapted and improved over time. The team that develops and works with the system may not remain throughout the lifetime of the system, or isn’t even the ones operating and maintaining the system, so it may also be necessary to document how the system is supposed to work.
Even if we have thrown out all role descriptions, we still need the right skills. Some are obvious – if we have no resource that can program, then nothing will be developed. Other skills seem self-evident, but in my experience they are usually forgotten to some degree or another. If nobody has sufficient competence in IT architecture, we risk creating a solution that doesn’t fit into the existing and future IT environment. If there is insufficient competence in testing, we risk carrying out insufficient integration, performance or penetration tests. Different people often have deeper competence within one or a few different areas of expertise, but rarely all together. Although it is said that developers need to have understanding knowledge about the business, I am inclined to believe that developers with cutting-edge expertise and deep knowledge about the operation or business don’t grow on trees. To get the right skills, we often need to use specialists, and therefore a number of different people with different skills. Not having role descriptions with the corresponding responsibilities does not change this, but it seems to be forgotten sometimes.
Read more: Don’t build stable IT systems
One of the roles that becomes obsolete with the agile working method is the requirements analyst. The product owner is often required to create and maintain the backlog and create user stories that can be used to build a solution that creates values efficiently. At the same time, the product owner must have mandate to take decisions and understand how different decisions affect the business or operation. This works well in some cases, but far from always. Sometimes because it’s difficult for a person to catch up with everything, other times it’s because deep expertise is required in several different areas, more than what one individual has.
We need people with expertise to help stakeholders describe their actual needs, to distinguish between wishes and needs, and to create specified requirements that are accepted by relevant stakeholders, described in a way that makes it understandable to those who will use it. We need people who can analyse and understand the consequences of how different requirements affect the solution and how it can be used. We also need people with the skills to design a solution that meets the needs of the stakeholders, both in terms of system requirements and usability.
We often mix up development and solution
The focus of agile work is often on the actual development and the work that must be done to deliver a good solution. There is however an important difference between what we create or change and the final solution, and this is often missed. We use Kanban boards or Jira, follow up burn down charts which shows what we do, create or change, but it’s easy to forget about documenting the solution. This problem has always existed since people in the projects tends to be more interested in knowing what to do and deliver, rather than how the whole solution they leave behind actually works and its qualities.
In my opinion, however, the latter is often just as important, since an understanding of how the solution works and how it can be used usually is necessary to maintain. It is difficult to get an idea of how a system works based on the activities performed or user stories implemented in different sprints. Therefore, we need to understand the difference between requirements for a change and requirements on the entirety. Requirements for a change are needed for us to understand what change we are going to make, and can generally be seen as a description of the work to be performed. This description concerns the development and has a lifecycle that will end when the change is implemented. It is a working document that applies to the project. Requirements on the entirety are needed for us to understand the whole solution and not just the changes that have been made in a project. Its lifecycle should be the same as the solution’s. That is to say, a change of the solution should require that the requirements on the entirety is updated so that we always have a correct picture of the solution – it is a document related to the product/solution. Depending on the needs of developers, tests and management, the level of detail between these two types of requirements may be different. And if one type is not needed, we obviously do not need to document them. But we must understand the difference between these two types of requirements.
In my experience, requirements for entirety are not always created, and they are rarely maintained together with the solution. I myself have delivered solutions where the client absolutely did not want to have an overall picture, having only been interested in changes — and after a couple of releases, they did not have a clue as to how the solution was meant to work.
The idea is that the agile team will manage and further develop the IT solution, and then the solution may not need to be documented – the team already has the knowledge needed. But it’s rare that the team remains the same over the entire solution’s lifecycle, or it may not even be them who will manage the system. In this case, it may be important to actually document the solution.
Conclusion – freedom with responsibility
Freedom is good, but freedom means that we really need to consider what is needed in terms of resources and deliveries in each individual case.
It is important to obtain the necessary resources. We need, among other things, to ensure that we have people with expertise in business- and system requirements. These people need to be able to work with the development team and with the stakeholders as well, but we must be careful not to create a set of filters between the stakeholders and those who will implement the solution. Part of this responsibility lies with these people in that they must not distort the requirements and needs or create requirements without real needs behind them. But we also need to ensure that these resources have access to the stakeholders to the extent required so that they receive correct information when needed.
In order to ensure that we do not miss anything, we should look at more traditional development methods to ensure that we don’t forget important deliverables, activities or competencies when we work with agile methodology. Make sure you deliver what needs to be delivered – not just in the form of change but also in terms of, for example, descriptions of the entire solution. Understand what needs to be documented, and the level of detail required for different types of documentation – for example, change descriptions versus solution descriptions.
We need to make sure that an agile organisation and an agile approach are not used as a way to cut development costs by forgetting or removing the skills and activities that are actually needed.