It’s been over three years since I wrote my post Four Types of Work in an Agile World and a lot has changed since then but it is still, by far the most popular post on my blog. I wanted to take a minute to revise the post as I believe things have changed, in the industry in general – not just my head!
When I wrote about this topic originally I described the four types of work introduced by The Phoenix Project as:
I discussed how we used the product backlog to mange the first three and introduced slack into everyone’s sprint and a SWAT team to mop up as much of the Unplanned Work as possible to avoid it jeopardising the planned work.
Over the subsequent years I’ve considered this a little futher. Partially as my knowledge of DevOps and Scrum have grown, but also because – let’s face it, no one wants to be in that SWAT team!
The first change I’d make to The Phoenix Project’s famous 4 types of work is to recognise that in reality all work is either Planned or Unplanned. Internal Projects are a type of Planned Work and Changes are an implementation phase of both. Lets say instead we have:
Next I’d argue that my previous approach of having a distinct team to shelter the project team is incorrect. It’s another phase of waterfall, splitting different phases of the Develop, Verify, Run into different teams creating silos which don’t talk to each other or share learning. As someone once said – if it’s you getting paged at 3am because the website has crashed you’ll quickly make sure you resolve it in office hours!
Teams must be either orientated around projects or focused on delivering platforms as described in Team Topologies. Those teams must ensure the entire lifecycle from design to operation. To do anything else is to isolate that team from the user and reduce feedback see DevOps 2nd Way).
These teams must also ruthlessly hunt down and eliminate the technical debt which leads to this unplanned work. Creating a buffer team to try to contain the work will only last until lack of feedback and continuously declining quality consume that buffer and overflow back to the development team.
Tech Debt can only be paid down by:
Increasing the frequency of deployments (thereby decreasing the delta).
Allocating between twenty and thirty percent of the team’s capactity to preventative maintenance and tech debt work.
Improving operability and monitoring in production.
Teams have to be utterly ruthless when they resolve issues in production to take action so that they can’t happen again. Or at least that they will be much easier to detect and resolve the next time. Unfortunately, many businesses do not invest the time necessary to maintain their own products. This leads to conflict between the teams and the business and ultimately fails both sides.
This is where it is so important to have your Product Owner on side. I won’t attempt to duplicate many excellent articles on the value of paying down tech debt and having that conversation. I’d only be repeating the words of others. What I would say is that providing meaningful metrics on code quality using tools like StyleCop, Fortify, and SonarQube help quanitify the risk to the business of continuing to operate in this way.
If you want to get your Planned Work back on track you need to hunt down and destroy the sources of Unplanned Work (this is not to say you shouldn’t respond to change when it comes along). It means that Unplanned Work is a symptom of technical debt, either in the form of bugs, lack of clarity, or poor operability.
If you want your team to be able to get on with improving your product, you need to ensure that they aren’t getting distracted by people struggling to use it – otherwise you won’t have anyone wanting to use it at all!
After I wrote about Getting Things Done last week I began to think how the GTD approach could work for developers working in a Scrum Team.
There’s no doubt in my mind that scrum is one of the best working processes for software development teams (yes there are others but scrum is incredibly prevalent and many teams across the world have a lot of success with it). However, having an effective scrum process does not guarantee that developers are productive or that they remember to complete the myriad of other day to day work tasks.
But let’s talk firstly about why GTD can help developers and why it’s not just another process to follow. Have you ever turned up to a meeting and had that sinking feeling when you realise you’ve forgotten to do your actions? Have you ever forgotten your timesheet? What about those times when you have tried to get your head down to write code but can’t quite forget all the other jobs miscellaneous jobs which you have to finish before the end of the day? This is because there are many tasks associated with your role which do not relate to the product or the team.
As well as writing code we ask our developers to complete an endless array of other tasks such as regulatory training, end of year reviews, interviews, timesheets, and other initiatives. These, in my humble opinion, have no place on a Sprint Backlog. They’re not for the value of the team or the but they do detract time from the sprint. Annoyingly, we we don’t provide a mechanism for developers or testers to track these if we’re not using the board – we just expect them to “be organised” and somehow find that time during a planning session. This isn’t fair and it isn’t good enough.
Our goal has to be to assist developers with the tasks their job requires which don’t fit nicely into a sprint format.
Before we go any further I’d like to point out that GTD and Scrum are not entirely unrelated ideas. The five steps of GTD are:
These match up almost perfectly with their scrum equivalents of:
Sprint Reviews and Retrospectives
David Allen, the creator of GTD, suggests reviewing your entire project list every week to ensure actions are kept up to date and nothing is missed. This process draws many parallels to a team reviewing its progress against a larger goal in a Sprint Review.
Implementing GTD for Developers
But how would you go about implementing GTD for a developer without treading on the scrum process? The first thing to realise is that the two frameworks manage work for different areas. Scrum is about product development, GTD is about managing your personal workload. There’s a crossover, where you’re working on work specifically for the product (hopefully a significant part of your day), but there are also significant areas where both work independently.
The first step, as with pure GTD, is to capture everything. This can be on paper, on your computer, or in a notetaking app. This list will form the basis of your in tray and should contain everything which is in your head or on your desk at the moment. You can limit it to work, but personally I’d recommend including your personal life too.
Your list may include items like:
One of the key tenants of GTD is to move all these items out of your head and into an inbox. Free up your brain for making decisions and having ideas not for storing stuff which would be better suited to a piece of paper. Chances are the first time you run through this you will end up with hundreds of items on this list, far more than you ever expected! If you find yourself slowing down take a look at the GTD Trigger List to see if you can tease out any more and I’m sure you’ll think of a few you’ve forgotten.
Don’t be intimidated by the sheer number of items you’re finding now. They’re already in your head, the only difference is now you’re seeing that list for real. If we can visualise it, we can throttle the number of items in progress – just like you would on a scrum board.
Going forward you’re going to capture items as soon as you think of them you don’t have the chance to forget them (remember what we said about remembering actions from meetings?). This list should never grow this large again.
Capturing Actions From Email
Email can be a particuarly tricky one so I’ll cover that one specifically. I recommend creating three folders:
I’ll explain about Waiting For later on but I want you go through your inbox and move every single email into either Action Required (you need to do something with this) or Archive. If you added it to the first folder, put it on your list.
Your goal should be to repeat this process at least daily. Remember your inbox is just that – it’s an in box. You should empty your inbox and decide what to do with it (not necessarily action it) as often as is reasonably possible.
Once you’ve constructed your list from your mind, various postit notes, your scrum board, and your inbox you’ll have a lot of work on your hands. I’m expecting you to have well over a hundred items. However, this list makes sense to you now but it won’t after a days (or even hours). We’re not going to complete these items all at once and we need to know that whenever we come back to then will still be clear to us. We want to record actions, things we are going to do – not just vague bullet points.
Implement login functionality
Reply to Billy’s email requesting feedback
Call hair dresser to confirm appointment
Reply to boss’ email and answer question
Check metrics on live site are within expected range
Note that all of these are now specific things for you to do, not vague points designed to remind you. David Allen (the creator of Getting Things Done) teaches us that one of the biggest causes of procrastination is not knowing what the next action or decision should be. Save your future self from that frustration by deciding what is actually needed right now, before you file it away to be done in the future.
GTD uses projects to organise work. The definition of a project is very broad.
“Projects are defined as outcomes that will require more than one action step to complete and that you can mark off as finished in the next 12 months.”
We’re going to use the actions list you captured to create your project list. I would recommend you keep a couple of high level projects to group various pieces of work together. I use:
However you should choose the ones which seem most appropriate to you. Within each of these I would create a project called One Off Actions.
Next you’re going to work your way down your inbox and create and organise as you go. The question you should keep asking yourself is whether your task is part of a wider project or if it’s a one off action. At this point you should also make a note of any deadlines for any of your actions.
Organising Actions Which Relate to Scrum Tasks
Many of the actions you have will relate to work you are currently undertaking on behalf of the scrum team. Code this, Code Review that, etc… There are a couple of ways to approach this. You could either create a duplicate item on your own system to track your work on the scrum board or you could ommit these from your personal system.
There are advantages to both. Having work listen on both makes it less likely you’ll lose track of something however at the expense of organisational overhead and keeping things in sync.
Personally I would recommend that you don’t track work you are doing as part of the scrum team in your GTD system as I would want to create a single source of truth. However, as long as you’re consistent I don’t believe there’s real harm either way.
As you are working through your actions you will undoubtedly encounter projects which are waiting someone else to complete an action. One of the most common reasons projects go off the rails is because a task is sat with someone and it is never followed up. This is where the additional folder we created in your email comes in useful.
Whenever you have an action which is sat with someone else tag that action with the word Waiting. I would also record the date it was delegated, the name of the person, and the date you wish to follow it up. Depending on the technology you are using you will have different mechanisms for doing this ranging from reminders and tags to simply changing the title.
Drop any corresponding emails into that new Waiting For inbox folder so those messages are always close at hand. BCC yourself into any emails you send asking for someone to pick something up and drop it in that folder!
If at all possible keep the action sat in the same project folder, this will help maintain context with the overall project.
Agendas are one of the hidden gems of GTD. Inside your work folder (although you could possibly do it for others too) I want you to create a folder for Agendas and then others underneath for:
1:1 with Boss
Along with any all hands calls or mentorship sessions you take part in. These folders represent everything you want to discuss in those upcoming meetings. This means if you have an issue you need to speak about you will never have that frustraiting feeling of not being able to quite remember what it is.
This means you can gather frustrations or highlights for the retrospective throughout the week and make a list of items you want to talk to your boss about rather than having to think of them on the spot. You can also capture any items which come from either of those two meetings quickly and easily in your inbox for clarifying and organising later.
Once you’ve raised your point and got your answer you can check them off. Remember you can use Waiting For if someone doesn’t have the solution for you right away!
While creating your actions is it often helpful to tag (or otherwise highlight depending on the technology you are using) the next action which is required to move a project along. I also tag my actions with Email, Phone, and/or 15Minutes to help me catagorise each item so I don’t have to jump from one application to another and can pick up quick tasks in between meetings.
By now you should have a list of all the actions you have committed to and their appropriate due dates. David Allen recommends you should reseve some time each week to zero your inboxes, review your projects, next actions, waiting for lists, and agendas and I would agree.
You’re looking for anything which is out of date, irrelevant, or no longer needed. You’re also looking for the next steps to progress your projects.
I would add one add additional suggestion. Ensure you schedule your personal GTD review before your sprint ceremonies. If you don’t have a clear vision of your commitments outside the sprint then you are never going to be able to give a fair view of capactity in those planning sessions. If you know you’ve got a large task to complete for a senior manager you’re now aware of that task and can take on less work in the sprint planning session.
Now we’ve got this wonderfully organised list of work it’s time to do some! There are a number of ways for deciding what to work on:
How long it will take
How urgent it is
Whether you have the right tools required (and to a degree the inclination) at that time.
Obviously the vast majority of your time will be for scrum tasks (or at least I hope it would be). However as we mentioned at the start it’s important that these other pieces are picked up and not forgotten about. I would recommend finding a certain amount of time each day to review this list and look for any actions and make sure you have plenty of time to complete them before their respective deadlines.
10 minutes at the start of the day (ideally before the daily standup) is all that’s needed to make sure you can plan effectively and you don’t miss anything which needs doing alongside your scrum deliverables.
A Note On Technology
I deliberately haven’t talked about technology in this post. The tool doesn’t make the system but it’s clear you’re going to need a good tool to keep this system working.
In his book David Allen talks a lot about Pen and Paper but also doesn’t go too much into digital tools (although personally I think he’s a little naive assuming that people won’t reach for an online tool first.
Personally I’d recommend Todoist, I find it very intuitive and reliable and they have a great GTD guide available which walks you through many of the suggestions I’ve made. However clearly there are other applications and tool available – please feel free to share any suggestions you’ve got in the comments.
In this post I’ve tried to explain why using a system like GTD is so important to developers and how it can be used to handle work which the scrum process doesn’t. I’d highly recommend having a read of the Todoist GTD Guide and giving their free version a go. If you have any other suggestions on how to integrated the two processes I’d be very keen to hear them.
I attended Agile Yorkshire last week and saw two great talks by Tom Hoyland and Jon Fulton. I really enjoyed both but a few points in Tom’s talk really interested me and I’d like to take a few minutes to share them.
Tom is a Scrum Master at Sky Betting and Gaming, I’ve heard good things about the company in the past so I was interested to hear one of their success stories. It turns out that Tom was part of a team of twelve who really stripped Agile “back to basics” and conducted a series of experiments on the road to continuous delivery. Working in a regulated industry myself I was intrigued how they’d got on.
One of the first things Tom talked about was how many different people in the team came to the table with ideas of what was agile best practice. We all laughed at his “my guru is better than your guru” but it makes a lot of sense! I am heavily influenced by Jez Humble, Gene Kim, and Clarke Ching but many of my colleagues may watch talks and read blogs from very different thought leaders. Tom explained that one of the first thing they had to do in the team’s formation was break many of the concepts down to their fundamental concepts and understand what worked for them.
Something else Tom discussed was how the team consolidated their own backlog. This was not controversial, how else would you prioritise the work against it? It was only when he gave examples of some of the different backlogs they’re identified that I became intrigued. Risk Logs, Retro Actions, and Design Session – all of these moved onto the board and each became visible and prioritised.
It’s dangerous out there – take your buddy! I’ve heard many of the advocates or pair programming before but the idea of your buddy following you into meetings, design sessions, and CABs!? Tom explained that if your buddy went with you to these sessions not only would they learn how to design, and walk work through the CAB but they’d also know the current state of everything you were working on. If you were sick or the proverbial bus came along the team wouldn’t need to bother you because everyone would know what was going on.
There were many other good ideas (and I intend to borrow quite a few of them myself) but the final one I’m going to mention was the idea that Velocity is in fact a vanity metric (read The Lean Startup if you have no idea what I’m talking about). Velocity is just a number, like Number of Users or Number of Page Views). What we want are actionable metrics, like team predictability and accuracy of forecasts. As a Development Manager I frequently use the team’s average velocity to forecast delivery dates, Tom recommended that there are better measures out there such as a temperature check of the team’s current mood (which would often dip before any reduction in velocity). It’s an interesting idea, and one I intend to think more about over the next few weeks!
A big thank you to Royd and the guys who put Agile Yorkshire together each month. An equally big thank you to Tom and Jon for their great talks!
I wrote recently about safety and how I’d describe it, I gave an example of a developer who suspected that a particular approach chosen by the team wouldn’t work but didn’t feel confident enough to speak out and challenge the design.
In this post I want to discuss just how serious that lack of safety is. Beyond that lack of a warning a lack of safety can lead to bugs, disengagement, and even resignations.
If you’ve not already read it then I suggest picking up a copy of 5 Dysfunctions of a Team but Patrick Lencioni. It really is very good!
To back up my statement over resignations I want you to think of the last time you disagreed with your spouse, friend, or family member folder what to do one evening or weekend. Maybe they wanted to go shopping or redecorate a room. I want you to think about how you felt doing that activity and question whether you really gave it 100%
Not really being engaged is hardly unsurprising. Let’s say you wanted to see one film but you were talked into seeing something different. Are you really going to admit that you enjoyed it or will you secretly (it not so secretly) believe that your choice would have been better?
The point of this simple example is that humans struggle to commit to an idea while they still believe that their option would have been better. When we have joint design discussions if someone has an idea and doesn’t voice it or has concerns but gets shot down then they will never feel like their voice has been heard. They become disengaged from the end result, because they never wanted to do it that way anyway. It’s not malicious, it’s a defence mechanism because don’t want to admit that out way wasn’t better.
Only be encouraging all team members to openly discuss their ideas so we gain not just consensus, but buy in. As for staff retention, if your team member never feels bought into the work because they don’t feel like their view is listened to, how long do you think they will remain in that team?
To explain the reason for this post I should probably take a step back and explain that I’m currently fascinated with system design and the idea of workflow as described in The Phoenix Project and The Goal. I should also add (in case there’s any doubt) I hate shopping! So as Lucy and I were stood waiting in line on a particularly busy Saturday morning I had an epiphany.
Because I didn’t have anything better to do I mapped out the process in my head. The boxes on the left represent the customer, the ones on the right the cashier – at the end of the process they would tell me how much I owed and I’d dutifully hand over my money.
You’ve probably been involved in this process firsthand!
As I was loading my shopping onto the conveyor belt I couldn’t help noticing that the process wasn’t smooth. For a few minutes the belt would keep going, I was adding more and more groceries into the queue – then, for no reason I’d have to wait until more space became available.
I became convinced that if I wasn’t forced to endure this wait then the whole system would balance nicely, after all – the checkout assistant seemed to be able to scan groceries as quickly as I could load them (input and output were reasonably balanced). Then suddenly, frustratingly he would stop and complete the transaction with the customer and I had to wait for more space to become available.
In my mind the entire system mirrored a typical release schedule – features are requested, created, and released. The last part, the creation of a signed off build is often what holds up the process (either through bug fixing or code freezes) and that was exactly what I was seeing here.
Scrum practitioners advocate having a build which is good enough to ship at the end of your Sprint, this prevents large delays being caused in your process and helps make your deployments routine and safe. I’ve written previously about the quality benefits this can bring.
As I looked around me in the supermarket I began to wonder why there wasn’t a second person on the till. One could scan the items and the second would complete the transaction to ensure the workflow continued uninterrupted. That was when I realised that many have introduced something far more revolutionary!
Consider the new Scan as you Shop processes popping up around the country. These hand held devices let you scan your purchases as you work around the shop, this reduces the over complicated process above to this much simpler one:
This simplified process reduces the need for staff and makes the entire end to end process far more efficient, there are even customer benefits such as being able to keep track of your trolley’s value as you shop. The supermarkets are so keen that they’re even willing to take financial risk on you not to steal their stock!
Tesco, by reworking their system have simplified their process and hugely increased bandwidth – I wonder if there are any similar process changes can we make in software development which will have such drastic effect our productivity?
*Thanks to draw.io for the flowchart software I used to create these images.
If you find yourself reading the Agile Manifesto (as for some reason I do from time to time) you may notice this:
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
I don’t think anyone would disagree with this. However in these days of satellite offices, home working, and outsourcing your team members are often scattered across cities, countries, and time zones you may not have the luxury of every team member sitting in the same room.
So what can you do?
There are a few tricks and tips I’ve found help you keep a high level of communication between team members.
Ensure your daily standup times suit everyone. Make sure it doesn’t force people to start early or stay late, consider people’s lunch and prayer times. There’s no golden rule saying you must meet at 9am!
Use tools like Trello to move post-it notes online.
Keep a running channel open for informal chat (such as Skype or Slack) and switch important notifications onto email so people don’t miss important information.
Work from home yourself, experience any pain points of your remote colleagues your are describing and aim to resolve them.
Use video calling. We were a little reluctant to start this but after years of Skype the difference was noticeable, remote team members were more engaged and banter was at an all time high.
These are a few of the tips and tricks which have worked for us, what do you do to help your distributed team thrive?
Let me start by saying I’m a big advocate of scrum (despite some of my posts in which I challenge it over and over again). Having said that it has it’s weaknesses (like any process), one I’m going to highlight in this post is the insular nature of some scrum teams.
The best way to explain this is to describe my own experience. When I started in the Scrum Master role I was very keen on continuous delivery and wanted the development team to produce a build every two weeks which could be supplied to the business to decide whether to deploy it or not.
We had a lot of projects on at the time and we were working very hard to meet the commitments my predecessor had signed us up to and get features out the door on time.
This went on for a month or two, we hit every deadline in the calendar and provided the builds to the deployment teams on the dates we’d agreed. So what happened? Nothing…
What I’d failed to realise was that despite our hard work over the last few months we’d failed to release a single new feature to a customer. The deployment teams had struggled to install our software into UAT and without any contingency (except when it was carefully planned for) we had no capacity to assist them or pick up any issues – until the next planning session of course (where usually the next feature was the most urgent due to “customer commitments”).
Development kept on working, features continued to be produced and deadlines were hit. But the customers were sat waiting, UATs couldn’t be completed (or in some cases even installed), and the business because frustrated with us because we weren’t available to help them get the product out the door.
So what went wrong?
This is where you may have to forgive my sleight of hand in the title. I don’t believe the problem was with the scrum methodology as such, merely the most common implementations of it. The first oversight was the handover, the second was the goals of the team. Let me explain…
Firstly the handover, the issue wasn’t that it was sloppy or that it we didn’t have consistent priorities across the business (although that certainly didn’t help). The issue was that we had one… A scrum team should contain all the skills and knowledge required to get a feature from concept to customer. Rather than handing builds over to the business to deploy we should have had someone from the deployment team working in the scrum team who would actually do the implementation. The team itself would then support the new feature through it’s UAT phases and out into the customer’s live environment.
The second failing I mentioned was the team goals. I have already alluded to this but the goal of the team was to “write this feature” whereas it should have been “deliver this feature to the customer”. Only once that goal has been met should they move onto the next one.
This continuity and accountability is a very powerful thing. Projects fail when departments don’t communicate with each other or their priorities are not aligned. Systems slow when there’s too much Work in Process (for example incomplete UATs) clogging up the pipeline and generating unplanned work. If you want to break out of this cycle you need to stop thinking about departments and handovers. Stop thinking of scrum teams as groups of developers delivering feature after feature and start thinking of projects being created and delivered by teams of people from all the disciplines you need.
If you can do that, then you can make your scrum team work for the business and not only for it’s own productivity.
We all do them, Daily Standups are the quintessential activity of a Scrum Team. Each morning the group gathers, discusses what they did yesterday, and what they plan to do today. The tone is monotone and everyone sips away at their thick treacle-like coffee in an attempt to remain upright while a few of the younger developers attempt to conceal hangovers which would force anyone of your advancing years to cower under a desk.
For me the daily stand up is one of the easiest Scrum practices to implement and therefore is often forced upon a team so they can claim that they’re “agile”.
As with many Scrum components the value is not in the compulsory attendance but in the enlightenment when a member of team suddenly has a lightbulb moment and understands why a practice is of use to them.
For me that moment came when I realised that the Yesterday and Today section of a Team Member’s speech is simply window dressing. It’s interesting certainly, it may even help the Team Lead or Scrum Master measure burndown but the real value of a Daily Standup is in the often neglected Impediments section.
During our working day we encounter and resolve countless impediments, those which prove to be more troublesome are raised in the standup where (more often than not) time pressed colleagues mutter a few words of advice or encouragement before wandering back to their own tasks.
This way of raising issues actually dampens the team members’ enthusiasm for “Any Impediments”. After all why should they raise them in scrum when they could simply ask a more experienced colleague quietly, later in the day. I know I wouldn’t want to admit I was struggling to my Team Lead if there was no increased chance of getting help.
So what do I recommend?
I suggest that each Scrum Master take a pen and paper into the standup. As well as facilitating the meeting they need to capture the team’s issues and impediments. At the end of the meeting it is their job to resolve them. More often than not this will involve finding the correct people to lend assistance, be they infrastructure guys, senior developers or management.
The Daily Standup is not a progress meeting. It’s an opportunity for the entire team to come together and check that no one is struggling with an impediment which will impact the team’s ability to deliver at the end of the Sprint.
Remember that a Sprint is not about individual completion, it’s about the team and this is everyone’s opportunity to keep the group on target so they can meet their combined goals.
My induction into my informal position of Scrum Master was rather quick, a member of staff was leaving and the team needed someone to help run the meetings. Learning fast and jumping straight in at the deep end is my typical (if not favourite) way of learning so I rolled up my sleeves, read a few books and did my best.
So what have I learned? What dubious advise could I pass onto any developer who finds themself stepping into the same role?
Know your Ceremonies
The Scrum Master’s week is punctuated by meetings such as Daily Standups, Planning Sessions, Sprint Review and Retrospectives. You’ll encounter resistance to these because devs like writing code, they don’t enjoy spending hours each week sat in the meeting room. You’ll need to justify these sessions, if you can’t explain why you want to meet then it’s best not to!
This is the most common session you’ll be expected to run. It’s also the most famous, many businesses claim to be agile simply because they have a daily standup! Getting it right is key to your team’s success.
First the obvious question, do you actually need to stand up? No! People who have never attended a standup will challenge this methodology, there are advantages for and against standing up for the meeting and you need to understand both sides if you want to discuss the reasons. On the one hand physically standing encourages participants to keep their part short and on topic, I also like to guide speakers around the circle so everyone knows when they will be expected to talk and no one is left stammering. On the other hand standing up can be very difficult for distributed teams, meeting over Skype with headsets reduces lot of background noise but brings with it the inevitable technical problems and opens the unending source of distractions which is a dev’s PC. There’s no right answer, but different teams will prefer one style or another.
Keeping on topic is a huge challenge and one I’m still struggling with. Your standup should consist of three bullet points
What did you do yesterday?
What are you aiming to do today?
Are you blocked in any way and are you on track to burn down?
In my experience there are two main reasons for a scrum wandering off topic, these are Story Telling (going into too much detail about what they did yesterday) and Problem Solving (using everyone’s time to try and become unstuck). Devs love to talk about challenges they overcame and solve other people’s problems. The key is to spot when this occurs and suggest that these conversations can be had later.
The sixteenth minute is an interesting idea, as I mentioned above one of the main reasons for scrums dragging on is people trying to utilise the entire team to solve their impediments. One approach is to formalise an optional follow up chat for the required parties so they can continue to discuss issues without hindering the rest of the team. Keep an eye on how many of these follow up conversations are needed, too many and they rapidly take over the team’s morning.
I’ve found the key to Sprint Planning is preparation, this can often be an issue when the meeting is scheduled for first thing on a Monday morning! Before you walk into the planning session you should have:
The backlog prioritised
Details of the capacity of your team (or team members if you plan individually)
Details of how much work has been carried over from the previous sprint
If you don’t have this information to hand you’ll need to acquire it in the meeting, this is all information you should have access to through your planning software. Asking for it in the meeting wastes everyone’s time and leads to boredom and the feeling of wasted time, not how you want to start your sprint!
Armed with this data your planning meeting is simply a matter of dishing out the highest priority tasks to the team members who want to pick them up. Simple!
The purpose of the Sprint Review is to demonstrate what you’ve built to the stakeholders and other interested parties, this can often be your Product Owner, Support Team or other devs. These people then have the opportunity to provide feedback which can be considered, prioritised and included in the project.
The problem I often find is that there are so many ideas, so many discussion points and so many questions that your one hour slot is barely enough to get through the first demo. So how can we address this?
Nominate a single person to make note of the suggestions, by making sure everything is written down no idea is wasted and they can be prioritised and scheduled with your Product Owner
Consider recording videos instead of live demos, the live demo is a bane of any presenter. By asking your devs to record videos in advance the demos are foolproof, there are no unexpected technical problems and you know exactly how long each video will last!
Save questions and feedback until the end of each presenter. We are geeks, not public speakers, give your developers a chance by letting them get to the end before bombarding them with suggestions on how to improve the task they’ve been slaving over all week!
A fundamental part of the Agile Manifesto is that teams should look at what went well, what they’re struggling with and adapt their processes to improve. Often this is done in a retrospective meeting.
When I first started doing retrospectives we followed a well known pattern
What went well?
What didn’t go well?
What should we start?
What should we stop?
We worked our way around the table and everyone was expected to come up with a suggestion for each list. I found these meetings rather unfulfilling, I often felt they descended into a rant about process, other teams, technology or whatever else was irking the group at the time. While I’ve no doubt that it was good therapy I didn’t feel like the hour achieved much.
Instead I’d suggest planning each meeting with a specific topic
How can we ensure that high priority support requests are picked up mid sprint?
Should we use Web API or WCF for our new API?
How can we get clear acceptance criteria for our upcoming bespoke development?
By stating what you hope to achieve from the retrospective in advance you stand a much higher chance of success! Ask your team for items they want to discuss, email around your proposed meeting topic with plenty of notice and ask your devs to bring their own ideas to the meeting.
Hopefully I’ve given a few helpful suggestions for you to consider. I don’t claim to be an Agile expert and I’m still struggling to follow lots of my own advice but every sprint we learn a little more… Isn’t that the point after all!?