agile methodology – Pragmatic Agile

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!