Pragmatic Agile

Beyond Superstars: How to Strengthen Team Ability for Maximum Success

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.

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.

Winning Tactics for Successful Teams

“If football were played by robots, I would win everything.”

Marcelo Bielsa

This is the second blog post of my series on how to build a team that can win. In the last blog I discussed how to motivate the team  and in subsequent blogs I will discuss Ability, Fitness, Motivation, Power and Luck.

No matter how motivated your team is, if your tactics are wrong, you’re never going to win a soccer match. The same applies to business teams – to win you need to achieve an effective work pattern. So in this blog I look at what tactics are the best, and how you can implement them.

Strategy v Tactics

I see the terms strategy and tactics used interchangeably, but they are at two ends of the scale. The strategy defines the problems you aim to solve in the long term and explains why. The tactics outline how you will approach solving these problems on a day-to-day basis.

The strategy will be hard to adjust, but tactics should change to make sure they are effective or continue to be effective. In software delivery the strategy is defined by the product owner, how to achieve that strategy should be the role of the delivery team. There are many great books on how to define and execute strategy and product management, but here I want to dive deeper in to how to organize a team in order to achieve the strategy.

“A good team plays with intelligence, awareness, and a good tactical structure.”

Arsène Wenger

My best tactics for a delivery-focussed team is to:

Focus on outcomes
Experiment
Use Lean principles
Implement a team organisation framework
Define Roles and Responsibilities

Focus on outcomes

Once the product owner has defined and stated their strategy, work with them to identify the desired outcomes. These can be expressed as OKRs.

Being focussed on outcomes means that you will aim to solve the real problem rather than just delivering tasks blindly. It increases innovation and gives the team greater flexibility in how they achieve the required results.

Experimenting/Intelligent failure

To achieve these outcomes, you need to experiment. Create a hypothesis that a chosen change will create the desired outcome and then try it, analyse the results and if it doesn’t have the desired outcome iterate (or tweak) the experiment or try something completely different.

Make sure if the experiment fails it is intelligent – by this I mean that it is Quick, Cheap and Unique. I have already written a blog on Intelligent Failure.

How do you choose and prioritise your experiments? In game theory there is a practice of backwards induction – this can be used to identify feature prioritization. In backwards induction you start with the desired outcome and work backwards to identify and prioritize the most critical features that need to be developed first.

Here’s a soccer analogy example which might explain things clearer-

In this scenario the striker is approaching the goal with the ball, and there are 3 seconds left in the game. The striker must make a series of quick decisions to score.

At 1 second (final decision), the striker is in the penalty area and must decide to shoot or pass. Shooting has a 70% chance of scoring, passing has a 30% chance. Optimal choice: Shoot.
At 2 seconds, the striker is at the edge of the penalty area. The options are to either dribble into the area or attempt a long shot. Dribbling leads to the higher probability shooting opportunity in step 1. Optimal choice: Dribble into the area.
At 3 seconds (initial decision), the striker is approaching the penalty area. The options are to sprint forward or attempt to draw a foul. Sprinting forward leads to the optimal dribbling opportunity in step 2. Optimal choice: Sprint forward.

Let’s transpose this into a Software development situation:

Final stage (Month 6) Target = 50,000 active users, required feature: Advanced reporting and analytics
Month 5 Target = 40,000 users, feature: Integration with popular third-party tools
Month 4 Target = 30,000 users, feature: Mobile app launch
Month 3 Target = 20,000 users, feature: Team collaboration tools
Month 2 Target = 10,000 users, feature: Task management and scheduling
Month 1 (Launch) Target = 5,000 users, features: User authentication, project creation, basic task management

In the example above we don’t know if the task management and scheduling features will achieve 10K extra users but it is an experiment we will try.

You can read more in “The Art of Strategy: A Game Theorist’s Guide to Success in Business and Life” (Avinash K. Dixit and Barry J. Nalebuff).

Use Lean principles

To follow on from experimenting, you need to conduct these experiments as cheaply as possible. This means using the Minimum Viable product principle, popularised by Eric Ries in his book The Lean Startup.

Do the least you need to do to prove or disprove your hypothesis, validate it and learn; and then either Pivot or Continue with the current approach.

Team Organisation

“Talk to each other” is the most common phrase shouted by soccer team coaches at the junior level (I know because I do it!). You need to create a way of working within the team that means they own the delivery, they coordinate tasks and they inspect, adapt and improve.

This is where Agile ways of working can help, especially the Scrum framework. It offers a standard operating model which provides opportunities to communicate (daily meetings) and regular intervals to reflect on progress with Iterations (Sprints) and a formalised approach to approve the team (retrospectives).

Roles and Responsibilities

In a soccer team you can’t have 11 defenders, you need a mixture of competencies. A coach will think carefully about who is performing what role. In a business team this is rarely done beyond asking the question, “do you have the necessary job functions filled?” (e.g. DevOps, Tester, Devs).

In “Team Roles at Work” (R. M. Belbin), the author describes the following roles-

Action-oriented Roles

Shaper – Challenges the team to improve and pushes for action.
Implementer – Turns ideas into practical actions; reliable and efficient.
Completer-Finisher – Ensures thoroughness and attention to detail.

People-oriented Roles

Coordinator – Acts as a facilitator, ensuring that everyone is involved and focused on team goals.
Team Worker – Supports team members and promotes harmony within the group.
Resource Investigator – Explores opportunities and develops contacts outside the team.

Thought-oriented Roles

Plant – Generates creative ideas and solutions; often seen as the innovator.
Monitor-Evaluator – Analyses ideas critically; provides objective judgment.
Specialist – Brings in-depth knowledge or expertise in a specific area.

Make sure you have most of these roles covered within your team – this can be multiple roles per person. Make sure they know that this is the role(s) they bring to the team. Encourage them to expand on this role and improve in it.

If you think that an important role is not fulfilled by a team member, think about who could do this role and speak to them about stepping up into it.

Making sure you have the right players in the team, and they can do the tasks they are assigned will be discussed in a subsequent blog on Ability.

If you can create the perfect tactics suited to your situation you will have an all-conquering team which will succeed in any situation.

Let me know how you get on.

_{Feature image photo by Markus Winkler: https://www.pexels.com/photo/top-view-shot-of-foosball-13548815/}

Unlocking Team Potential: The Role of Motivation

8–12 minutes

I help to manage my teenage daughter’s soccer team. It is (mostly) great fun and the experience has given me a deeper appreciation of the nuances of the game. I read quite a lot of football-related books but one I read recently on team tactics has got me thinking about the essentials of a winning team dynamic. It states that you need to be better than your opposing team in six key areas in order to win a soccer game:

Tactics, Ability, Fitness, Motivation, Power and Luck

I think this is a great way to think about any team dynamic, and it fits especially well with a software development team. How do you create a team that can create an amazing product, deliver a success project or a release, achieve a desired outcome for a quarter? Do you just rely on your team’s ability? How do you effectively motivate your team? How much is your team’s success reliant on sheer luck?

Developing this analogy has been a great way to collect my thoughts on how I build teams. I’ve learnt a lot as well, so I thought I would share how I think you can create a game-winning team by focusing on the six key areas.

I intend to write a blog on each of the six areas. First up is Motivation.

NOTE: Before I continue, I need to address my contentious use of the term “soccer” rather than “football” (I am English not American, after all!). Having read several books on the history football, I know that in that the early days of the evolution of the sport, football was split into two distinct rules/codes – Association (Soccer) and Rugby. The term soccer was first used by the British in the late 19th century and I believe is the best way to distinguish it from all the other codes around the world – Aussie Rules, Gaelic, Rugby, American etc. https://en.wikipedia.org/wiki/Association_football

Motivation

In a soccer game, the motivation of the team is the biggest factor in effecting whether they are going to win the game, especially at the top level where the relative ability of the players is mostly even with only slight gains from having the top, top players in your team. The most important job of a soccer coach is to motivate the team to play harder than the other team. To do this the coach need to get the tactics right, of course, but a team that is really focussed on winning will win more frequently than a team who are on autopilot.

In the business world, motivation means that everyone in the team gives 100% every day to deliver as quickly as possible to their highest standard and actively participate in making the workplace a more efficient place to work. Having a team in this state will mean that you can achieve anything, no matter what challenges you have been given.

There are lots of books on how to motivate individuals in the work place. Commonly considered the best book on this subject, Daniel Pink’s book Drive: The Surprising Truth About What Motivates Us describes three core elements to motivating an individual:

Autonomy – The desire to direct our own lives
Mastery – The urge to get better at something that matters
Purpose – The need to do work that has meaning

I am not going to discuss these further here, Pink has done a very good job of that already. However, I think he has missed two important elements:

Having Fun
Collective Responsibility

Having fun

Making work fun is implied in Pink’s book. If you have autonomy, if you are getting better at something and have a purpose you will naturally be enjoying the work and be more motivated. My suggestion however is that you need to actively make work fun to motivate people. If people enjoy their work and the people they work with, they will be more eager to make the project (and therefore the company) a success.

In Fish! A Proven Way to Boost Morale and Improve Results (Stephen C. Lundin, Harry Paul, and John Christensen), the authors describe how you need to include play in everyday working life. I suggest you do this in two ways – actively reserve time in the week to play games with team members and gamify essential but repetitive and boring (often admin) tasks. For example, make bug fixing a game by creating a leader board of the team members who solved the most/biggest bugs. I recommend weighting the bugs according to their importance and difficulty to avoid promoting the wrong behaviours.

Playing games is a great way to build relationships in a team and making the team enjoy working together. However, don’t forget that this type of activity may not be fun for everyone, and enforced/mandatory fun will not actually be enjoyable at all. Make it optional and if some of the team don’t want to attend then find out specifically how you can make work fun for them too. In my gamification example for bug fixing, you are still going to get team members who don’t solve bugs and are going to be at the bottom of the table every month. Make light of this rather than it being a shaming exercise, and you can even reward the person at the bottom of the table (wooden spoon?), then it will still be a fun exercise for everyone.

Psychological safety and trust is a big part of making work fun. If people can make mistakes, experiment with ideas without fear of being chastised and ridiculed then humour and playfulness is more likely to occur naturally. Amy Edmondson in her book The Fearless Organization: Creating Psychological Safety in the Workplace for Learning, Innovation, and Growth, notes, “Encouraging curiosity and learning means creating conditions where people feel free to ask questions, explore ideas, and even have fun with what they’re doing.”

Silliness also has a place in a motivated team. In Fish!, the authors describe a fish market where workers toss fish to each other, joke with customers and engage in playful interactions, which may appear “silly” to outsiders but serve to energize the environment. Being silly can break tension, foster connection and boost creativity but this does need to be balanced with professionalism. Knowing when to do this, with whom and in what environments is important. For example, in front of the management team in a board meeting might not be the best choice! Examples of silliness could be Icebreaker questions at the beginning of a daily meeting such as, “If you were a vegetable, what vegetable would you be?”, or instigating a Hawaiian shirt day.

Variety is often important to make work fun. In software development you can often get experts in particular aspects of the product and when delivering to tight deadlines it is very easy to ask the same person to work on the same area. Try to make sure knowledge is shared as much as possible and everyone can try new things as often as possible. Again, some people don’t like change and you need to make sure that the person with the new challenge you are giving them is comfortable with it.

“Variety is the very spice of life,

That gives it all its flavor.”

William Cowper

Having a flexible work-life balance can make work more fun by integrating personal needs, and therefore reducing stress. This does need to be balanced with the necessity of the team to be able to communicate effectively, (having core hours is important), but if you can be flexible with the team members they will be flexible with you and work in personal hours if required.

And lastly, you need to celebrate success! Let’s go back to the analogy at the beginning of this blog – when teams win soccer games there is a LOT of celebrating! This provides a vital opportunity to bond with team mates. I recommend celebrating whenever possible, even for the smallest wins. Just make sure the celebration matches the success – an all-expenses paid team night out is not justified for the completion of a successful iteration, but it is for a major project delivery lasting over a year.

Success itself is a massive motivation – if you are part of a winning team you have confidence to go and win the next game. Celebrating success no matter the size of the achievement will show the team that they are winning and make them want to win more.

Collective Responsibility

In Daniel Pink’s book Drive: The Surprising Truth About What Motivates Us, he says that having a shared purpose is important in motivating people but here I want to emphasise the need for the individual to take the responsibility for delivering the shared vision.

To do this you need to make everyone in the team invested in the team goal. In soccer this is obvious: they want to win a game, the cup, or the league. It is also obvious what they need to do to contribute to the goal: score a goal, save a shot, run with the ball, tackle and pass. So, in your business team you need to do the same: explain the company or project goal and explain how to contribute to achieving that goal.

When the team is given a new challenge make sure that this is clearly communicated to the team, including why it is important and how it will make the company better. Discuss how to solve the challenge as a team and get them to agree the milestones and delivery date. In doing this you getting them to be invested in the project. If they feel they have been consulted and are part of the commitment they will be motivated to deliver it.

They will also be motivated to improve the team processes, cover for other team members and actively spot issues and risk and remove them. In soccer teams we coach this – if the full back advances up the pitch with an attack opportunity the winger needs to cover the defensive position if there is a counter-attack.

Jessie J is right – It is not all about the Money, Money, Money

I am sure lots of people would say that the best way to motivate an individual is money, or the threat to remove it. Whilst at a basic level this is true (people will work harder for a promise of a pay rise), once someone has enough money to make them comfortable, it becomes less of a motivation and they can fall into a trap of working at 80% of capacity and become bored.

Pink states in his book, “The best use of money as a motivator is to pay people enough to take the issue of money off the table. Pay them fairly and pay them well. Once that’s done, the true motivators of autonomy, mastery, and purpose take over.”

If you can combine having fun with giving your team members autonomy, mastery and purpose whilst at the same time giving them collective responsibility 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!

Intelligent Failure

I was watching a video of Jonathan Smart talk about his excellent book Sooner Safer Happier and something he said jumped out at me:

“We want intelligent failure”

Intelligent failure, he explains, is a failure that is:

Quick
Cheap
Unique

Failure is not intelligent if you have spent a lot of time and money and/or you have made the same mistake several times already (doh!).

This is a great concept – making a mistake is not bad as long as we do it quickly, cheaply, learn from it and alter our approach next time. In fact, in her book, The Right Kind of Wrong, Amy Edmondson suggests companies should actively seek to make mistakes in order to use the lessons learnt to make strategic decisions.

Agile and failure

Guess what? Scrum and the general Agile methodology provide the tools to ‘fail intelligently’ in the inspect and adapt principle!

An iteration retrospective provides the opportunity to identify where failures have occurred, learn from them and adapt ways of working accordingly.

The next time you do a retrospective, ask the team where they have failed specifically rather than the usual Start, Stop or Continue topics. Why not ask the team to identify some experiments they can do which are likely to fail so that lessons can be learnt quickly and can be used to make decision on how to continue the work.

I would suggest that you also broaden it to be company-wide and ask the management team to do the same. Failure is not negative when it can be used to drive the company forward.

Escape from the Office – How to run an escape room for 80 people simultaneously

What is the most terrifying thing you’ve done professionally? For me, it was having to guide over 80 people through an interactive ‘get-to-know-you’ session. These type of sessions can be so awkward so I was totally ready to blow the format up and produce something that was enjoyable and useful for everyone. It was just totally terrifying for me!

I have now done these events a few times (getting better each time – and more out of my comfort zone). So let me tell you how I pull them off.

The basics

The escape room style session has multiple groups doing the same activities to escape the “room”. The groups compete with each other to be the first to finish all the activities, work out the escape code, in order to escape the fastest. There’s a range of fiendish or logical puzzles to complete as well as physical challenges. The variety of games maximise the opportunity for the group to interact with each other and create memorable moments which can be discussed and laughed about later!

Materials

1 set of escape room puzzles per team (see below)
Physical activity instructions (see below)
Ping pong balls (number depends on activities chosen)
Chopsticks (number depends on activities chosen)
Plastic beer cups (number depends on activities chosen)
Table for each team and physical activities

Puzzles

I used the puzzles created by a professional paper-based escape room creator, Paper Escape Co.

I recommend spending the money on this kit, they are really varied, well thought-out and just the right side of tricky to work out! They also save tons of time. Choose 6 and 10 different puzzles which each give a specific answer. The answer from each puzzle can then be combined to provide a code word which can be used to “escape” the room.

The number of puzzles you choose will depend on how long you want the activity to go on for. The more puzzles you have, the more possible combinations of answers there will be. Use this table to calculate how many puzzles to use.

Here’s an example of a puzzle you could use (I have created this one myself to protect Paper Escape Co’s copyright):

The pack from Paper Escape Co contains hints for the competing teams, which is necessary for some of the more fiendish puzzles.

Physical Activities

It is difficult to find physical activities that keep both the athletic and the sloth-like happy. But I really like the Beat That! selection of physical challenges, and used it for inspiration. Watch the video in the link for ideas on what tasks you can ask the teams to complete.

Directions

Here are my top tips on how to run an escape room session with a large team:

As a rough guide I recommend you split your group into teams of between 4-8 people and have 2 and 4 physical activities and up to 10 mental activities for them to complete.
As part of your planning for the session, rope in as much help as you can. You will need a small group of people to help facilitate the session and support the teams through the puzzles and activities. One person can support up to 4 teams or 2 activities. For example for 80 people I had 10 tables and 4 activities – I had 3 people looking after puzzles and 2 people looking after the physical activities (5 helpers in total). Brief the helpers and give them the hints and even the solutions so that they can help the teams. We actually did the puzzles together before the session, so that all the helpers understood what needed to be done.
Set up the room so that there is 1 table for each team (where they will do all the puzzles), and 1 table per physical activity. I had 14 tables in a very large room!
Place half of the puzzles on the tables ready for the teams to start.
Split the attendees into the teams. You can do this however you want, but I love to add a bit of silliness and get everyone to order themselves in a line according to the number of graters they own (cheese, nutmeg, foot!). I then go down the line giving everyone a number between 1 and 10. The number represented the table and team they were on.
Let them start cracking the puzzles – the helpers can give hints progressively to help them out. I gave the helpers a timesheet for when to start helping the teams; e.g. no clues until after 5 minutes with no puzzles completed.
Once the puzzles have been completed, move your teams on to the physical activities tables and complete the first and second activity.
During the time it takes the teams to complete the physical activities, get the helpers to lay out the second half of the puzzles on the puzzle tables.
Once the two physical activities have been completed, move the teams back to the puzzle tables to complete the second half of the puzzles.
When they’ve finished the puzzles, move the teams to do the third and forth physical activity.
Once all activities have been completed they can be given the final puzzle – arrange the letters (the answers to the puzzles) into a passcode and the winning team is the one to complete the passcode and tell the facilitator their answer.

That’s it!

Good luck! Have fun! And let me know how you get on.

You are the weakest link, Goodbye!

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

How do you fix weak points?

Hidden Skills

Diversity

Roundup

1. Fast pace whilst maintaining quality

2. Accountability

3. Resilience

4. A Happy Team

Strategy v Tactics

Focus on outcomes

Experimenting/Intelligent failure

Use Lean principles

Team Organisation

Roles and Responsibilities

Motivation

Having fun

Collective Responsibility

Jessie J is right – It is not all about the Money, Money, Money

1. Make the team predictable

2. Make a plan

3. Don’t over commit

4. Get Management buy in

5. Show progress

6. Change the plan

7. Deliver and celebrate!

8. Review the impact

Summary

My greatest weakness: I can be too pragmatic

Pragmatism in action

How to run a pragmatic Agile project

My actual greatest weakness?

Agile and failure

Further Reading

The Right Kind of Wrong

Nurturing innovation through intelligent failure: The art of failing on purpose

Sooner Safe Happier – Antipatterns and patterns for business agility

The basics

Materials

Puzzles

Physical Activities

Directions

That’s it!

Leave a comment Cancel reply