scrum – Pragmatic Agile

Is it important to have a team of super stars to succeed?

By superstar I mean someone who knows their subject, completes tasks efficiently and to the highest standard as well as driving thinking in their area. Sounds pretty good to have a team of these guys? But in reality, a team’s success is built on bringing the weakest members up to standard rather than elevating already successful performers.

You are the weakest link, Goodbye!

Let’s go back to my favourite analogy: Soccer!

David Sally in his book “The Numbers Game: Why Everything You Know About Soccer Is Wrong” says that Soccer is a “weakest link” sport, which means that the squad is only as good as its weakest player. It has been statistically proven that by improving the weakest players in a team you can have a more significant impact on overall performance than further enhancing the strongest players.

I know that this is true for software delivery teams as well – you can only deliver as fast as your slowest team function. Notice I say function rather than team member. In any software team there are several functions: Backend or Frontend Developers, Product Owners, UI/UX Designers, Testers and DevOps. Most of the delivery items will need to go through each one of these functions. If one is weaker than the others it will cause a bottleneck in the flow of work through the delivery process.

If you have a superstar before the bottleneck, it will cause more of a queue if it is after the bottleneck they will be starved of work and won’t be efficient.

How do you spot where the team’s weak points are?

You can use Cumulative Flow Diagrams (CFDs) to spot where there are bottlenecks in the process. CFDs help you visualize workflow progress and stability over time. They are area graphs that depict the quantity of work in different states, showing arrivals, time in queue, quantity in queue and departure. You can use them to spot in which stage your tasks are taking longer to complete. If one of the stages is taking longer this would indicate that there is a bottleneck in this area. See the example below.

In this example you should spend time working with the team members who are responsible for Deployments to see how their skill needs to be increased.

But don’t rely solely on CFDs to work out weak points, you should also use quality indicators such as:

Are there a lot of bugs found in production? This indicates that testing needs to be improved.
Do we get feedback from users that the UI/UX is complicated? So you need to work on UX design improvements.
Is the expected outcome not achieved after delivery of a new feature? There is a weakness in product design which needs to be improved.

How do you fix weak points?

Just like a soccer manager, David Sally suggests concentrating on these three strategies when improving your team’s overall ability:

Recruitment Strategy – teams might benefit more from investing in solid, reliable players to fill weak spots rather than spending heavily on one superstar.
Training Approach – coaches should focus more on bringing up the level of weaker players rather than solely developing top talents.
Team Dynamics – creating an environment where stronger players mentor and inspire weaker ones becomes crucial.

Hidden Skills

To improve the overall ability of your team you should also seek out “Hidden” skills in the team. These “Hidden” skills can supercharge the productivity in your team by unlocking untapped potential, matching employees with roles that align with their natural strengths as well as boosting individual and team morale.

These “Hidden” skills can be categorised in four ways:

Leadership and Communication Skills – for example, can the tester be capable of training team members, or can a developer be a talented team lead?
Practical Skills – this could be a backend developer who is programming iOS apps in their spare time.
Personality-Based Hidden Skills – does a team member have good organising skills and therefore be a good match for the Scrum Master role?
Unique Personal Talents – such as creative problem solving or attention to detail which can be used to enhance the team environment.

Finding “hidden” skills doesn’t need to be complicated. I’ve found these strategies work well:

Observe and Challenge – pay attention to how team members conduct themselves and if you can spot a skill that they don’t use in their day-to-day job then challenge them to use it more e.g. if they show capability in their presentation skills then get them to present user demos.
Conduct skills surveys – implement formal assessments or surveys to identify other skills.
Conduct 360 reviews – ask each reviewer to identify skills they see in the reviewee. They may be surprised what other people say about them!
Celebrate unique talents – praise all skills including those unrelated to work. This builds trust, connection and keeps the team energised.

Diversity

Your team needs to play Total Football!

If you haven’t heard of it before, just let me explain a little. Total Football was a groundbreaking tactical model that emerged from the Netherlands, during the 1960s and 1970s. It is characterised by flexibility in player positions on the pitch as well as collective responsibility. The strategy allows any outfield player to seamlessly switch positions which creates a dynamic and unpredictable playing style where players are expected to understand and execute multiple roles on the pitch.

This strategy of flexible roles could work well in software development teams. If they understand another team member’s job, they can be sensitive to how they need to interact with them. For example, developers can experience the QA role (temporarily), and by doing so they will learn first-hand the frustrations of the testers and change how they interact with them in the future. When there was a communication issue in one team I was heading up, I successfully moved developers to work on automation in order to reduce conflicts with the testers job after sharing the role.

By being a bit more flexible in assigned roles, you also have less key-man dependencies – which is to be avoided.

Role-sharing in practice

A few examples of successful role sharing:

QA and Developers, Devs can test and QA can code

DevOps and Devs, Devs can deploy code and DevOps engineers code

Scrum Master and Product Owner – Scrum Master works on specifying a feature, Product Owner conducts the team rituals

Roundup

If you can elevate all team members to the same standard, find hidden skills and build in some flexibility in roles, you will have an all-conquering team which will succeed in any situation.

Let me know how you get on.

This is my fourth blog on how to create winning teams. I have already discussed motivation, tactics and fitness. You can read them HERE.

I’m currently on a break between job contracts, and preparing for interview questions. This has set me thinking about the dreaded interview question, “What is your greatest weakness?”.

To be honest, I haven’t been asked this question for a long time, but it has been a useful reflection point. Let me explain:

My greatest weakness: I can be too pragmatic

Being too pragmatic means that I sometimes accept less-than-perfect solutions to keep product delivery moving, where if I held out for a better fix, the problem might get resolved rather than leaving me stuck with an imperfect situation for longer.

Looking at this concept and turning it over in my head has been really interesting, because surely rather than a weakness, this is actually a strength?! I would rather be pragmatic and get things done, than idealistic and slow down delivery. Especially in Agile Software Delivery when the correct way to do things can be a matter of opinion anyway.

This is just another way of rephrasing the ” one size does NOT fit all” mantra when performing Agile Transformations. The methodology needs to be tailored to fit the situation, and rigidly following a plan for the sake of it should be avoided. I’d go further, however, and advocate to push this to the extreme and even mess with some of the sacred ceremonies and practices of Agile SDLC.

Pragmatism in action

Example 1

I have recently had someone outside of the team challenged me on the fact that my team rarely completed their iteration commitment and sometimes rolled over 50% of their commitment into the next iteration. This person wanted the team to commit to less work to resolve this problem. I can see the benefit of having a strong commitment from the team which is delivered say,75% of the time. However, to do this by slowing delivery down would be a mistake in my view.

The over commitment issue was caused by three factors –

Requirements from the product team were created too close to the iteration start date and a technical solution wasn’t created before estimation
The QA team were not sufficiently organised (resourced)
Team members were reluctant to share tasks

If we only focus on the team overcommitting without addressing the root causes, delivery will slow down. It’s more effective to fix underlying issues first, then apply the Scrum framework as intended.

However, on the flip side, because we continued to ‘make do’ there was little incentive for the product owner, QA and developers to change.

We had a really tight customer delivery date, and we needed to make progress, and I had included these inefficiencies in the team pace within the scheduling plan. So, in this situation my pragmatism enabled things to get done where an idealistic mindset of “stick to the methodology” would have slowed down delivery.

I would rather be pragmatic and get things done than idealistic and slow down delivery

Example 2

I was a Scrum Master for a team where the requirements for an iteration from the product team were one line, actually just a title.

Did this cause issues? Yes. Development took longer, there was functionality missing, testers took longer to test, rework was required.

Did we make progress? Yes. And we learnt lots too, about what the product should do, what the testers needed, what the team needed.

If I held the “Ready for Dev” line and made the Product team go away and work out their exact requirements, we wouldn’t have got those learnings.

It took six months and a lot of follow-ups to get our tasks clearly defined. If I’d have rejected the poorly defined tasks in the first sprint, we could have resolved this in one month and sped up from month two, but it would have cost me goodwill with the product team at the same time.

So, rather than putting barriers up to this project at the beginning I made sure the team just rolled with it, and the project was delivered to the requirements.

On balance I think it is better to progress than stand firm.

How to run a pragmatic Agile project

In order to be pragmatic in your Agile process, pretty much everything is up for grabs in the debate about what is actually required. How about trying these:

Daily Meetings – Don’t meet daily. If the team still deliver, meet once a month, or three times a day, or never! What ever helps your particular team get through their particular project.
Sprint Planning – Don’t do planning as a team. Do it individually, or the product owner decides.
Backlog grooming – Never do it if the tasks are simple or the product owner is always available to discuss the requirements.

Don’t get me wrong, I don’t recommend doing any of these! Some of them made me feel terrible for even writing them down, but if they work for the team and it means you deliver value to your users faster – do it!

However, I have 2 non-negotiables

Inspect and Adapt – You have to do something with the team that reviews performance and generates actions to improve the team at the end of every iteration, otherwise how do you know things are working?
Review progress with Stakeholders – You have to demonstrate work completed to the stakeholders otherwise how do you get feedback, learn and plan the next steps?

My actual greatest weakness?

I am colour blind. At school, I once coloured in the oceans on a map bright pink. I can still hear the teacher laughing – it was the ‘80s!

Have fun colouring outside the lines!

Tag: scrum

Beyond Superstars: How to Strengthen Team Ability for Maximum Success