Do we still need projects?

One ultimatum of agile methods is to make projects unnecessary. But what does this mean? Will we not try to finish anything anymore? Or do we not need a plan for work anymore?

If successful, the agile method is better in both respects: it helps us achieve more and plan more efficiently.

What Is a Project?

Let’s start with what a project means. A project is a temporary spell during which a named group of people carries out something on a certain schedule and with a certain budget. A project has a plan that defines its tasks and output. So when you need a new product or application, you make a plan in order to determine the cost of making it. The project is more likely to succeed if we communicate and guide the work more precisely, in addition to monitoring the budget through a schedule and working hours. The quality of the plan also affects the project, as the more precise the plan, the better we can account for any risk scenarios.

A project is a temporary spell during which a named group of people carries out something on a certain schedule and with a certain budget.

But who in this model monitors the project’s completion, the fulfilment of the need, and especially the realization of the business model? The temporary nature of the project, as well as hierarchical planning and management, also lead to wrong choices of resources.

I often have to hear stories about a project having been 50% successful: how we were able to use the budget in the planned scheduled, but the product was not quite completed. A project also has a great tendency to expand uncontrollably in size in the planning phase. This is only natural in a situation in which we think that we cannot afford to fail in an important project, so we prepare such a good plan that it takes all the possible combinations and their risks into account. We map the scenarios and prepare mitigation plans for the risks. In other words, we need sub-projects for the review and specification phase that, when completed side by side, provide the details for the actual work once we add enough resources. From where can we obtain all these experts – particularly when preparing a new functionality for new customer needs? The answer is nowhere, as the majority of the risks in an extensive project are not detected until during the work itself, even if we perform less experimental work to meet a clear need.

Definition of project work:

– A temporary team that, due to its temporary nature, lacks shared routines, group chemistry, and possibly even experience in the subject and application in question

– A project has a schedule divided into phases

Agile Activity as a Solution?

The greatest change introduced by an agile operating method is project management. There is no significant change to a developer’s work day and none to the development work itself. We also continue to make changes to the code as before and record tasks as having been completed and bugs as having been fixed. So what does change?

If a team is viewed as a unit with a certain utilization rate, its utilization rate can be improved by eliminating idling. The project model results in a great deal of idling.

The development department is most often a bottleneck, at least in most organizations that monitor their expenses. In other words, we will always have more wishes and needs regarding new features than we will ever be able to produce. The product development backlog is long, and bugs, at least the most critical ones, should be fixed. The aim in the lean approach, which the agile approach is also rooted in, is to develop the throughput. This is done by identifying bottlenecks and optimizing the operation of these parts. But how can a bottleneck be optimized?

If a team is viewed as a unit with a certain utilization rate from the perspective of industrial engineering and management, we can improve its utilization rate by eliminating idling. Operating according to the project model results in quite a bit of idling. Launching a project requires waiting for a range of things: tools, access rights, learning and other things. Additionally, in order to ensure good communication, we need to have a kick-off meeting, documentation periods for milestones 1, 2, 3, 4, 5, 6, and 7, status reports and meetings, a final meeting, a lessons learned summary, and many other things.  We could say that the agile model offers a clear solution to this bottleneck problem: the team is a permanent group to whom management “feeds” tasks in the desired order of priority. In other words, the team operates with full power the entire time, or, more specifically, with an efficiency of 100%, when the optimal amount of work has been proven to be roughly 80% of an employee’s working hours. Prioritization, identification of new needs, and sales work are carried out in conjunction with this.

In fact, the greatest change takes place in interaction and manifests as an increase in communication. Information no longer flows only from management to the developers; instead, we have clear communication models for both mutual understanding of the requirements and the progress of the work, i.e., we also have a communication channel in the opposite direction. The agile approach also emphasizes the significance of presence and physical meetings: it is characteristic of humans to also communicate in ways other than formally in writing. In order for us to perceive the solution to entities that are new or difficult to understand, we require stories, i.e., narratives: examples of needs and implementation opportunities in particular.  

Efficient Communication Enhances Work

It is said that some developers are up to a hundred times more efficient than others. One explanation for this is that modern development of applications largely entails using a variety of existing libraries or (cloud) services. In other words, an efficient and capable developer combines existing components and adds the missing parts, thus creating functionalities that are already proven out of parts that the developer is familiar with from their previous experiences. Explaining these opportunities to another party and shedding light on the peculiarities of business operations is difficult when we are not able to present and draw on the whiteboard what we mean.

In order to improve communication, a Scrum model has been developed for agile methods. It recommends iterative presentation events.

The traditional hierarchical model has established methods such as UML, TOGAF and BPML for presenting these matters. The methods work, but they require much effort to use and learn. When we add this to the number of combinations available because of different options, we start to understand the enormous amount of work to which specification can lead to. An application made with the agile model may also include documentation and an exact description with the notation above, but it is only prepared for a functionality that is found to be correct, and without overdoing it to ensure that the other party understands what we want. It is enough that we meet the needs outside the development group, which I consider to include business operations and development in this context. These external needs may be related to the authorities, end customers, and others, for example. In other words, we keep planning continuously but document less in order to avoid unnecessary documentation. On the other hand, continuous adjustment of the direction as the options become clearer guides us to make the right type of application. A functional application that is continuously verified with automated tests and monitoring may suffice as documentation.

In order to improve communication, a Scrum model has been developed for agile methods. It recommends iterative presentation and review events. A demo session is more than a meeting: all stakeholders are welcome to it, i.e., the output of the development iteration in question is presented to everyone interested. The aim of this open approach is to make the progress of the work clear to everyone, and more importantly, to gain information for the next phases of development. In other words, by demonstrating how the system works now and how the completed parts meet the needs, we can give business representatives an idea of what the future system will be like to use and how it will meet their needs.

At best, the completed implementations or library components used will meet a few of the requirements on the development list adequately as such. This allows us to reprioritize the list and even remove features that we consider to be difficult, as they already function well enough, i.e., produce the customer value that we want them to produce. In brief, the purpose of prioritizing the backlog is always to focus on the next most valuable features and achieve as much customer value as possible in every iteration.

Requirements of the Scrum model:

1. The clients/owners of the requirements, i.e., business representatives, monitor the development iterations and provide feedback. They are motivated by seeing and, preferably, trying out completed features.

2. The capability of development teams to make all types of features as ready as possible.

Having Multiple Skills Is a Strength

The multiple skills of the development team have other positive impacts besides the opportunity to prioritize the backlog that is independent of the teams. The lean model seeks to shorten backlogs that arise from dependencies between different parts of the process, i.e., between various resources outside the team in our software production facility. Traditionally, many functionalities that require coherence, such as architectural design or testing, have been left outside the teams. Additionally, architects are sometimes divided precisely into their own areas of application, in which case obtaining approval for an architectural outline may have to wait for the architect in question to have free time or come back from a holiday. When the work of the team depends on a limited external resource, this inevitably leads to waiting or at least a delay compared to the optimal work pace. The agile methodology offers several solutions for eliminating this problem. However, the most important solution is to identify and eliminate the dependencies within the organization. In many cases, dependencies are built deeply into the organization’s foundation, which is why it takes commitment and daring from management to transfer architectural responsibility to the teams, for example.

The lean model seeks to reduce backlogs that arise from dependencies between different parts of the process.

The benefits are easier to understand with regard to testing within a development team. If the team itself tests its output as much as possible before releasing it, it will also identify bugs before the release. This way, we can avoid bug reports, additional testing rounds and other additional work, i.e., we can eliminate unnecessary work, or “waste,” when we do not have to document bugs or take the long and winding road. The team’s goal is to try and deliver code that is as bug-free as possible and fix any bugs proactively before distribution.

We often wonder how we could fix bugs without them being recorded in the bug database. Again, this is a question of assigning responsibility to the team: a bug is not a bug until it leaves the development team. If the developer does not write the bug into the code in the first place, then it is not a bug. Similarly, it the team itself identifies and fixes the bug, it is not a bug. A self-directed team should be able to choose a method with which it manages its own work during integrations. The team can choose to use a bug database, but it can also do so more lightly while saving itself hassle.

Continuity Streamlines Work

Permanent long-term teams become more efficient in many ways over time. The first phenomenon is very natural. When the members of the team know each other, they work more efficiently because they do not have to spend time on guessing each other’s special skills and strengths. They are able to assign the right work to the right employee. This requires the team to continuously improve the team’s internal situation and pull together. The second significant contributor is continuous learning. The systems developed today are very complex, and business models are difficult to understand. When a multidisciplinary team solves broad entities, it learns to understand the laws of business and utilize the opportunities available to it. Knowledge means the ability to function with partial baseline data (Kuhn & Jackson, 2008).

Permanent long-term teams become more efficient in many ways over time. They are able to assign the right work to the right employee.

So how can we function without projects? Projects are larger entities that seek to produce new functionalities or improve a product. In other words, they are changes that deliver the specified customer value. It is important for such an entity to eventually deliver more value than it costs. The creation of business value may require larger changes, which is why these entities will also be important in the future. When the agile development model is scaled to include more than one team and also extended to the company management, we need a portfolio management model. In the agile model, entities corresponding to traditional projects are treated as epics, i.e., large bodies of work.

The difference compared to projects lies in the continuous prioritization of the Epic backlog and continuous business ownership. A project is often handed over to the development organization after business management has obtained the funding for it and after the first milestones have been reached. After this, management will ask after the project when the schedule is about to end. However, instead of perfectly successful content, the answer is often a bunch of unsolved problems and the team having run out of money. This is one important reason why business management must genuinely own the bodies of work and continuously monitor their output. It is a good practice to place bodies of work in a clear order of priority based directly on monetary benefit. In other words, you can make your own entity a higher priority the better you are able to explain the business benefits it offers or reduce the implementation costs of the functional parts.

This is possible for us if we are able to direct the teams’ work to always focus on features that will deliver the greatest benefit. Let’s keep in mind that agile teams always deliver functional products after every iteration, which allows us to confirm how much value can be achieved with the latest version. Is our product already good enough that we are generating profit? The projects of a lazy manager move down in the order of priority and provide the company with nothing. This unproductivity is made visible, and capable managers get the appreciation they have earned.

So what next? Let’s assume that in five years most software development and other product/service development processes will have abandoned the project model and focused on delivering value to the customer. In that case, what can we improve on next? Contribyte’s Tulevaisuuden Tuotekehitys (Product Development of the Future) community seeks to find answers to this question.

Would you like to switch from the time-consuming project model to more agile methods? Contribyte can assist you with that! Read more about our agile and lean coaching and various agile training opportunities.