project-management – Pragmatic Agile

The four essential strategies for building a fit, resilient and high-performing team

If you have had read my previous two blogs you will know how to have a highly motivated team with a strong tactical structure to deliver fast but without a fit team you are not going to win.

In soccer about 20% of the goals scored are in the last 15 minutes of the game. There are several reasons for this which include urgency and increased risk taking, but a major factor is fatigue. Team fitness is the third most important influencing factor for a soccer team to win a match. I think this is true for a software delivery team as well.

If the team isn’t fit then it doesn’t matter how motivated they are (and they won’t be for long), or how good the operating model (tactics) are. An unfit team won’t be a high performing team and win the match, the project and achieve the product goal.

A fit software delivery team is a team that:

1. Deliver as fast as possible whilst at the same time maintaining a stable product

2. They are accountable for the outcomes

3. They are resilient to setbacks and issues

4. They are happy

1. Fast pace whilst maintaining quality

To deliver quickly whilst at the same time maintaining the quality of the product I suggest you implement the lean software development and DevOps practices described in “Accelerate: The Science of Lean Software and DevOps” (Nicole Forsgren, Jez Humble, and Gene Kim).

In the book the authors describe how to implement these critical practices:

Continuous Integration/Continuous Deployment (CI/CD)
Automated testing Version control
Utilise cloud infrastructure
Alerting and monitoring
Lean management techniques (limit WIP, visualize work)

and then track these metrics to make sure you’re getting better:

Deployment frequency
Lead time for changes
Mean time to recovery
Change failure rate

Forsgren and her co-authors demonstrate that high performing teams share key characteristics: they deploy more frequently, work in smaller, more manageable batches, maintain lower change failure rates, and recover from incidents faster. But I really recommend you go and read the book; it is very easy to read and understand and has lots of other points on cultural changes which I have described in my other two blogs in this series.

2. Accountability

In a high performing team, every member of the team needs to own the goal and make sure that everything they do is a step towards achieving the goal. In soccer, a left back can have a shot on goal they don’t need to always pass to the striker. The same applies in our teams: if everyone is waiting for someone else to solve the problem we don’t move as fast as we should.

“When everyone is accountable for achieving organizational results, and not just doing her job, the right things tend to happen.” – The Oz Principle

In “The Oz Principle: Getting Results Through Individual and Organizational Accountability” (Roger Connors, Tom Smith, and Craig Hickman), the authors use the Wizard of Oz as an analogy for accountability. Essentially their message is: don’t expect the Wizard to solve all your problems, you have to do it yourself.

The authors introduce the Accountability Model, which consists of two primary zones:

· Above the Line – taking ownership, solving problems and making things happen.

· Below the Line – blaming others, making excuses and waiting for external solutions.

Success requires shifting mindsets and behaviours to stay “Above the Line.”

The book outlines a four-step process to accountability, summarised as “See It, Own It, Solve It, Do It”.

You need to coach accountability into the team. When they come to you with a problem, ask them to come up with the possible solutions and fix it themselves. The team retrospectives give you an opportunity to practice this. When the team identify issues make sure you don’t take responsibility for solving them, discuss possible solutions and then assign the follow-up actions to the team members.

3. Resilience

A fit team can overcome any obstacle, any setback and come back stronger. In soccer, the best teams cope with going a goal behind, losing a player due to injury or having a player being sent off. Your team needs to be able to anticipate, prepare for, respond to, and recover from disruptions.

“Resilience is not about avoiding risks or disruptions; it’s about having the capacity to anticipate, absorb, and recover from them—and even use them as opportunities for growth.” “The Power of Resilience“

To be resilient you must be flexible and agile. This is where the Agile methodologies come into their own. If something changes you can change your approach almost immediately. You don’t need to follow the project plan created 6 months ago. Agile methods mean you only need to design solutions to problems when needed, and therefore you are not wasting time on tasks that may need to be done further in the future which actually can become obsolete.

Another way of building resilience into your team is to avoid key person dependency. This is where one member of the team has specialised knowledge or skills that no one else in the team has. If that person leaves unexpectedly then performance will be lost. To avoid this happening:

Knowledge share, document critical processes, decisions, and expertise.
Cross-train, train multiple team members to handle essential roles and responsibilities.
Succession plan, identify and prepare backups for critical roles.
Automate, repetitive tasks can be automated to reduce reliance on individuals.
Encourage collaboration, make the team decide on next steps and solutions to reduce centralized authority.

Risk Identification and Assessment is also important so that you can proactively plan for any disruption. This is large subject which I won’t tackle now as it is deserves a whole blog dedicated to it. I recommend “Waltzing with Bears: Managing Risk on Software Projects” (Tom DeMarco and Timothy Lister). As well as providing the risk management frameworks common across all types of projects, the book also outlines common software delivery issues such as schedule flaws, requirements inflation, specification breakdown and under-performance.

4. A Happy Team

This seems obvious: to have a fit team they will need be happy and motivated. See my previous blog on motivation for some tips on how to make a team happy (top tip – it is not about giving payrises!).

If you can create a team which delivers as fast as possible whilst at the same time maintaining the quality, and is resilient and accountable you will have an all-conquering team which will succeed in any situation.

Let me know how you get on.

8 Effective Ways to Build Trust in Agile Software Development

When searching for the terms ‘trust in Agile SDLC environments’, I found lots of articles on how to create better teams and relationships within the team. I did not find much on how to make people outside of the team (I.e. the stakeholders) trust that the team are delivering.

External trust in your team matters. A team’s performance must be visible and acknowledged, not just effective.

One of the common complaints about Agile Project Management is that it is too woolly – there are no hard deadlines. To the uninitiated, this could be seen as allowing the team to take it easy and not deliver as fast as they would if they were working in more traditional project management environments (i.e., personal deadlines mapped out in Gantt Charts).

I think the opposite is true (and maybe in another blog post I’ll explain why), but, in this blog, I want to describe how you can create trust that the team is delivering as fast as they can but also that they are delivering the right things at the right time.

To create trust in Agile Planning you need to follow these eight steps:

Make the team predictable
Make a plan
Don’t over commit & have difficult conversations early
Get Management buy in
Show progress
Change the plan
Deliver and celebrate!
Review the impact

1. Make the team predictable

This is the hardest sell to the management team. If you have a new team or one that doesn’t know its capacity in a quantifiable way, you have to spend time getting the team to this position – there is no short cut.

This will take at least three iterations (e.g. six weeks for two-week iterations). But in my experience, it will take a new team at least five iterations (10 weeks). In order to make yourself plausible in future conversations and timelines, you have to tell the stakeholders that they have to wait up to 12 weeks before you can give them a plan. If you crumble now and start giving delivery dates without this information you are likely to be over optimistic and miss delivery dates. I’m sure I don’t need to tell you that if you do this, your credibility will be lost.

To get to the team capacity (or team velocity) you need to start estimating all the work that they do in Story Points. (Again, this deserves a whole blog post on the subject but here are a few links for more detail: Scrum Alliance, Mountain Goat)

2. Make a plan

Once you know the team’s capacity you can create a plan. I suggest quarterly planning as this is long enough to justify the effort but short enough to ensure minimal amendments to the plan.

To make the plan, ask the product team to create a list of features required in the next three months. These can be described in one sentence or a short paragraph. The development team can then estimate the size of these items in T-shirt size – where the team can complete one large, or two mediums, or four smalls in a sprint. You can also use XL (takes two iterations for the whole team) or XS (eight items can be completed in an iteration). They should ask questions to the product team, but you should not spend too much time on each item otherwise the whole planning exercise will take too long.

I suggest that this process should take no longer than two hours.

Once the product team have the estimates, they can decide on items to work on in the next quarter.

3. Don’t over commit

At this point you need to put contingency in the plan – leave capacity for at least one extra iteration in the plan to account for –

under estimation of tasks
additional requirements on the features included in the plan not currently known by the product team (emergent requirements)
some space for additional features that appear during the quarter

& have difficult conversations early

You might have some push back at this point either from the product team or the management team over how much your plan shows will be done in the quarter especially if they are used to being over-promised to. It is important to stand firm on the team estimates and don’t over commit. You need to have the difficult conversations now over how much work can be done, rather than accept everything and then disappoint everyone at the end.

The Product team need to make hard decisions now on what should and should not be attempted in the quarter. They don’t get the opportunity to do this if you make them happy by over promising now.

4. Get Management buy in

Once the list of features has been agreed on by the Product, Dev team and Scrum Master the list should be presented to the Management team.

You should review the plan with the management team. Each item should be explained as to why we are working on it – include the ROI, success criteria, customer value and any metrics which will be tracked.

If the management team agree we can continue.

5. Show progress

Show progress as often as you can to as many people as you can.

Report at least at the end of each iteration. Project the current velocity against the remaining work to make sure you can still deliver everything in time. I use burn up charts to do this.

Show progress as visually as you can. If you are co-located use a wall to pin up diagrams to show the work left to do and, more importantly, what has already been done. If you are a remote team use a tool such as Miro to do this but keep advertising it to make sure everyone sees it.

6. Change the plan

This is Agile, which means that we can and should change the plan when necessary! If we are running late ask the team to see if there is anything they can do to deliver the same features but for less effort. If not, then ask the product team to decide what items won’t be done.

Communicate this change and the reason for the change to everyone.

If there is new work to be done, then ask the product team to remove a similar sized item from the to-do list.

I run a bi-weekly change board to review all the new requests and decide whether they should be added to the quarter. There needs to be a high bar for things to qualify but we should also allow things to be added.

7. Deliver and celebrate!

At the end of the quarter you should have an official end of quarter review. Assess what got delivered, what didn’t, what extra was delivered and you should celebrate as a team and a company.

With one team I worked with, I would buy doughnuts if we delivered on time. I wouldn’t just buy doughnuts for the team but for the whole company (it was a small company). This meant when people outside of the team asked, “Why do we have doughnuts?” someone would answer that the team have completed a major milestone successfully. Nothing like advertising your success!

8. Review the impact

It is really important at some point to review what was delivered and compare it to what was expected at the beginning of the process. Did you achieve the expect ROI? Did the metrics change in the direction expected? by the amount expected? Ask the customers for feedback.

Present this to the stakeholders even if you didn’t get the results you hoped for. What did we learn? What are we going to do next?

Summary

If you follow the key steps above by confirming the plan with stakeholders, keeping them updated, delivering on time (even with scope changes), review the impact, and report back you’ll build the trust needed for your team and company to succeed.

Embracing Pragmatism in Agile: A Stronger Approach

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!