Did the use of Agile evolve?

In terms of project management, most of us know that Agile started off as a better method for software development. The whole point was to bring better solutions to the market faster, by making the development process flexible. 

The productivity ecosystem is Darwinian, just like any other ecosystem in nature. The basic premise is that the fittest survive – the fittest being those who best use their resources. And in our quickly-changing world, the definition of “good resources:” also changes quickly. 

Without making the Agile process fit the environment, we’re in danger of ritualizing something that was meant to be a solution from meaningless rituals. 

In today’s IT, trust and ownership became a resource that changes how teams work and how the Agile methodology is altered – and a lot of companies adjust their Agile style to support trust and ownership. This wasn’t the case at the beginning when central management was still a knee-jerk reaction. 

This is how some of the world’s major software-based companies broke out of the Agile box, according to research by The Pragmatic Engineer:

This is just one example of how Agile can change to face new project realities – and it’s just one reason that today, every company uses its own approach to Agile. According to the State of Agile 2022, over 50% of companies use their own approach to Agile. 

Let’s take a look at the rules of Scrum, and Agile, and how we usually make them fit our needs:

1. The project manager is responsible for delivery 

Officially, Scrum defines roles like Scrum Master, Product Owner, and the Development Team. The Scrum Master helps everyone understand Scrum theory and practice, both within the Scrum Team and the organization, while the Product Owner is responsible for managing time, budget, and project goals. 

In TSH we noticed that this responsibility setup creates a gap. What? I will explain using a simple example: 

Let’s imagine we are about to start a new project. The goal is to build a simple game for kids. The project is sold and it shouldn’t take too long but… we still don’t know each other and we don’t have a backlog created but the decision was made: we work in Scrum. 

Are we ready to start the development? 

Absolutely not. Someone needs to choose a team and organize the workshop to write high-level requirements and set first priorities. Someone needs to establish rules like: communication platform, reports needed and meeting schedule. 

That “someone” is a project manager in TSH.  Ok, so the developers started the first sprint, and the project kicked off! Everything goes smoothly and management in TSH is curious about the progress. 

“The PM should manage the budget, documentation, and schedule and make sure the goals are achieved. He’s the one to be responsible for client and team satisfaction,”  explains Tomasz Poźniak, Head of Delivery in TSH. “There is much more. The PM should be also engaged and know everything about the project at any stage.”

2. The team is not entirely self-managing 

According to Scrum rules, the team of developers should be self-managing. BUT In TSH developers can fully focus on development. 

Let’s get back to our example project. Everything was going just fine in the previous chapter. Now, the team found some obstacles and it turns out that only the DevOps developers can help, but we don’t have the appropriate skills in our team. 

“Officially”, according to Scrum, the team should find the right person and should be involved in the recruitment process if there is no one available in the organization. In real life developers say “we need a person” and the PM needs to find “a person”. 

In the 5th sprint, another problem appears: the sprint is almost over but we have only 20% of the scope delivered. One can expect that the team will deal with it or at least will be able to explain the reason for the poor result. 

But most of the team are young developers and their lack of experience may cause the project to progress slower than anticipated. Scrum masters would usually coach and support the team, but in this situation, PM skills are also helpful and will work just fine. 

The PM explains the situation to the client and ensures the right solution is found. The reasons for the delay are designs that are quite complex, the team is struggling with chosen frontend library.

While there are a lot of complex reasons for the situation, it’s the PM’s job to balance team skills and project expectations. Whether they’re dealing with junior developers or experienced seniors, the PM has to keep tabs on everyone’s skills and strong/weak points so they’re a good match for what the project demands. 

The PM can also ask an external consultant, or architect for help and an opinion on whether implementing other tools might be a better solution. Another idea is to mix up the team setup and introduce at least one other dev with a different skill set.

3. Risk register and other paperwork

Scrum says that uncertainties are built into a project but does not explain how to deal with them in detail. So at TSH, we use a traditional way of managing risks: 

“While we can never predict the future with certainty, we can apply a simple and streamlined risk management process to predict the uncertainties in the projects and minimize the occurrence or impact of these uncertainties. 

Let’s get back to our kids’ game project. 

Progress was significant but at some point, our Product Owner (client) became more and more unavailable. Meetings, especially refinements were rescheduled. 

It turned out that the client wanted to invite an external security consultant to audit the entire application on the final stretch. 

But thanks to the fact that we had a register of risks, we remained calm. Previous projects with this client have shown that security is important to them, so we planned and carried out such tests in-house. 

Minor errors were quickly corrected, so the external auditor did not threaten the project’s planned completion.

The risk register was found to be very helpful. The PM had diagnosed that the absence of PO can be problematic so they talked about it with stakeholders. It turned out that the Product Owner experienced problems with poor connection and communication channels used in the project. 

The PM introduced a new way of communication and collecting requirements. Instead of meetings, the PO could write requirements directly in Jira, in case of any questions the team asked questions in comments. The PM knew his team enough that the QA’s notice was imminent. 

Would you like to know more about how we manage risks? Please find the risk register template here – you can rework it on your own if you’d like! 😉 

For a quick Polish lesson, FAŁSZ = FALSE

4. A roadmap may be the key

In Agile projects, it’s unlikely to have a roadmap before projects start.

But many clients come to us with fixed deadlines, so we need to respect them. Deadlines can be a result of certain budget constraints: clients are not able to pay more, so if we extend the schedule it would mean, they won’t be able to pay for extra MDs. Fixed delivery dates can also result in some business goals: if they work in a seasonal industry and need the project to be done before high season starts, any delay can cause significant money loss. So how we build the schedule is an important factor they consider whether they choose us as a partner or not. 

This, unfortunately, is the way of business – there are deadlines, budgets, and goals that all need to be met, and the roadmap needs to include all of these “destinations”. This means that the road can’t be straight – and the map has to illustrate detours, tight turns, and tunnels that lay ahead. This also means that both the client and TSH have to work together in order to make the most informed and precise roadmap that takes the project to its final destination. 

“We are aware that neither the Scrum guide nor the evidence-based management guide doesn’t tell you about the roadmap. In the EBM guide, you can find a few Key value measures related to Time-To-Market, but all of them assume you already have any data eg. velocity. 

A client we worked with summed it up for us. 

“We decided on a roadmap of the entire project (divided into milestones) for two reasons:

1. We are able to focus on the functionalities included in the milestones without excessively refining the system – we have a set of functionalities to be implemented in a given period and the task of the entire team (including the design team) is to ensure that these functionalities can be implemented.
2. We are better able to verify whether the whole project is on the right track. Additional checkpoints allow you to assess the capabilities of the current team to complete the project on time and, if necessary, take action to increase efficiency or reduce the scope of the project.

• Maciej Witman, Librus

So do we use Agile or not? 

Can we still say we use Scrum in TSH – of course, we can! We keep all scrum rituals, we focus on the goal of the project, and we try to deliver key values. At the same time, we try to ensure our clients that we have control over the project and are able to adjust to their needs. Our clients appreciate that.  

We believe that the PM should be deeply involved in the project, and have knowledge about its every stage, but should also skillfully manage the budget, documentation, and project schedule so as to prove all the goals set in the project, with the “obvious” satisfaction of all parties (not only the client but also the project team). 

This way, the person in charge can make the most informed decisions, period.