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…

You are The Ref

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?

FSGD-Words

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.
mvp

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.

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.

New Framework - No ActionsThe 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.

Goldilocks GoalLet’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.

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?

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.

Organically grown processes

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

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

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.

Stop Start Continue

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.

Release Wednesdays

This Wednesday, one of the teams I work with shipped a new version of their product – the DLM Dashboard – for the 10th Wednesday in a row. That’s 10 releases in the 10 weeks we’ve had of 2015 so far. Which is pretty cool.

One of the notable things about that release record is that we haven’t shipped on any other occasion in 2015. That’s because we made a working agreement to release only on Wednesdays. Imaginatively, we call this initiative Release Wednesdays. Yes, it’s a thing.

As a result of putting Release Wednesdays at the heart of how we develop and deliver software, we’ve optimised our projects, processes and practices so that we can to release frequently and deliver new features incrementally. Interestingly, in addition to increased pace of delivery and user feedback the weekly cadence gives us, we’ve found many of these optimisations to be beneficial in their own right.

Before I highlight some of those optimisations, here’s a quick synopsis of ‘why’ we have Release Wednesdays:

We release every week because:

  • We want to give our users valuable enhancements as quickly as possible and get timely feedback on the direction we are taking the product.
  • We believe in keeping the delta between releases small and the risk associated with an individual release low.
  • We think practice makes perfect and that the more often you release the less frightening it is to do so.

We only release on Wednesdays because:

  • We want to have a ‘deliberate’ release process, not an ‘opportunist’ one.  An opportunist release process results in an irregular release rhythm; sometimes there might be three releases in a week, sometimes one a month. You release when you can. A deliberate approach to frequent releases means a regular, sustainable rhythm.
  • It keeps us honest. In order to achieve our goal, we need to be able to keep our build ready for release continually.
  • We don’t have to think about when to release. An opportunist release process means that you need to continually agonise over whether ‘now’ is a good time to do a release or not. That decision can take time, effort and (possibly) a great deal of thought. Agreeing to release every Wednesday means that our ‘when should we release?’ problem is solved.
  • We don’t want to drown our users in updates. We think that one release a week is frequent enough for users to get their hands on the latest work we’ve done and give us timely feedback, without the update notification becoming irritating.

How we’ve optimised our approach for Release Wednesdays:

  • The team are responsible for the releases – they decide when things are shipped. In parrallel, I’ve encouraged them to buy into a weekly release cadence and do my best to coach them when they discover obstacles to delivering stories. Without the team being behind this initiative, it was not going to work. Once the team had tried it and liked the momentum we achieved, the approach was here to stay. Now, getting then current story done in time for next Wednesday is hugely motivation for the group.
  • We’ve streamlining our release process – automating everything we can and simplifying everything else. For example, we rely on automated testing to prove builds and, thanks to an internal tool, we can deploy to Production with the click of a button. See my post from 2013 about the benefits of automated deployments.
  • We break our work up into small, incrementally valuable user stories. This is so that they can be integrated into our weekly cadence – each story should be around a week to two week’s work for the team. This is obviously a bit of a black art, so we’ve had to think a lot more deeply about the scope of our user stories and their relative value. We have found that we have a much more ‘agile’ backlog and a good feel for what we can achieve in a week.
  • We keep the product code in a continually releasable state. This is a working agreement and has pushed us to use separate branches for each feature, user story or bug fix, so that the root of our source control repository only has work that is fit for immediate release. An additional benefit of this is that any parallel streams of work (e.g. a new feature and a big fix) are isolated from one another and so can be shipped independently.
  • We apply the Agile Release Train technique, which has brought it’s own benefits – #NoEstimates, Team-driven scope management and clear planning horizons. See my recent post on the Release Train for more details.

Just to be clear, almost all of these optimsations have caused us problems from time to time. For example, we sometimes find it difficult to keep within the bounds of our small stories and the pressure of always want to get something finished for the next Wednesday can feel relentless if we are not mindful of it. It’s also fair to say it’s not going to work in every environment, with every kind of software development project. However, we build a COTS product which is installed on hundreds of client machines across the world and it works well for us. I really beleive the benefits of a deliberate, weekly release cadence far outweigh the disadvantages.

I’d encourage other teams to experiment with Release Wednesdays – well, to try deliberate releases on a day of your choice at a fixed cadence (weekly, fortnightly, even monthly). We probably shouldn’t all choose Wednesday. If the enitre world released their software on the same day, it might be a bit wierd.