Session idea: You are the Team Leader

Here’s a session idea that has been rattling around in my brain for a while; how to better prepare team leaders for the awkward people-related challenges that will crop-up in their future. I’ve tried, but been ultimately unsuccessful, to submit the session to my local agile conference, so thought I would post the idea here to see if anyone has any ideas to help me improve it. So, here it is…

Session Title: You are the Team Leader

Abstact

You are a newly appointed leader of a software development team. On your first day in the role, a team member tells you in private that they think that one of the inexperienced developers in the team is a “waste of space”. What do you do?

Team leaders are faced with awkward situations and difficult challenges every day. Peopleware, a seminal book about leading project teams by Tom DeMarco and Tim Lister, states that “the major problems of our work are not so much technological as sociological in nature”. This rings true; we are comfortable solving technical problems, but we struggle to cope with the unpredictable issues that crop up when people work together.

Furthermore, in difficult moments when we are put on the spot, we can react hastily and respond to situations in ways that do not reflect our principles. If given space and time to think about these challenges, we would probably handle things differently and be more consistent with our values. Often we handle awkward situations as best we can when they first come up and then, hopefully, we have the experience to better handle them in the future. Hopefully. But perhaps we could prepare ourselves better in the first place?

In this workshop we will deliberately practice leading a software development team. Attendees will tackle a series of awkward leadership challenges, pooling their ideas and experiences in order to decide what they would do in each situation. There will not be any right answers, but we’ll discover new perspectives, evaluate options and better prepare ourselves for the awkward situations and difficult challenges to come.

More information about the session

In this session, we’ll be focusing on the team interaction and people challenges team leaders face every day, rather than technical or process problems. We’ll take some time to talk about the leadership principles we’d each like to personify and will then use that as a framework for the rest of the session.

We’ll employ a number of facilitation activities to explore each challenge to help sub-groups think creatively. At the end, we’ll ask groups to share their proposed course of action and their reasons for that decision.

The workshop takes inspiration from Paul Trevillion’s cult You Are the Ref comic strips, which feature a series of awkward football referring challenges (see below). If I’m lucky enough to be selected for a conference, I’m hoping to produce some (significantly less well drawn) comic strips to help capture each challenge and bring the scenarios to life. We’ll see…

How LeanKit helps it’s teams make effective decisions

This week I attended an excellent talk by Jon Terry, the CEO of LeanKit, at a Software East event hosted at Redgate Towers. If you’re not familiar with them, LeanKit is a workflow visualization SaaS company based in Franklin, Tennessee. Jon talked about the approach LeanKit took to help their teams stay lean and make good decisions as they grew from a small start-up to a medium-sized enterprise.

Here’s part of the abstract for the talk:

Does this FizzGood? Improve velocity, predictability & agility by asking a simple question

LeanKit’s founding team had a strong Lean-Agile background from previous careers. So, in the early days of the company, we just instinctively did things in a Lean way with as few formal processes as any startup. But, like any growing company, we eventually did have to start clearly defining how we do things. And like anyone, we were tempted to become more bureaucratic – with lots of scheduling, coordination, meetings and estimates.

Instead, we developed our FSGD (Frequent Small Good Decoupled) approach. This LeanKit way of working has provided our teams with a simple yardstick for making effective decisions without a lot of cross team scheduling and coordination. It has simplified abstract Agile concepts into something everyone easily understands and cheerfully applies on a daily basis.

From: http://www.meetup.com/software-east/events/227959891/

So, FSGB (pronounced Fizz Good!) is simply a mnemonic everyone at LeanKit now uses to help them make decisions that align with the company direction and it’s lean principles. The concept was defined by the four co-founders of the organisation (not by an extended committee) and rolled out to all areas of the organisation (Development, Marketing, Sales, etc). It now forms part of their induction process for new hires and is referred to frequently throughout daily life at the company.

Giving teams and individuals autonomy to take decisions and providing the right-level of guidance so they can do so in a deliberate manner, consistent with the aims of a business is something I’m really keen to explore. So, here’s what I took away from Jon’s talk…

What does FSGB stand for, then?

Frequent, Small, Good and Decoupled – but that soda can looks waaaay too pleased with himself, if you ask me

Frequent

What? Deliver stuff frequently and at a deliberate pace – not annually, quarterly or sporadically.
Why? Basically, because it’s better! LeanKit is a SaaS business and Jon added “I have to resell to all my existing customers every single month”, so delivering new stuff frequently is paramount. It also reinforces all the agile goodness of continuous integration, continuous delivery, customer feedback, stress-free/low-risk releases, etc.
Anything else? Jon added that if you are in a high margin, fast-moving business, investing in speed of delivery will pay for itself very quickly; “it’s basically free”. If your team ask for money to get their cycle time down, you give it to them.

Small

What? Break work down into its smallest valuable components. Each small piece should be able to be delivered independently.
Why? Delivering work in small sections brings a load of benefits; reduced work in progress, increased opportunity for customer feedback, reduced risk for each individual release, etc. In fact, it’s this small batch size that really helps enables a lean workflow approach.
Anything else? By breaking everything down into small, valuable pieces teams may find that they are finished with a feature earlier than they expected. For instance, a development team wants to develop awesome feature, X. They spend time thinking about whether it can be broken-up into smaller units and realise that it comprises four distinct pieces of functionality. So, they put the four sub-features into a queue and begin work on the first piece – x1. They complete x1, ship it and start work on x2. This process continues until they have shipped sub-features x1, x2 and x3. However, before starting x4 they realise that feedback from their customers is telling them that they do not need it. In fact, x4 would make the user experience worse. As a result, the team decide they are done with feature X and move on to feature Y (which users are really desperate for!). The time required to do x4 has been saved and customers are happier, awesome.

Good

What? Things need to be good to be done, so we don’t ship garbage. At LeanKit, the definition of “good” includes something being tested, logged, documented and reviewed (known as TLDR – they love an acroynm).
Why? Well, shipping small stuff frequently should not be at the expense of quality. A Saas business needs to resell to their customers every month, remember? So, we can’t afford to deliver them garbage. On the other hand, “good” does not mean gold-plated. Gold plating is very unlikely to be more valuable that the next thing on your work queue.
Anything else? Jon is an advocate of Henrik Kniberg’s more nuanced version of the Minimum Viable Product idea. Henrik talks about the concept of a Minimum Testable Product, a Minimum Usable Product and a Minimum Lovable Product. He feels teams should go through each of these phases when building a product and not jump straight to a gold-plated, finished version. If you take this approach, good things happen (see image below or Henrik’s excellent post for more about this). This idea works all the way down to a feature level – teams should ask themselves what the minimum that would be good enough to test an idea, and make that first. They should certainly not hold onto something until (they think) it’s perfect.

Frequent, Small, Good and Decoupled – but that soda can looks waaaay too pleased with himself, if you ask me

Decoupled

What? Work should be independently valuable but it should also be isolated from all other work, so as not to spread risk to other areas.
Why? So that one piece of work does not put other pieces of work at risk. Jon added that if one small feature in a frequent release is garbage (and not “good”) it will only affect a small number of people and will not damage other things. This backs-up the drive for small, frequent releases.
Anything else? Keeping to this “do no harm” manta means that LeanKit can trust individuals and teams to act independently because they must ensure that their work will not damage another team or their work. This reduces the amount of cross-team co-ordination required and therefore reduces the number of coordinator-type roles in a business.

Can this be applied elsewhere?

Jon was keen to emphasise that the components that make up FSGD are not rocket science and were certainly not dreamt-up by LeanKit. However, there is a real strength in calling these principles out so explicitly in a business (growing, or otherwise), and asking the people to work there to use these idea to help them make effective decisions.

Distilling this philosophy down to a four letter mnemonic – FSGD – may seem imprecise or simplistic but it has ensured that the notion is small and clear enough for people to keep in the forefront of their minds. It sure beats capturing it in a hefty tome that no-one will ever read.

In my opinion, emphasising that things should be “frequent”, “small”, “good” and “decoupled” would be a valid thing to do at most software companies. I’m not sure the “Does this Fizz Good?” call to action or the cute soda can mascot that accompanies the concept is going to land in a (typically cynical) UK software company environment. However, being principled about how you are going to work in order to reduce bureaucracy and help individuals and teams make sound, consistent decisions certainly should.

If you want to discover more of the backstory to FSGD, there’s a related article on the LeanKit blog by Daniel Norton (LeanKit’s CTO) – Does This Fizz Good? A Thinking Tool for Faster Value Delivery.

Goldilocks Goals: How to keep Retrospectives fresh and engaging

Retrospectives are the lifeblood of a team’s drive for continuous improvement and a force for good on software development projects. Teams should have a Retrospective at the end of every single sprint and they should never, ever cancel a Retrospective.

But how do you keep retrospectives fresh and engaging, when they should be ubiquitous and routine? One way to do this is by varying the activities that comprise the retrospective. Running a Stop/Start/Continue post-up every two weeks is going to get stale really quickly. So, if you don’t vary your retrospective activities at the moment, go invest in a copy of Agile Retrospectives by Derby & Larsen or just google “retrospective activities” and gather some ideas.

The 3 Bears could not face yet another affinity-mapping exercise, so politely asked Goldilocks to reconsider

Another way to keep Retrospectives fresh is to set explicit goals for each session. Often, these sessions are run with an implicit goal of “Let’s see what we can improve”. I’d argue that running every Retrospective with that goal, implied or otherwise, is a mistake. Instead, facilitators should choose a goal related to what’s important in the team/project/company, right now. Doing this will help guide the team toward a subject that is new, interesting or timely, and is therefore worthy of their investment.

Like the interminable Start/Stop/Continue activity, running every Retrospective with the same goal can be a bit… well, dull. Doing so invites the team to think about things in the same way they always have, with the same perspective and bias. In a Retrospective, we should endeavour to look at events and ideas in a new light, to challenge habitual thinking and to be innovative.

However, just choosing a specific, varying goal for each Retrospective isn’t quite enough. You want to choose a Goldilocks Goal.

You’ve guessed it – a Goldilocks Goal is a goal that is “just right”. Just right in terms of the scope of discussion it opens up during the meeting. A Retrospective’s goal should allow the group to thoroughly explore a decent-sized subject but not opening up an area too big with too many possibilities for a 60 to 90 minute meeting to reasonably cover.

The image below represents the structure of a Retrospective meeting, incorporating the distinct stages of the meeting popularized by Derby & Larsen.

The session opens up on the left, starting the discussion and gathering data points (the green circles) within a certain scope. Then comes the central, creative section of the session where data is analysed and people start to think creatively; connecting dots and spotting patterns in order to come up with novel insights. The session should then begin to narrow focus, converging the discussion towards an agreed set of tasks and the closure of the meeting.

The meeting’s goal is what opens up the discussion on the left of the diagram, setting the scope and dimensions of the whole session. If that goal opens up a subject that is too narrow or too wide, then the meeting will be ineffective and misaligned.

Let’s use an example: it’s Retrospective time and your team is still recovering from a sprint where they accidently released the installer for the Spotify desktop client rather than their own software (this, obviously, is an entirely made up scenario). You, as designated Retrospective facilitator, decide to go with the usual goal for the session:

“Find out what we can do better”

This is often the implied goal of a recurring Retrospective. There is a real danger here that the story team’s fail is lost amongst the huge number of subjects that arise from the last sprint – bugs, meeting problems, practices, environment, etc. This very open goal could lead to the team being unable to generate any real insight. They will struggle to tie together a legion of data threads, unevenly explore particular bugbears and lose the focus needed to delve into root causes of the most important issues facing the team. At the end of the session the group will, frequently, be left with some relatively inconsequential actions to progress over the next few weeks.

On the other hand, facilitators can go the other way and choose a goal that is too narrow. Doing this will mean the session only supports debate on a very specific topic, data points will be scarce and the group will lack the shared experience needed to engender a proper brainstorm. In our example, you decide to get straight to the root of the problem (as you see it) and introduce the team to the following Retrospective goal:

“Find out what’s wrong with our automated tests”

This goal could easily result in a session that is predictable and routine, where the group will only be able to talk about automated tests and unable to exert influence on what is explored and tackled. The end result of this session may be concrete actions to improve something that is relatively unimportant when compared to other problems on the project. What if we shipped the Spotify installer because of a manual error? What if that manual error occurred because someone was forced to rush to meet an unreasonable deadline?

A goal that is too closed may mean that some people feel marginalized or demotivated, as they are unable to contribute to the discussion. Furthermore, this is a leading goal. The facilitator has already decided the root cause and preferred solution to the team’s problems. This is not cool, and your Facilitator Hat should be confiscated immediately.

So, instead of choosing a goal that is too open or too closed, facilitators should spend some time defining a Goldilocks Goal that opens the debate up just right. Teams need a goal that is open but has boundaries. That way the debate can be influenced and re-aligned by the team, but the meeting is focussed on a key area and is less likely to head off at an unproductive tangent. The boundaries of the goal could be delineated in a plethora of ways – time, function, process, practice, commercial, technical, etc. The facilitator should use their judgement, or the insight of the team, to find a restricted scope suited to the current situation.

In our example, I would argue that the following goal was just right:

“Decide what we can learn from our last release”

This will focus the session squarely on the main pain point in the sprint but will still allow team members to raise issues that they feel are connected (a team member’s absence or a crazy deadline). It should ensure that there are fewer threads of data to explore and analyse, as the discussion is bounded by the timescale of the release and the components that comprise deployment (tests, automation, people, etc). Actions arising from this session are more likely to be tackling root causes of important issues, and ensure the team improve in a valuable way.

So, to recap… in order to keep your regular Retrospectives fresh, engaging and relevant, vary your activities and set a specific goal for each session. Make sure the goal is a Goldilocks Goal; not too open, not too closed, but just right.

Making time for Personal Development: Gold Cards

At the beginning of 2015 I got the development teams in my corner of Redgate together to explore the results of an annual company health survey. Amongst the feedback we’d received in the survey was a clear consensus that team members found it difficult to make time for person development activities.

That was especially true of activities that people wanted to do to further their skills/experience in an area that did not align with the project they were currently assigned to. So, an engineer working full-time on a desktop application wanting to increase their web development skills. This kind of activity, together with reading a book on coaching or mentoring someone on testing strategies, were falling by the wayside.

It wasn’t all bad news. Some team members were managing to eke out time to do personal development activities alongside core project work through timetabled extra-curricular activities that happen at Redgate, like Coding Katas, community of practice get-togethers or Coaching Dojos. However, most people were not able to find the time to focus on self-improvement naturally or simply felt too guilty to step away from project work. They saw this prioritization of personal-focussed work as somehow letting their team down.

Redgate have always been supportive of spending time on personal development (a.k.a. learning and development) tasks. In 2013 we rolled-out an entirely new approach to facilitating and building personal development plans and we’ve spent a lot of time honing role-specific Skills Maps to help people measure where they are and decide where they want to improve. Despite these efforts, the survey told us that Redgaters were still struggling to feel like their personal growth was being given enough focus.

In response to this discovery, we decided to experiment with a concept called “Gold Cards” – an idea we were introduced to by Rachel Davies of Unruly. Here’s Rachel’s post on the use of these personal development artifacts at Unruly – Gold Cards and Viking Helmet.

What are Gold Cards?

Gold Cards make it explicit that everyone can spend up to half a day a week (or one day every 2-week sprint) working on stuff associated with their personal development. For our teams, these half day personal development blocks and can be used for:

Anything on their personal development plan
Katas and dojos
Training
Product innovation (where innovating aligns with an individual’s personal development)

The only qualification for this work is that people describe what they will be spending their time on to their team at that day’s stand-up meeting.

To represent these two half days of personal development, each team member is issued with gold-coloured cards that they can place on their team taskboard to indicate when they are working on personal development. They can use their Gold Cards at any time you choose during the week. Or if they work in two-week sprints, they can use two Gold Cards per sprint, if that makes more sense. Unused Gold Cards do not roll-over to the next time period. Use ’em or lose ’em.

We hoped Gold Cards would make it overtly ‘ok’ for everyone in development up to spend half a day a week (or one day every 2-week sprint) focusing on learning and development. Basically, we’re consenting to people spending 10% of their time on personal development. This isn’t necessarily a change in policy, we were always very open to people doing personal development activities. We just wanted to make that sentiment explicit.

Where we are now

My division of Redgate have been using Gold Cards for 6 months now and they have been a success, garnering positive feedback from team members and having little or no discernible impact on project productivity.

Here’s some of the feedback we’ve had about Gold Cards from our teams:

They have encouraged people to think about and undertake personal-development related tasks (hurrah!)
They ensure it is called-out when people are spending time away from the project and why
It can be difficult to know when’s the best time to use your Gold Cards, but the teams have successfully self-regulated this
They highlight, and implicitly promote, personal development activities that were already happening (like Coding Katas)
They highlight the need for people to think about personal development, to have a ‘plan’ and to actively manage it
Making the use of Gold Cards ‘mandatory’ didn’t really work (especially in a sprint with a big deadline)
People think quite hard about how many hours a Gold Card is ‘worth’ and worry about only spending half a card (i.e. only using 2 of the allotted 4 hours)

Interestingly, it seems a side-effect of adopting Gold Cards has been that personal development stuff that was already happening, like attending Coding Katas, is now called-out and visualized on team boards. This has reinforced to other team members that spending time on these personal development activities is acceptable and, as a result, they are more likely to get involved themselves.

All-in-all Gold Cards have definitely helped us move in the right direction, but we’ve got more to do with personal development – especially with regard to development areas not aligning with current project work. We hope that the Spotify Guild model may help us in that regard.

However, based on this success, we are now planning to spread Gold Cards to the rest of the development teams at Redgate.

Encouraging convergence: Our project management working agreements

As I described in my previous post, the project managers in my division want to be deliberate about how we run and deliver projects. We decided to develop set of “working agreements” (or manifesto!) calling out best practices we have experienced (such as retrospective meetings) and the aspirational aims we have (such as delivering frequently) with a view to embedding these in all projects in our division and encouraging consistency.

A team’s taskboard reflects their processes and practices, but how much of this stuff should be common across other projects and teams at the same company?

If you want to learn more about why we did this, see Encouraging convergence: Putting a framework around agile team autonomy.

Here are our project management working agreements:

Process

We will use the Scrum framework for projects.
We agreed to have:

One or two week “sprints”
Daily stand-ups
User stories to capture work
A shared sprint review/demo
Frequent, regular retrospective meetings

We’ll share sprint cadence.
This means sprints on each project will be 1 or 2 weeks long and start & end on the same day across all Opportunities projects.

Each project team will be able to adapt their process and practices within this framework to suit their circumstance.
For instance, projects may have a differing level of certainty which may affect planning practices.

Purpose and goals

We will give our teams a clear purpose and good goals.
Where “good” means:

We will give our teams clear goals that they can directly influence.
We will give our teams goals that help them decide what to do and what not to do.
We will know if we have met the goals we set.
We will know if we are on target to meet the goals we set.

Teams will deliberately identify what they want to achieve in each sprint and release.

Roadmaps and themes

We will have a project roadmap for the next six months.
This should be a rolling 6 month window.
The immediate contents of the roadmap will be well-understood and certain.
The contents of the roadmap 3-6 months may be more uncertain and represent our ‘best guess’.

Project roadmaps will be broken into discrete, timeboxed themes.
These themes will be timeboxed according to the investment Opportunities is willing to make for the value.
These themes will help teams decide what to do and what not to do.

Themes will be broken down into small, independently valuable user stories.
This will be done before development begins on a theme (probably just-in-time).
The generation of themes and user stories will be owned by a product manager but, if necessary, facilitated by the project managers.

Delivery and planning

We will encourage our teams to release frequently (ideally, at least once a sprint).
We believe this is best practice and motivational.

We will adopt a deliberate, release cadence (for example, releasing every Wednesday).
We believe this is best practice; it builds predictability, keeps us honest and unlocks the release train approach.

We will use the release train technique to plan the delivery of each theme of work on the roadmap.
We use the “train” metaphor to communicate a few key concepts:

The train departs the station and arrives at the next destination on a reliable schedule (fixed cadence; standard velocity, predictable releases)
It delivers its cargo to customers (release)
If a team wants its “cargo” (code, documentation, etc.) to go, it has to put it there on time. The train will not come to them nor wait to get their content.

We believe using the release train will:

Engage the team in planning
Visualise the plan to deliver the current theme of work
Make the effects of scope changes and delays clear
Help us make better decisions around what we work on and what we don’t work on

We know when we expect to finish the current story and theme.
We accept that this may change as we learn more.

Continuous Improvement

Each project will have a mechanism to ‘Inspect and adapt’ each sprint.
We favour Retrospective meetings and believe running these every sprint is best practice.

We will share improvements and adaptations taken on each project with other project managers.
This can be achieved by a write-up of a Retrospective.

We will adopt good practices in other teams if there is a clear advantage or improvement to be had.
This should be reflected in this document.

We will regularly facilitate Retrospective meetings for other project managers.
This is so that project managers can participate in the meetings for their own projects.

Meetings

Meetings will have clear goals.

Meetings will be attended by the ‘right’ people.

All regular meetings will have an agenda that is shared with the attendees.

Practices

We will record decisions that have been taken over the course of the project.
We believe this will help us with consistency across the lifetime of the project and ensure all team members are aware of decisions taken in their absence.
We believe this will help new team members can be brought up-to-speed quickly.

We will encourage our teams to identify the relative priority of the tasks required complete a user story.
We believe asking teams to differentiating between ‘must have’, ‘should have’ and ‘could have’ helps us make sound decisions.

We will encourage team members to take time each sprint for personal development.
We favour doing this by using ‘gold cards’ to represent personal development tasks on team taskboards.

Cross-project Cooperation

We want the teams in the division to feel part of a larger development team.
This is so that:

Team members know who they can talk to in another team about a given problem
We are not blinkered by ‘team goals’
We avoid social barriers between teams
We are more easily able to move people between teams if a need or development opportunity arises

We want the teams to know what each other are doing and what they plan to do.
This is so that:

We know when work in one team will affect another team
We know when teams should work together to solve a problem
We spot opportunities to share skills and experience across projects
We are more easily able to move people between teams if a need or development opportunity arises

I’d be interested to hear what people think of these. Do you think they are useful, over zealous, anti-agile or just common sense?

Encouraging convergence: Putting a framework around agile team autonomy

The company I work for adopted an agile development approach in 2008. It was before my time here but, as I understand it, they trialled Scrum on a single, important project and then rolled the approach out to other teams when the benefits of an agile approach became clear.

As – rather awesomely – the company believes in pushing responsibility and ownership down to the team level and encouraging people to be undertake challenges as a group, each team became the owners of their agile process and practices by default. On the face of it, this sounds like a good thing, right? It was certainly one of the aspects that attracted me to the company; team ownership and autonomy.

Over the years, development teams have evolved, disbanded and been created. Most of the time, each team has been given full autonomy over how they work. Some successfully optimised their approach for the special characteristics and factors at play on their projects. Some were less successful.

Our organically grown processes and practices

Regardless of the success of these adaptations, what we have ended up with is a collection of teams with disparate approaches to the same mission – creating great software. This freedom has produced some really interesting innovations and we’ve been successful as a company. However, this divergence of approach has caused problems:

We make the same mistakes repeatedly. For instance, a single team may decide to drop retrospectives (without thinking about how to maintain a continuous improvement initiative) and that turns out to hurt the team down the line. That team learns a lesson and starts doing retrospectives again, but that lesson is unlikely to be passed-on, so inevitably another team repeats the mistake a few months later.
It takes a relatively long time to spin-up a new team. Each time we start a new project we go back to the drawing board to decide what our approach to software development should be. This takes time and does not necessarily build on best practice.
Considering we are one company, we find moving people between teams can be difficult, as each move requires people to learn about a new way of working. In management-speak, this harms team liquidity.
Best practices and good ideas that have worked are, in general, not shared as teams can be resistant to ideas from outside.
Comparing projects is pretty difficult, so it can be hard to determine if they are struggling and need help, or if they are on track. Measuring progress on each team requires an understanding of exactily how that team works.
We can find it difficult to collaborate across projects, because we are all different – we have different practices, different cadences and different traditions.

We could solve these problems with strict processes and low-level governance, but that would be a bad thing, right? Ideally, we’d like to avoid this stuff but allow teams the freedom to do what it takes to solve the special problems and issues that are tied to their circumstance – that is, to allow them to ‘inspect and adapt’. Our view is that we should be deliberate about how we run and deliver projects, but not dogmatic.

Therefore the project managers (who are effectively team leaders) in my division decided to develop a set of “working agreements” calling out best practices we have experienced (such as retrospective meetings) and the aims we have (such as delivering frequently) with a view to embedding these in all projects in the division and encouraging consistency. We tried to identify the right things to do in the general case, to find universally useful practices that would be of benefit in most cases. We did not gather a superset of all the practices across our teams, with a view to homogenize every aspect of how we work.

The idea is that these working agreements form a framework for how we run projects in the division, so that new projects always have a solid starting point and the fundamentals of how we work remain broadly similar.

Our project management working agreements

We have explicitly declared that projects can diverge from these agreements. Certain jobs will have special characteristics or other factors that suggest a different approach. For instance, an exploratory prototyping project is unlikely to require a 6 month roadmap! In these cases, we have agreed that divergences from the agreements should be discussed with our colleagues, so we all understand why they are happening and share new practices.

Furthermore, improvements and optimizations within this framework are encouraged for each project. Following a retrospective, the team may decide it would be advantageous to formally adopt TDD for their next feature. This kind of adaptation needs to be able to happen locally, without the need for consensus across the division’s development department. We want to reflect and embrace what we learn as software development evolves (e.g. the movement towards continuous delivery), so the agreements are a “living document”, open for negotiation and improvement, driven by local optimizations.

Our working agreements have served us well so far and we’ve still learnt new things to evolve our approach. In fact, we’ve recently gone through a review of our agreements and have made some changes to reflect what we now think is best practice for projects in our division. For instance, we have agreed to use a release train technique for continuous delivery planning.

The project managers got together to review our working agreements and bring them up-to-date

I’ve shared our working agreements in my next post. Please take a look, if you are interested.

When the going gets tough, don’t cancel the Retro

If times are tough on an agile project, whatever you do, don’t cancel the Retrospective meeting.

Let’s be clear, cancelling that meeting is removing an opportunity for the team to inspect the way they have been working, and adapt how they do things so they can improve.

That’s an opinion I’ve held ever since I started working on agile projects back in 2008. It just seems logical to me. I had a conversation this week that reinforced that position.

I was chatting to a couple of members of a development team over lunch about their project. They couldn’t really stop themselves from complaining about some difficulties their team had been experiencing over the last few months. They highlighted a few issues that they felt could be improved and discussed how they’d like to change aspects of how they work together. My overall observation was – they seemed pretty fed-up.

When I asked if they felt they could discuss these worries in their next sprint retrospective meeting, one of them told me how those meetings had not really helped solve their problems in the past. In any case, their team felt they spent too much time in meetings in general, so they had decided to change their process and only have retrospectives at the end of every other sprint. As a result, they had a retrospective meeting once a month.

I recommended that they have a retrospective as often as possible, given their description of the project. One of the team members stopped me and said, quite matter-of-factly and without a drop of irony, “Some of us, Chris, have a more pragmatic approach”, he shrugged apologetically, “we just prefer action over meetings”.

He looked at me somewhat condescendingly, eyes filled with pity as he considered my misplaced faith in a meeting. How could a group of people coming together to talk about stuff be preferable to actually ‘doing things’?

Somehow I managed to stop myself from slamming my forehead into the table in disbelief. I also avoided making the suggestion that the pragmatist’s preferred action seemed to be complaining about the problems they had, rather than trying to resolve them. I did, however, embark on a robust cross-examination of what was meant by the term “pragmatic”.

My recommendation to the two colleagues (who are good guys, by the way) was to not give up on retrospectives but to talk to their manager/scrummaster/facilitator to see if they can design a meeting together that would help them tackle their problems. And they should definitely have a retrospective every sprint.

I described the kind of retrospective activities that might help surface and explore the issues they were experiencing. A teamwork satisfaction poll, perhaps? Or a Mad/Sad/Glad activity? This seemed to gain some traction with the other team member, who went away to talk to the facilitator earmarked for their next retro.

Teams can label the time they spend in retrospectives as worthless and futile. Often, this is because they’ve experienced some poorly run or structured meetings that have failed to produce valuable, insightful actions. In these cases, I’d plead with a team not to give-up on retros and suggest reading Agile Retrospectives by Derby & Larsen to give their meetings a better chance of success.

Teams have been know to cancel retrospectives if they feel like they are under too much time pressure and are forever racing to reach difficult deadlines. For me, taking time away from your desks to reflect on what is going on when a project feels like it is in a perpetual race against time, is invaluable. To be honest, if you think that having the team in a meeting room for one hour every two weeks is going to make your project fail, then it’s going to fail anyway.

So, if you are on a difficult project and are considering cancelling or reducing the frequency of your retrospectives, ask yourself what the root cause of that drive is. Then consider whether that root cause is something that would actually benefit from a regular, frequent opportunity to inspect and adapt.

Leading Agile Teams