Making sense of agile – part 2

Agile from the trenches

In my previous blog post “Making sense of agile” I shared my vision on the merits of adopting the agile way of working and what it can bring both at corporate and personal level. I also promised to do a follow-up piece focused on a sample team working in an agile fashion, so here it finally is. The goal remains to provide an insight in what it’s like to work in and with an agile team while you – the reader – aren’t required to be well-versed in all things agile and scrum to understand this content.

Creating the agile team

I must admit that I struggled a bit with the angle of approach for this follow-up blog post, so I decided to start with the very definition of an agile team. I like the way leadingagile.com has described it:

An Agile team is a cross-functional group of people that have everything, and everyone, necessary to produce a working, tested increment of product. Dedicate these people to the team, and as a rule, do not move them between or across teams as demands ebb and flow.

Here we immediately see a key difference with the traditional way of creating teams in some large organisations. We had no need for a dedicated project manager to go hunt all over the company to procure the right mix of people required to deliver the project goal. Depending on the corporate organisation, such can be a relatively smooth process or a source of frustration. The latter happens when there’s competition for resources which can effectively become an impediment for the formation of the team, since the individual team members usually (continue to) report to their respective managers, who may have other priorities in mind.

In the case of our agile team, most members were selected from already existing agile teams and reinforced with a fresh career starter, while the teams that provided people also received replacements to stay at their desired size. We benefited from having all impacted teams operating inside the same organisational department of our client’s company. People were selected based on their known technical skill set and motivation. In case of the starter, we took a calculated risk as the latter quality was deemed crucial to boost the former. The feedback from the people who would join the team was valued to come to the right people and skills mix.

Here’s an alternative definition of an agile team:

A group of people who hold a set of compatible values, a set of values based on trust and respect for each other and promoting organizational models based on people, collaboration, and building the types of organizational communities in which they would want to work.

I can’t recall where I came across this definition, but if you read on until the end, you’ll understand why I equally value this definition.

Team composition

The entire team is made up of Design is Dead consultants working for Telenet, a major telecom player in Belgium. Even though it’s a small team consisting of 5 developers and a scrum master, the team still incorporates all required skills for the job at hand. Note that in scrum everybody’s called a “developer” as a generic term to indicate they are part of the scrum team. In reality, the individual skills can, of course, be much more diverse than for example being full-stack Java developers. Some members are more proficient in analysis or testing practices, devops or any other required skill. What’s important is that the team is confident it can handle any task it will need to perform either by virtue of its combined experience or by its strong motivation to acquire new knowledge and skills as needed. Nice evidence of this attitude was the setup of the complete CI/CD pipeline including test automation by the team itself whereas traditionally this used to be done by a specialized DevOps team servicing the different scrum teams.

Another interesting characteristic of the team is that it is geographically and culturally split over two countries and time zones with a part in Belgium (Brussels) and Turkey (Izmir). Ordinarily, this could be considered a cause for concern for the efficiency of the team, but due to the company culture and investment in proper onboarding by having the team members spend the initial sprints on the same location and allowing them to bond, this risk is almost completely mitigated. Of course, having everybody in the same location will offer the best guarantee for success but after a few years of working like this we can rightfully claim to have established a successful onshore-nearshore co-operation formula at Design is Dead that minimizes the impact of distributed teams and maximizes the benefits of rapid scaling and cost balancing.

Finally, the Brussels part of the team is working in-house at the customer’s HQ premises. This is also an important success factor since we want to involve the business as closely as possible with our development. The proximity of stakeholders who can be invited to the bi-weekly sprint reviews, the ability for our PO to attend retrospectives and higher accessibility to the larger organization, in general, all contribute to setting up a favourable work environment for the agile team. After all, the aim is to establish a partner relationship to jointly deliver the desired added value at a steady pace. In short: efficient feedback loops aren’t just a necessity at team level but also towards the people we’re delivering the value for.

The assignment

Design is Dead have been working as a subcontractor and IT solution partner to the former BASE Company (now Telenet) for many years and as part of our past deliveries we have created an application that handles all inquiries about mobile subscribers as requested by Belgian legal & justice authorities via official warrants. This is a legal obligation for all telco’s in Belgium.

The scope of the project for the new team is highly technical in nature, yet easy enough to describe. The existing system has various ways to handle the requests coming in through various channels but the entire process of request intake, processing, pricing, returning the query results and invoicing currently involves many manual operations performed by members of the Justice Team at Telenet. Due to the Belgian Financial Intelligence Processing Unit’s request to all telco’s to automate the existing inquiry process, our team will build a new application that does exactly that. We also want to do this while reusing parts of the legacy system where possible. Note that none of the current team members was on board when that legacy application was built, so there was ample need for code investigation by our new team.

Hitting it off

When asking the team members individually what they see as their success factors the answers are amazingly similar. Excellent team communication scores very highly and with part of the team in Brussels and part of it in Izmir this is extremely important. But more than just the technical tools we employ for this, the very open and constructive way in which constant feedback is given matters a lot. One only has to have a look at the team’s dedicated Slack channel to see this in action every day.

The fact that the communication is going so well can largely be attributed to the very high trust level that’s been established in the team. Since the team members moved in from other teams, only a few of them had worked together on a day to day basis before. However, the newly formed team soon found out they had a matching drive and could speak openly about their views on the technical solution, which knowledge areas needed a boost, … basically any relevant (or banter) topic without fear for conflict.

As a scrum master, I also observed that building that trust level was made easier thanks to the psychological synergy of the team. There was ample room for people’s personalities to be appreciated as opposed to reducing team members to just their technical skills and interacting accordingly. This made relationship building a lot easier and this is something I consider the true foundation of any well-performing team. This is what makes your teammates fill in the gaps spontaneously whenever unexpected things happen, e.g. like somebody falling ill or going on holiday, which could otherwise have a significant impact on such a small team.

The secret recipe for success

There are some other important factors that have contributed to the team’s high-performance level, although some of those also come with increased risk as well.

High on the list should be the single project backlog. Contrary to most of our other teams, the backlog for this team is really only focused on the project at hand. This avoids context switching, which in turn allows the team to maintain a very strong focus. Most of our other teams rather work on a backlog that contains items for multiple projects that need to be delivered via multiple delivery platforms, which inherently causes more overhead.

However, the backlog itself has to be filled up entirely by the team itself. The PO role is much less prominent than with our other teams. We’ve solved this by using the team’s best analyst as a substitute PO who gathers the input from the government and customer side and briefs the team on the high-level priorities. I suggested using user story mapping to the team to make it easier on ourselves to create the actual backlog, but the story creation, splitting and grooming all happens exclusively by the team. We appropriated the walls of a meeting room for this where we will keep updating our overview permanently for the duration of the project. This in turn also made the project more comprehensible and transparent for the actual PO and stakeholders (we also do our sprint reviews in that room) so that we could get some validation of our approach and proposed priorities while minimizing the risk of blindly developing items which might not have been the highest value parts expected by our customer.

From the above, it’s also clear that the team has been allowed a high degree of autonomy. Our customer trusts and empowers the team to build the right solution, based on our proven track record. This trust in the team’s professionalism and abilities boosts the team motivation even further and it doesn’t shy away from the responsibility level that comes with it. The team knows it’s being watched closely as the execution on the project milestone deliveries remains a very rigid requirement imposed by the government. For less mature teams this might have become a serious stress factor but given this team’s strong foundations in trust in each other, it’s being experienced as an extra motivator to show off the team’s capabilities. By demonstrating working software every two weeks the team in return shows it’s worthy of the trust and autonomy granted by the customer.

Another important success factor has been the team’s willingness to run controlled experiments and proof of concepts where needed. The project is quite complex technically speaking and therefore the team every now and then encounters areas that need investigation before the right technical solution can be established. In contrast to the waterfall way of working in scrum we want to deliver the added value as fast as possible and at a steady pace. This means that there’s no classic analysis phase before development starts but that we do this effort just in time where needed. We do this by creating the aforementioned proof of concept stories which allow us to create the actual functional stories based on the proofed technical solution. These will then be taken up in the next sprint(s) to become part of our bi-weekly drops of working code.

Finally, the fact that the team is fully adhering to the scrum framework is also acknowledged as a reason for its success. The can-do attitude and willingness to go full speed ahead is definitely not specific to agile or scrum teams, but the scrum framework offers a way to channel this energy efficiently. The built-in self-improvement practice of the retrospective helps the teamwork on its weak points and bolster its strengths. This is clearly reflected in the team’s positive velocity and predictability improvement and knowing their efforts are well spent also boosts the team’s confidence.

Learning from failure

While reading all of the above ones might start to wonder where all the setbacks, challenges and hiccups are hidden. Surely things can’t be smooth sailing all of the time just because you work in agile and scrum? Fear not, for you have now ventured into the most interesting part where I try to describe how we failed and what we’ve learned from it.

At the onset of this blog post, I mentioned how we set up the team. I also provided two definitions of an agile team and the latter proved to be the one where we initially failed. When we started out with a career starter we took a calculated risk. We assumed that the same mindset was shared between all members of the newly formed team and that we would be able to bridge the technical knowledge gap through our combined efforts to bring our junior member up to speed. However, after a few sprints, it became apparent that communication and productivity left a lot to be desired. We stressed frequently that she should ask a lot of questions to avoid getting stuck but that didn’t really get going. In a project where we venture into uncharted territory regularly, we need to rely on top-notch communication and the transparent exchange of ideas to do the best possible job.

In spite of the openness and support from the other team members, the contributions, therefore, stayed below par. Much worse, at some point, the team found out that our junior wasn’t sincere to the point of lying about work items being done or not. This was a serious breach of trust and also compromised the team’s quality standards, so after four sprints and a lot of second chances, the team concluded that our junior’s mindset was incompatible with the team’s expectations and that the team’s productivity was more harmed than it benefited from her contributions.

This is a hard message to digest and as a scrum master I am responsible for guarding the team’s efficient collaboration, so after exhausting other ways to resolve matters inside the team I finally had to facilitate a team composition change to resolve this fundamental impediment. Our junior was replaced with someone from another team in whom we had more confidence regarding their attitude and ability to bridge the technical knowledge gap faster. It was not a junior but the attitude weighed more than the technical proficiency, just like it had with our junior.

There’s no ill-feeling toward our junior as job experience is something you can only gain through doing. I hope the event was rather embraced as a learning experience which will help throughout her future career and not something to get hung up on as a source of self-doubt or anger.

Naturally, the team has encountered other snags left and right and the high risk of the scope volatility still remains, but these are all manageable in the bigger scheme of things.

The agile journey continues

If there’s one thing I hope to have made clear through this blog post it’s that I firmly believe that agile methodologies aren’t just about technical alternatives to the classic waterfall way of working but also about delivering good products to customers by operating in an environment that does more than talk about people as “our most important asset” but actually acts as if people were the most important, and lose the word “asset”. Of course, you can have motivated teams doing a good job working in more traditional ways, but the very core principles of agile make this much more likely to become reality in self-managed agile teams, provided the essence of the mindset is understood and nurtured within the teams and preferably the organisation they are a part of. Establishing the right environment to provide the teams with the best chance of success should be a management priority, as opposed to managing the individual team members directly as done in the more traditional way of working. Maybe I’ll revisit that topic in another blog post someday 😉

At the time of writing this blog post, the team has just completed its last sprint containing functionality required in the initial product launch. Even though many people were sceptic that this would be feasible with such a small team, the first milestone has been delivered on time and now the journey continues. I have every confidence that the rest of the project scope will be delivered accordingly and that I will enjoy coaching the team for the duration.