Those are similarly important as the technical excellence of the team. Even if the people inside are super skilled for the job they are about to deliver, there are still areas that can ruin their effort for perfection. And it won’t be that much their fault as it will be the direct responsibility of the project management decisions and their ability to serve the team with fit-for-purpose processes to support the team with clear intent and predictable activities.
Highly Segregated Team With Distinct Skillsets
Imagine that the team has skilled developers, perfectly independent and with the ability to keep up their promises and deliver the agreed sprint content just in time before the end of the sprint. Even in such a perfect scenario (which is highly unlikely to happen anyway), the team will have problems keeping up with (ever-growing) backlog features if the skills are strictly segregated between the team members.
Few Examples
The team has 1 or 2 DevOps engineers capable of doing any changes to the automated pipelines or taking care of the services inside the platform, but the rest of the team has no clue about such things. Then discussing those stories on scrum ceremonies like refinements will lead to wasted time for the majority of the team by hanging on the meeting without any participation and vice versa – the DevOps developer will have no interest in the rest of the functionality-oriented stories, and the time on the meeting will be mostly wasted as well. There is a single database expert for the whole team. Depending on the complexity and usage of the data solutions in the system the team is developing, this person might be constantly overloaded with stories they have no chance to complete soon enough, especially when factoring in their priorities. Even worse, other stories will also have to wait, as those are dependent on the data source provided by the database stories. When a particular product is mostly oriented towards backend development, the only front-end developer is there just in case (because from time to time, some little change is needed even into the UI application anyway). In that case, again, most of the scrum ceremonies are a waste of time for this team member, as their knowledge is limited only to the front end, and nothing else matters.
Where It Concludes
In any of the above cases, the outcome is that people are either wasting their time or, alternatively, they are unable to catch up with the backlog demand. They are blocking the rest of the team from starting work on the next stories, or they are effectively decreasing the overall effectiveness of the scrum team because there is too much time that is not utilized within the sprint. The team, however, still has this number of developers. From the outside, it is not visible (even not wanting to be exposed) that the people inside the team are not able to take on some stories just because they are too oriented to some specific skill set. So they can’t help the other team members with the stories, even if their capacity would allow that, and the priorities for stories would favor it as well. It is even difficult for the product owner to compose some meaningful sprint content for the team, as the product owner must always take into mind how many people can work on every single story and if more similar stories are brought to the sprint at the same time, ultimately the capacity of the team is overflown, even if there are in fact people that could possibly work on those stories, but they don’t have the skill set to start with those.
Solving The Dilemma
It is a dilemma to be solved, and project managers shall be aware of the route to choose. Specifically, a choice between:
Having many full-stack developers capable of working on wider content, but not really experts in many topics. So they can go wide but not deep. Then the delivery can progress fast, but the quality might suffer. Having dedicated experts for each technology, but then accepting the limitation and working harder on better-fitted print content. Then people can go deep and build great stories, but the stories will need to be approached sequentially, thus taking longer to deliver.
Weak Product Owner
This one is not necessarily a “process issue” by definition, but I treat it like that just because the creation of solid stories can be understood as a process that the team should want to have rock solid and compatible with the development team. What I mean by weak does not need to be referring to the knowledge property of a person but rather to the ability of the product owner to serve the team stories which developers can understand and which make some clear sense from the product roadmap perspective. Both of those are very important for a successful scrum team. If the stories are lacking details for developers to be able to clearly understand the purpose, functional value, or technical expectations, then basically two scenarios can happen:
Developers will build something different from what the product owner actually wanted. It is even hard to catch during the sprint itself because mostly the product owner has not had the ability to track the progress of the stories on such a detailed level, and mostly PO will just expect the thing will happen (magically). Developers will spend way too much time clarifying the stories and discussing them over and over rather than start building them. This involves many additional calls, repeated agreements, and postponing the work to the late sprint phase. It reaches a point where the original estimates for the stories can no longer be considered accurate, and the stories are not possible to close within the sprint and are rolling into the next sprints. In the worst case, the situation then repeats in the subsequent sprints.
Time For Self-reflection
It is usually hard to admit, but the product owner should find the time to reflect, look at the backlog stories created, and eventually compare it with the product roadmap vision if there is still any sensible link between those two – if there is any roadmap at all. If not, that is the first thing to solve. Sometimes, the solution is to admit that the product owner is too far from the team and too far from own target. In such a case, the product owner part of the team is to be solved. If nothing else, bringing into the team a solid business analyst oriented more towards the team’s content rather than business content (for that, we already have a product owner in this case) could be a valid option to go for, even for the price of increased total costs of the team.
Testing Processes Without Fixed Timeline
What if the testing activities are not tight to a concrete schedule inside a scrum sprint? At first sight, this might look like something good we want for an agile / scrum team. Flexibility is always welcome and sounds good when presented outside. My experience shows that the result of this freedom is more chaos than flexibility. It does not mean that the solution to this should be creating “waterfalls inside sprint” with dedicated testing phases followed just after development is done. This is by no means the right approach in this case. You may read more about this in my posts on scrum testing strategy and agile testing life cycle. We can still allow some flexibility and choose the testing schedule as it looks most appropriate for the current development team and the given product properties the team is delivering. There are, however, two main targets that should be accomplished by this choice: If those conditions will be met, the team will naturally adapt to the fitting process, and the delivery schedule won’t be affected by unplanned prolonged testing activities. In the end, what matters the most is reliable and predictable sprint release, which leads me to the last point of this blog.
Undefined Release Process
Now, this is such an obvious thing for each scrum team. Yet, curiously enough, it is also usually one of the most underestimated processes. Very often, a scrum team will just say release will be after each sprint, but it is not backed up by a solid process. What happens then, in reality, is a lot of chaotic, unpredictable activities will arise during the release time. Suddenly all people are occupied with “release tasks,” and nobody is able to focus on continuing to develop new sprint stories. Sprint metrics are off, and release looks like random, unpredictable activity from the view of 3rd person (usually the client). People are so focused on the backlog, sprint content, development, testing, and finally showcasing the results that they forget that once they are done with all this, the next sprint is already ongoing, and they are already losing time.
Looking For A Good Time To Release
So when exactly should the team do the actual release to production? The single important thing that matters at the end. The answer to that question sits in the process, assuming you have one. Depending on:
the complexity of the content the team is producing in the sprints, duration of a sprint, number of affected components in the system the number of people using and requesting the changes,
a repeated release process should be established and followed going forward. The exact rules of the process can be again flexible in defining. But as it is with testing activities, making it a rock-solid habit that is predictable and scheduled for concrete days in the future makes it something to rely on and refer to.
Choices To Pick
The possible forms of such a process could be any of the following or others:
Complete the testing of the features from the current sprint during the following sprint and release the content at the end of that sprint (once testing is completed). This means each release will not have any content from the very last sprint but it will contain stories from the 2 sprints before. The last sprint before release is always dedicated to testing the content from the previous two sprints. This does not mean the development during the “testing sprint” will be stopped; it only says the content developed in that testing sprint will not be included in the next release yet. If there are enough automated testing activities in place already, strive to do the release after the end of each sprint. Then this must be a very strict process with dedicated people focusing on that few days for 100%. It should still not affect the rest of the development team in any way. You can also choose to release once per month or once per N months, mainly if that will be fine from the end users’ perspective. This will increase the effort on the testing side for each sprint (as the content will be bigger for each release). But on the other hand, it will mean less amount of repeated activities over time, which in this case, can have benefits for the team. As a result, it can enable the team to build more new features between the releases, despite the fact the features will actually come to production with a slower cadence.
But as already stated a few times before, it is not so important which of those processes will be picked. It is much more important how good the team will then stick to that process and will make it a hard-wearing habit. You may also read this guide to the release management process and practices.
