I like retrospectives, actually, I love retrospectives. Especially retrospectives that really get to the root of any problems the team are having and then get a great solution or at least something to try. The trouble is, retrospectives can often be stale, how many times have you been in a retrospective and had this:
So, um, yeah, good sprint, I think everything went well, didn’t it? I had a problem with some testing, but I fixed it. What was it? I can’t remember. Something to do with fixtures, but it got done.
The problem with memories is that they’re fallible. Who can remember what you did two days ago, let alone a week ago. Certainly me and, it appears, neither can the teams I coach. There are things, youcando to make retrospectives better, but this wasn’t so much a problem with the retrospective as a problem with memory. So, what did the teams do? Added a timeline to their sprint backlog. It’s quite simple really. Create a grid on the bottom and, in every standup, discuss whether anything happened yesterday that could be added to the board. The idea is to get key things on there, so, stuff that went wrong, stuff you noticed or learnt, good stuff; use it as a way to remember the timeline of the sprint. When you get to the retrospective, you’ll then have an entirely different conversation than the one above.
Some of the teams have gone a step further and added an arrow to remind them which day of the sprint it is and even added holidays/absences. What do your teams do to remember their iteration?
I’m a big fan of whiteboards. I’ve got a bit of a reputation at work as someone with an unhealthy desire for many whiteboards. As I sit here, I can see seven. There are three more in the office I can’t see and another four waiting delivery.
Ron Jefferies speaks at length about how big visible charts are a “good thing” (he echos Alistair Cockburns sentiments on having Information Radiators) and so, in the name of throw-away blogging, and because I don’t have any link baiting “10 reasons why… ” posts, I thought I’d add one. 😉
The elephant in the room.
Whiteboards are there in the room with you. You can’t do anything without having it there, reminding you it’s there and what is on it. With a digital tool, you need to go and find it, on the web, on the intranet, on demand.
The ice breaker. They start conversations. People will gather around a whiteboard (especially if it is a sprint backlog) and discuss its content.
The flexibility. Things can be changed, moved around, re-ordered, annotated, etc etc without fuss or hassle.
The process. The manifesto says “Individuals and interactions over processes and tools”. Use the flexibility of a whiteboard to help hone your process, before committing to a tool which defines a process for you. The structure can be changed REALLY easily. Need a new column? Different chart? Another colour? Silly picture? Stick it up there, instantly with a pen. You’ll probably need to program, request or configure these changes with a digital tool, which takes a LOT longer.
The culture. They help a team define their culture. Each sprint backlog whiteboard where I work is a little artefact which reflects the culture of the team and it’s members. One is clean accurate and ordered neatly, another is messy and colourful with pictures of Transformers. You can tell a lot about a team from the sprint backlog whiteboard.
The collaboration. Product owners, stakeholders and interested parties can see what a team are up to and, importantly, collaborate with the team as they’re standing next to them when looking at their board.
The disposable information. You only need to measure something for as long as it is useful. Need to chart the performance of your tests over a release period? Perhaps you want to chart users of a particular feature temporarily? The whiteboard allows you to track this information, with no overhead and comparatively little investment compared to a digital tool.
The doodle. If you’re trying to explain something to more than one person, a doodle, or sketch may help (especially in development, when you might be describing a class structure, or some architecture). You’ve already got a whiteboard in your team area for your sprint backlog, use the other side?
The wheels. I advocate whiteboards on wheels, these can be dragged back and forth between the team area and meeting rooms if needed. You don’t have to worry about logging in to a meeting room PC, getting the digital tool up, logging in to that, then increasing the resolution, or zooming with the browser so everyone can see, then clicking to the right section then … you see what I mean? Take your whiteboard and your pen.
The end. Often it’s nice, when you reach the end of a release window or the end of your tether, to just wipe the board clean and start again. Get some solvent, give it a good clean, redraw your columns and start from fresh. It’s cathartic and cleansing.
I read in my twitter stream today, this from @lloydwatkin:
I really hate bullshit phrases used in tech, my latest word of hate is ‘timebox’ 04/05/2011 15:16
and it got me thinking about time boxes. I use the word a lot and use the concept of time boxes in almost everything I do and Lloyds comment made me think “is this just a bullshit idea, or just a bullshit word, or bullshit in general?”
When meetings suck
I don’t know about you, but I’ve sat in my fair share of meetings that totally sucked. No one really had much to say, the conversation goes off on tangents, someone announces that we can’t talk about that now as it’s part of a ‘series of conversations that we need to have’ and everyone inwardly groans. There’s no agenda, no action points … nothing. Usually one person will dominate the room, quacking on as if they love the sound of their own voice, making statements based on little more than opinion, causing everyone in the room to raise an eyebrow and, maybe, an eye from their game of Angry Birds under the table. People pretend to take notes on their pads on their knees, when really they’re drawing larger and larger concentric circles and colouring every other one in while perhaps writing a poem, or ode to boredom*.
These are the meetings that everyone hates, when there are too many people, no agenda and people prone to waffling about shit only 20% of the room understand or care about. How does time boxing help here?
An agenda is a time box. If you’re booking or facilitating the meeting, you’ll find that an agenda and the authority to chair the meeting are all you need to have a successful outcome (assuming you have an idea of what the outcome should be). When you book the meeting, set the agenda in the meeting request:
00 – 10mins – Welcome and introduction
10 – 20mins – Talking about the herping
20 – 30mins – A demonstration of the derpa-machine
30 – 40mins – The future of the thing
40 – 60mins – Q&A, action points and AOB
These are time boxes. Maybe you don’t call them that. Most people call them agenda points and many people will leave off the timings, but by adding the time boxes to it, you’re subconsciously telling the attendees that, unless something extra happens, this is what we’ll discuss and this is how long you can expect it to take. If 50% of your attendees don’t care about the herping and 50% don’t care about the derpa machine, then those people know exactly how long they can draw concentric circles or play angry birds for. Or, they’ll know they only need to give 10mins attention to something they’re uninterested in and that’s better than 60mins attention to find the 10mins you’re interested in. Doing an agenda will also give people time to think about what they should be doing to prepare for any, all or just their part of the meeting. Finally, by setting a perimeter around an acceptable length of discussion time gives you the authority to say: “OK, we’ve run out of time for that agenda point. Batman and Spiderman, if you have more to say on this matter, please book another meeting and invite those people relevant. OK, so onto the next point…”. Trust me, people will be relieved.
So, by simply adding some timings to your agenda (which we can agree are useful) you’ve created time boxes. Things look good for time boxes so far.
What about meetings that can’t have an agenda?
Well, some meetings can’t. In SCRUM there are two that definitely don’t have any kind of official agenda; retrospective and sprint planning. Retrospective is a meeting where the team discusses HOW they did the work in the last sprint and what could be done to make it better. Generally, this involves everyone taking turns to say what they though was good, bad and how they think it might improve. Timeboxing here lends itself well in that, you divide the length of the meeting (in minutes) by the number of people and that’s how long each person get’s to speak for. They’re each time boxed. If there are six people retrospecting for an hour, they get 10 minutes each.
As for sprint planning, you can do the same with each section and then the stories. You’ll have to play with timings, but I suggest:
00 – 10mins – Cocking around that devs do getting coffees etc. 😉
10 – 3omins- Quick groom of the backlog
30 – 60mins – Work out velocity and commit to stories
60 – 240mins – This is where it get’s fuzzy. It all depends on how many stories you’ve committed to. If you’ve committed to, say, three. Then divide the remaining time by three and get on with it. If it’s many stories, then perhaps set aside 45mins for the first story, 30mins for the second and 20 mins for the rest. Remember, you don’t have to do all your planning up front!
So, score two for time boxes. Without time boxes, sprint planning would but much harder and probably longer. Besides, they’re also one of the basic rules of scrum!
But that’s not all…
When scope creeps
Imagine, if you will, that you’re working on a bit of software, or a website and you show it to the stakeholder. They say “Hey, that’s nice, but can you…” and then give you a list of amends, some of which are huge. Welcome to scope creep.
If you’ve been in software or web development, you’ll have been a victim of scope creep. You get the list, you work your way through it and, all of a sudden, you’ve run out of time.
“But wait, ” you say, “surely time boxes cause this ‘lack of time’ problem.” Well, yes and no, but they definitely provide you with a reason NOT to do the stuff that has crept out of scope. Scrum is based around the idea of time boxes. Without them there wouldn’t be iterations. An iteration, or a sprint, is a timebox. Sprints don’t get extended, or shortened (although they can be cancelled). At the beginning of a sprint, the team commits to a bunch of stories that the product owner wants done. They work on them and, when nearly finished, will show the product owner or stakeholder who might say “Hey, that’s nice, but can you…” . To which you answer…
“… No, but if you wait unti the end of the sprint and ask me, I’ll do it then.”
Anybody reasonable can see that it’s a good compromise: work has been asked for that is clearly out of scope. The developer doesn’t have time to work on it during this timebox, but the timebox is there, defined and immutable, therefore can be used placeholder for when the work CAN be done (apart from the fact that the extra work needs a user story and estimation and prioritisation etc) and the stakeholder or product owner only has to wait until the end of the sprint (the maximum wait will be two weeks). Usually, by that time, they decide it’s not a relevant change anymore, or it was so insignificant as to be forgotten.
The point is, it’s there to add some boundaries, to protect the developers from scope creep and to protect the stakeholder from adding work that isn’t well thought out or valuable (this is quite a simplistic view, but it proves the point of the value of time boxes. Obviously, lot’s more comes from the scrum framework in order to derive value, but out of the scope (fnarrr!) of this article).
Right, so that’s three for three … next!
When the kitchen is a mess
So, when I said I use time boxes in almost everything I do, I meant it. I mean even my personal life and I suspect you do too (even you @lloydwatkin!). As an example which is fresh in my mind from last night: I was tidying the kitchen and had set myself some time boxes: 10mins to wash up, 5 mins to clear and clean the table, 5 mins to sweep the floor and 10 mins for extra stuff — 30 mins to clean the kitchen.
With these time boxes set for myself, it become a challenge to get this stuff done in those time boxes. And lo and behold, it takes 30 mins to do a chore which might otherwise take me an hour and a half (most of which would be procrastination). It also stops me from doing too-much-work (K.I.S.S!) as I might put something in a cupboard and think “Hmmz, that cupboard is a mess, I’ll just give it a quick tidy.”, et voila, scope creep.
Finally, time boxes aid immensely with parenting. If you’re a parent you’ve probably said (or shouted): “10minutes until bedtime!” and this creates an unwritten expectation (much like the meeting agenda or the sprint length) that, at the end of 10 mins, some action will happen (bedtime). Instead of the ambiguous “Bedtime soon!” which leaves it open ended and easy to abuse.
What to avoid
Boyles law states:
For a fixed amount of an ideal gas kept at a fixed temperature, P [pressure] and V [volume] are inversely proportional (while one doubles, the other halves). – Wikipedia
Which means, gas will expand to fill available volume. This law can also be used to describe development:
For a fixed amount of ideal developers kept saturated in caffeine, velocity and time are inversely proportional.
Which means, work will expand to fill the time allocated to it.
This is not always true, but you should be wary of it. Some teams will feel that, they have two weeks, so they can take it easy if they’ve underestimated a story or two. This is not fine. Velocity should remain constant. If at any point your teams feel they have undercommitted, then commit to more, or do something with value to the team – rebuild a tool, or refactor some code or SOMETHING and perhaps next time, commit to a little bit more and see if you can stretch a bit further. It’s a limbering excercise.
A time box is a limit, not a goal. If you’ve got a 10 minute time box in a meeting, or elsewhere, you don’t have to fill it, you just have to have finished within that time box.
Some time ago I held an Agile Dojo at Affiliate Window. It was an entire morning of grass-roots agile training, taking the department back to basics and helping them (and me) understand what ‘Being Agile’ means, there was an accompanying deck of slides, which I’ve redone in full on technicolor and without the need for me presenting them. This was for new starters and those that missed the session or needed a refresher. I thought I would post to slideshare in order to make it easier for people to view it, then I figured I’d post it here too. 😉
I was asked this a while ago and I’ve seen it mentioned a few times on blogs and forums and what not. I’ve answered it on a few occasions, so I thought I’d put it all into a coherent blog post.
Estimating a project before you start, with a brand new team is a tricky situation and one lots of people encounter.
There is a way you can work it out though, but your product manager should understand that it’s an estimate and it will change. If you need some backup, read this article on the ‘Cone of Uncertainty’ by Jeff Atwood and remember, you know the LEAST about a project right at the beginning!
How can I estimate?
There’s two ways you can do this; based on points or based on hours. I’d suggest using the hours method as it will give you a range. You can get a range with points as well, but only when you’ve done a few sprints. Some people are against estimating in hours and, usually, I am too. But for this “beginning of a project with a new team” exercise, it’s invaluable. The below all assumes that you have a product backlog ordered by priority.
I’ll start with the points method (and, step 1!):
Estimate, in story points, your entire backlog. This is easier than you think and is often called the white elephant method, we use it with great success.
Draw up somewhere a grid with 0, 1, 2, 3, 5, 8, 13, 20, 40, 100 and ? as labels.
Print out all your stories, or, if you’re already using index cards, just put them in a pile (but remember to put their priority order on them, so you don’t forget!) and put them in a stack somewhere.
Now, each member of the team gets up, picks a story from the pile and sticks it to the board where they think it goes. If they have NO idea, then they put it in the ? box.
Get everyone in the team to take turns in doing this. They must all do it in silence. Each turn they can pick up a story and place it on a board, they can also move a story that is already on the board, but they have to pick it up, face the team and say ‘I am moving this story because… ‘, then they can re-place it on the board.
This goes on until all the stories are gone from the pile and no one is moving stories anymore.
If you get two people moving a story back and forth because of a personal belief on it’s size, just have them put it in the larger number.
Now, pick the story at the top of the backlog and say “Can we do this in two weeks?” If the team says yes, put it on the board, this board represents your sprint. Pick the next story and say “Can we also fit this story into two weeks?” if yes, put it on the board. Continue until your sprint is full.
Now, assuming you’ve story pointed all your backlog and the total is 260 points, you’ve worked out you can do 20 points per sprint, that means it’ll take you 13 sprints based on story points (so, 26 weeks). This will be quite wrong, but will give you a rough idea. If your product manager is bit simple, he might start telling everyone it’ll be done in 26 weeks. So, do the next step too:
Ask each member of the team to estimate a max and min number of hours a day that they can work (taking into account meetings, phonecalls, emails etc etc that take time out of your productive, development hours); so Steve might say 4 – 5, Tina 5 – 6 and Hardeep 6 – 7. Work this out as hours per sprint. (So, Steve can do 40-60 hours per sprint in a two week sprint), with the above figures you’ll have a range of 150-180 hours a week;
Remove all the cards from the board and put them back on the backlog;
Pick the top story again, say “Can we fit this into a sprint?” If the team says yes, put it on the board again;
Next, break this story down into tasks and estimate those tasks in hours;
Do steps 3 and 4 until the team says they can’t fit anymore in the sprint based on the total number of hours (by adding up all the tasks) and their estimated man hours per sprint (ie: 150-180 hours per week as above), as a guideline, you should probably stop at around the 165 hour mark or, if the team cannot agree whether a story would fit or not, assume it won’t;
Add up the number of hours they estimated, now you have how many hours they can fit into a sprint;
Add up the story points for the sprint, this gives you your velocity.
So, you now do:
> total story points / velocity (from step1) = number of sprints based on velocity (don’t use this though, it’s a very rough guide)
> number of sprints based on velocity x (estimated hours for sprint (from step 2)) = total hours for project.
> (total hours for project) / (lower weekly hours estimate) = minimum number of sprints
> (total hours for project) / (upper weekly hours estimate) = maximum number or sprints
So, now you can say to your product manager, the project will take between 44 and 36 weeks (assuming two week sprints). Again, this is still only an estimate, but it gives you a better idea. Especially as you know the least right at the start. The best thing to do is provide continual updates to the PM. Once you’ve done a couple of sprints, you’ll have a better idea of your velocity and you should groom your backlog frequently (including re-estimating occasionally) to keep your estimated delivery fresh, based on the most up-to-date knowledge.
I’ve taken some queues from the article as he talked a lot of sense, and wrapped an agile spanner around it.
The key is in the name, ‘agile’. We should turn to the holy grail; the 12 principles and four core values of the agile manifesto when thinking about how to appraise people people in our department. The four main points to take from the manifesto when thinking about appraisals, I think, are (paraphrased for context):
People and interactions over processes and tools
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts it’s behaviour accordingly.
Continuous attention to excellence enhances agility
Simplicity is essential
So, with this in mind, we can see what an agile appraisals needs to:
Dispense with forms and formality and concentrate on the conversations;
Look at how the team can work better together.
Individual agile appraisals
In individual appraisals, the ‘team’ are the boss and his/her subordinate. The boss’ focus of an appraisal should switch from the traditional “How are you performing for me?” to, “How can we work better together?”. The idea is that, the appraisal is about doing things that make the relationship between the boss and subordinate better and allowing the subordinate to appraise themselves. What do they need to do to make their input more valuable and what do they need from their boss?
This could be in terms of more training, guiding, coaching, tutoring or it could also be in terms of their relationship “I need you involved more in what I’m doing.” or “Help coach me on unit testing”. The subordinate should talk about how they’re going to make the relationship better and the boss should reply with “How are you going to do these things and, more specifically, how can I help you do that?”. This also has the benefit of reinforcing the Stop, Start, Continue idea of appraising your boss.
The whole idea here is to inspect and adapt, to spend some time reflecting how things are going and suggest and then try some ideas for the next period which reinforce the idea of a ‘team’ relationship between boss and subordinate and to ensure that the subordinate improves on issues that are important to them as well as being beneficial to the greater good of making quality software.
Bare this in mind during any appraisal: “Given who I am and what I am learning about this other individual, what is the best way for us to complement each other in getting work accomplished with excellence?”
The appraisals should be regular, at least once a quarter and last no longer than one hour. An appraisal can also be arranged at a convenient time for both boss and subordinate if either feels that their working as a team is suffering for any reason or that something that was agreed isn’t working or needs a tweak. The notion of ‘annual appraisals’ is absurd in this context.
Team agile appraisals
Team appraisals can be run in the same way. These shouldn’t be confused with the sprint retrospective. The team appraisal is where the whole team gathers in one place for a time (not sure if a time box is relevant here, I think it should be no longer than half a day perhaps, but no less than two hours) and in turn, each person works on the mantra above (“Given who I am and what I am learning about this other individual, what is the best way for us to complement each other in getting work accomplished with excellence?”), says how they feel they could improve to benefit the team and then the team provides feedback on what the team member said and perhaps offer any help, or suggest ways in which the team member might meet that improvement.
This is not an opportunity to bitch and moan. This is an opportunity to inspect and adapt and reflect on how the employee works within the bounds of their team. This is like a retrospective in many ways, instead of being about the process, however, it is about themselves.
They have the option of having their manager present, but it isn’t essential and if they don’t want them, they should not be forced to have them. The team appraisal should happen BEFORE the individual appraisal, this will give the team time to reflect honestly on how they feel they need to improve without fear of reprise, and then take this to their individual appraisal, hopefully without modifying their feelings too much before they sit with their boss.
It should be made explicit that annual appraisals are nothing to do with pay reviews. Appraisals are NOT for showing off how wonderful the subordinate is, no one writes things down they’ve done all year, they just get on with their job and do the best they can. If the appraisal was about that, the boss and subordinate would be working at cross purposes: the boss wants to talk about how the subordinate can improve and the subordinate wants to talk about all the great things they’ve done. The pay review meeting (if there even IS one) should be entirely separate.
The appraisals are about improving working relationships, not about money. I can’t stress how important this is. Without this explicitly stated, it will undermine the usefulness of the appraisal.
Another issue to think about when using money as a motivator is that it will only work in a narrowly defined way. People will do EXACTLY what is asked of them in order to get the bonus, or the payrise. They will do nothing more and nothing less, just what is required to pass the test and win the prize. Mary Poppendieck had this to say:
Using money as a motivator is like playing with dynamite because money is a VERY effective motivator. Monetary rewards motivate people to do EXACTLY what is being rewarded – not necessarily what the organization intended to reward, but EXACTLY what is being measured to generate the reward. Therefore monetary motivators have a long track record of generating unintended consequences. If there is any apparent competition for the money, money motivates people to get as much as they can for themselves. Thus monetary motivators have a track record of suppressing collaboration. Finally, bonuses for performance rapidly come to be an expected part of the landscape, replacing passion and dedication as motivators . These are things you probably cannot change about using money as a motivator.
– Mary Poppendieck
Annual appraisals or performance reviews are supposed to be an objective evaluation of the employee that helps with determining payrises derived from performance and to let the employee know where they can improve. In reality, this is not a majority of peoples view; most folks see appraisals as a waste of time: they are dispiriting and foster resentment, cynicism and inherently dishonest, instead of promoting honesty and candour. Reviews are political and subjective and create a chasm in boss-employee relationships. The link between pay and performance is tenuous at best and they are in no way objective. Would two bosses give you the same review?
No, I don’t understand it either. One of the guys in my team made them. Perhaps I have two sides, one good and one evil. What is he trying to say? That I can kiss my own butt? Answers on a postcard please.
One of my favourite things about coaching multiple teams is you’re in the enviable position of watching multiple team cultures grow and change with the passage of time. These changes occur with outside influence, changes of team size and, at least here anway, with new memes that pop up on the internet.
One of the teams I coach has a team ritual. Their bot in IRC can be provoked into asking one of them to make tea, which the team member will do by filling their team-teapot with hot water, returning from the kitchen and performing the ‘Which tea shall we have gents?’ dance. This is accompanied by rounds of oohs and aaahs and finally the selection of a Fortnum and Mason loose leaf team will be dumped into the teapot.
It’s fascinating and humbling to watch these guys gel as a team. It’s often said that developers are insular, quiet, reclusive, like herding cats, blah blah blah and, while in some instances this may be true, I don’t believe it’s the norm. They form firm bonds around their passion for the code, which then spread out into their passion for other things (like tea, whiskey, or carpet putting).
Team culture is important, as I’m sure many other books and blogs will tell you, what is equally important, is allowing that culture to come into being and then nurturing it into something that, eventually, helps define that team. Make sure you do that, no matter whether you’re a coach, manager or team member, make sure you’re not impeding your teams ability to become a micro-culture within your organisations existing culture. This is doubly true for teams of developers.
I don’t know what role I might have played in helping the teams here define their own culture, if I’ve even helped at all, but I’ll certainly never try to stop them and will always encourage them along a theme and, importantly, take part in that culture – this is crucial to gaining trust. When in Rome, do as the Romans do. The great thing is, I love each of the way the teams here operate, so it’s not hard for me to get involved. Your mileage may vary, especially if their culture dictates they all play football and you hate it for example.
There’s probably a blogpost in creating a team and making them a cohesive fighting unit. But for now, it’s safe to say I’m proud of the way the teams I coach are actually teams of guys and not just individuals sitting next to each other writing code.
So, next in the series of things that are agile, I’ll be looking at Kanban. For the longest time, I had no idea what kanban was and I would bandy the word about like I knew what I was talking about. In my head, it was putting things in a Kanban board and that was it, but it’s way more than that.
It was born in Japan, coming from the Toyota Production System and comes from a desire to minimize waste (see the previous Lean post). Kan means “visual” and Ban means “card”, “board” or “note”.
Imagine, if you will, a car production line. Any car will do, but, as we’re talking about Toyota, let’s talk about an Aygo (I think they’re ugly, but you can park them under the stairs and you don’t pay congestion charge so, whatever). Your job, on the production line, as you’ve yet to be replaced with a Cyberdyne systems robotic arm, is to put the bonnet on these cars. So, a car rolls onto the platform in front of you and you pick up a bonnet from your pile of ten, pick up a screwdriver and fit the bonnet. Well done you.
The next car rolls up and you do the same, then another, and another until you’ve fitted five bonnets. The 6th car rolls onto the line in front of you and you turn to pick up a bonnet and notice a card on the top of the your 6th bonnet. It says “Order 10 more bonnets now.” and a bonnet id number. So, thankful for a break, you pickup your card, go to the guy who makes bits of cars and hand him the card. He’s just got back from delivering windows to someone and he says thanks and begins making bonnets.
The important thing to notice here, is that he hasn’t got any bonnets for you and the last thing he was doing was making and delivering windows for someone else. He isn’t making bonnets yet, because you don’t need them yet. He hasn’t got any “in stock” because you don’t know you need them yet.
Off you toddle, back to your car and carry on fitting the sixth bonnet. The moment you’ve fitted your 10th bonnet, a trolley arrives, pushed by the guy who makes bits of cars and on it is 10 bonnets. While you’re waiting for the next car to roll onto the line in front on you, he stacks the next 10 bonnets where the previous 10 were, slips a new card in between the 5th and 6th bonnets and goes back to his cage to await the card from the next person needing bonnets (or doors, or windows).
In a nutshell, this is Kanban. When you need something, you go to the next step in your process, ask for it and someone gives it to you. You put a “kanban” in their box and they deliver what is required. It’s a pretty simplistic description of it, but that’s what it is. At any one time, there are no more than 15 bonnets in existence. This is the maximum amount of bonnets ever needed at one time and, because there aren’t bonnets hanging around, waste is reduced. What we’re doing here is limiting the amount of work in progress. This is lean; why would we need more than we can actually use?
In software development, the Kanban “visual board” is just that, it’s a board you put somewhere with your story cards on it. Because software development doesn’t generally involve bonnets or doors (but it does involve Windows *shudder*), we don’t need to have cards placed between things to be found by our workers. Instead, we put eveything on our board. How your board looks is going to be up to you. Afterall, you’re the owners of your process, right?
When constructing your board, make sure you put a column for each different state, or step that your stories have to go through. Bare in mind that you’ll need a column for the status of the story; from conception through to done. For now, we’ll ignore the idea of ScrumBan, so no tasks, or sprint backlog. I’ll come back to ScrumBan in another post.
So, you’d have a column for your goals. I’d like to coach teams to work to a three month release window. The goals you’ve set for that three month period, should be in the first column. This is for information and just limits “thrash” (as used by Arlo Belshee).
The next column might be a new column. Like our bonnet guy, you might want to limit this to 10. Your mileage may vary though and you’ll want to try out different numbers seeing how you go. From the new column, your story might go into a requirements, or honing phase. You should apply a Work In Progress limit (WIP Limit) here too. To start with, try half the size of your New column WIP, so, in this case, five. This column is where your product owner would clarify what the stories mean and write the acceptance criteria. Perhaps do mockups, or at least write a document describing the interface or requirements.
Next up would be a “Development” column, the WIP here could be three, again it will depend on the size of your team(s). After that, maybe you’ll have a review, test and done columns, each with their own WIPs. The point here is that your board is unique to your process. Kanban isn’t a process, Kanban helps you highlight your process to reduce waste and spot bottlenecks. The great thing is you can introduce Kanban and it doesn’t threaten anyone or anything. You still do the same thing as you were doing before, process wise, it just forces you to have a visual representation of your process, and this is where it helps you cut out the chaff. Run your Kanban board for a while and take note of what happens. Soon your bottlenecks will be totally visible, if you’ve always got three stories in your “Test” column and the developers can’t move onto the next story because they can’t go over the “Test” WIP limit, then you know the bottleneck is with the testing.
If the board looks like it’s running well, but something is still a bit off, then perhaps be a bit more granular with your columns, can you split the “Requirements” into gathering and documenting? Or can you split the “Test” column into “automated” and “regression” columns?
Soon you’ll see where your bottlenecks are and you can fine tune your process to reduce waste. Record your progress now and after you’ve fine-tuned to see whether your changes were successful. Agree with your teams and the powers that be you’re not going to make huge, sweeping changes overnight. Help them understand that, now you can see the process, you can make gradual, incremental, evolutionary changes that means everyone keeps their jobs, but the process get’s better and creates less waste.
According to Wikipedia, this stuff can be broken down into four core components, I agree with the breakdown, but I’ve provided my own examples:
– Visualise the workflow (but it on a board!);- Limit Work In Progress (stop doing so much, only start when you’ve finished and don’t have waste lying around gathering dust);- Mange Flow (Make sure you’re recording your changes and the impact they are making so you can prove whether your changes worked);- Make Process Policies Explicit (Stick to the process on the board. Anything you do that isn’t written done but done “because that’s how you do it” should be written down and shared, some people will go “Oh, THIS is how we do this? Great!”);- Improve Collaboratively (Improve, yes. Do it with your teams, yes. Then read some sciency books about the Theory of Constrant or the Lean Economic Model … or don’t, your process won’t suffer!).
Remember, Kanban isn’t a process and doesn’t use timeboxes, it’s about visualising a process and using that new information to reduce any waste your process has.
I had an email from our communications department today, it was a forward of an article called “Six ways to bring Agile Innovation into your company,”written by Neil Perkin. It’s a pretty good article, although it only touches on the core principles of agile. Off the back of that, I was asked by my company if I would submit to an interview. Always happy to talk about myself, I agreed! You can link to the original here, or view it below:
Continual development of our technology products is central to the success of our proposition. As well as a 25 person-strong development team (and counting!), Affiliate Window and buy.at have invested in supporting resources to ensure that all of our technical departments are as efficient, productive and accountable as possible.
Investing in people and infrastructure matters, but so does establishing the right approach and attitude. We are aware that agile methodology is playing a huge role in this, so when we saw Neil Perkin’s recent Econsultancy article “Six ways to bring Agile Innovation into your company,” we went running to our dedicated Agile coach, Mike Pearce to find out more…
As Digital Window’s agile coach, you are the company’s advocate for agile methodology. Why do you feel it’s important to have a clear organizing system for our technical and product development work?
There’s a lot to get right in software development, from listening to our customers (not just verbally but also watching their trends and traffic on our platform to help us understand our users), to delivering valuable software to satisfy our users along with a whole lot of collaboration! With so much going on and regular changes in customer requirements, we need to maintain agility to keep pace with the changing performance marketing industry, as well as expanding on our foothold in the US and merging our legacy systems into the new Darwin platform. We, therefore need a coherent set of rules which allow us to work quickly, delivering quality and providing feedback fast. Agile offers us that (as well as other benefits).
How far do you agree with Neil Perkin’s key points in his recent article “Six ways to bring Agile Innovation into your company”?
I agree with all of them. The Agile methodology is fairly simple. The harder part, and the reason roles like mine exists, is applying the 4 core values and 12 principles of agile to the things we do every day. Traditionally, the Agile methodology is applied to software engineering projects, but increasingly I’m seeing articles like this, which extract relevant ideas from the Agile Manifesto and apply it to other areas of the business. I think it’s wonderful; if we’re all Agile, we can work in rhythm and that will make things easier and more efficient as we’re all dancing to the same song.
Do you think that Neil has prioritized the right areas? Within our own business environment, what key elements of agile innovation are most important?
Yes, although perhaps not in the right order. Our highest calling is satisfying our customer with early, regular releases of quality software (or, other soft services in other parts of the business). If we’re regularly releasing software – and regular could mean quarterly, monthly or fortnightly – then we’re getting feedback quicker and providing value sooner. After that, collaboration is very important. We’re not, for the most part, the primary users of many of our products and so we rely on those that are to help us steer the products in the direction most beneficial to these users.
I’m also in love with our feedback loop. Without this, we wouldn’t know what to build. I believe in the 80/20 rule, 80% of your users will use 20% of your product. So, this is where the value lies, in that 20%. This 20% is where we’ll get the most feedback from the most users and that feedback is driven straight back into our product team to help them make decisions on which direction the product should take.
There’s plenty of other agile elements that add up to our whole agile process, but the one I want to particularly mention is our inspect and adapt cycle. Once we finish an iteration, that is a period of development, we look back at not what we did, but how we did it and see if there are improvements we can make in our process. Toyota call this Kaizen, which simply means “improvement”, we look for weak points in our process – if we think we could test better, or analyse better, or collaborate better – and make a change for the next iteration, then ask “Did it work?” and, if so, try making something else better. We’ve all learnt one important thing (and it’s a bit cheesy): perfection is a direction, not a destination.
As a service provider as well as a technology company, in what ways do you think agile methodology can cross over between departments and benefit the company as a whole?
We’ve already started to see benefits. The features we work on now have stakeholders within the business, people with specialist knowledge of a feature, or a relationship with users who interact with the feature. These stakeholders are empowered to steer the direction of our products and it’s making a big difference. Also, our development teams work to two week iterations and the business knows that we could potentially deliver new features every two weeks (and we frequently do, our recent security improvements are testament to that!). This energises people as they can see constant change. It also means we’re getting fresh, relevant and valuable feedback which is incredibly important when planning new features, releases and changes.
One of the most interesting points that the article makes is regarding integration of customer involvement and feedback into the production process. As Digital Window continues to develop industry leading products, in what ways are we putting this point into practice?
Feedback happens on several levels in our development process and we do all we can to foster and encourage it. Firstly, there are our stakeholders, who, as I mentioned, specialise in their chosen project (eg, reporting, profiles, security, etc). They represent our users and our business. We collaborate with the stakeholders about twice a week, checking we’re on the right path and making minor course adjustments as we go.
Secondly, we’re heavily involved with our product managers day-to-day. Their vision and creativity helps set our products apart from our competitors and their feedback helps us explore new ideas with existing features.
Finally, when we launch our new features, we look forward to hearing feedback from our users. While it’s great to get good, positive feedback, it’s also very useful to get negative feedback. It helps us tweak our products in direct response to what our users like and don’t like. As I mentioned, our highest calling is early and regular deliver of valuable software. Without our users and stakeholders being involved and providing constructive criticism, it’s much harder to deliver the software our users want. Until someone can teach me to use a crystal ball effectively, I’ll rely on our feedback loop.
If you want to know more about our agile process, or gain some insights into what we’re doing in the Affiliate Window development team, then follow @AffWinTech on twitter.
Yesterday in a retrospective a pretty awesome thing happened.
The QA in the team highlighted an issue whereby he wasn’t getting the visibility he needed on the bugs he’d raised and when they were fixed. He suggested a potential solution and the rest of the team didn’t agree. They headed off, all of them, the QA included, into a discussion about how to solve the problem and came up with a possible solution involving an extra column on the Sprint Backlog. Thing is, some of the guys didn’t *quite* understand the premise and the QA guy wasn’t sold.
So, I suggested some roleplay.
As you’d expect, everyone moaned: “Bah, roleplay, what a crock!”, however, after another five minutes of inane chatter on the subject, I mentioned it again, except, this time, I leapt up and drew up some sprint tasks on post-its and stuck them on the pretend Sprint Backlog they’d made to illustrate their points and got people up to play the roles of developers, reviewers and QA. We ran a two week sprint, with four tasks, in two minutes and it worked. It proved that their idea was a little confusing and they decided to try something else.
So, if you’re stuck at an impasse about process in a retrospective, spice it up a bit with some role play and get the team acting out their sprint.