• Added a ‘simple’ view to the site, this means you get to see everything in an easier fashion for editing etc. There’s still edit-in-place, it’s just easier than scrolling through the cards. You can still use the ‘card’ view, which you’ll need if you want to print the cards.
• Tidied up some style issues with the card view, so it’s a bit neater now.
• Added a newsletter signup, so you can be kept up to date with the things I’ve added.
• A few bugs fixed.

Check it out at http://storyprinter.mikepearce.net/ and please let me know if there are any new features you’d like to see.

Feedback comes from these - image by mpeterke

Part of my new role is to review and appraise the team. Given that there are a lot of them and I can’t spend enough time with each of them (and nor would I want to) to be able to do a good review, I figured that I’d have them do 360 reviews. There are multiple ways to do this, which I outline below, but I didn’t pick one for my team, I let them vote (I also let them post any new review methods they knew of in order they could vote for those too) – can you guess which they voted for?

Traditional

The traditional approach is an anonymous review: I pick several people to review the employee, they craft and submit reviews and then I deliver this feedback to the reviewee.

This sucks on multiple levels:

• Suppose the reviewee disagrees with some of the feedback, how can they offer a rebuttal? To me? How does that help?
• What happens if they don’t understand the context of the feedback?
• What happens if, in the name of keeping the feedback anonymous, I remix the feedback and lose the actual message (but I don’t know I’ve done that)?
• We work in tight scrum teams, this means that the BEST people to offer feedback, are the other people on the team (also the product owner and potentially stakeholders, but we’ll come to that), this means that, after the review, the employee goes back to their desk, possibly seething or feeling dejected, put upon or just miserable because of the above but they KNOW that someone in their team gave them shitty feedback.
• Sucks, right?

So, another option is to have the reviewee choose the people they want to review them. No. This also sucks:

• They might pick people who don’t really have much to do with the and would offer a good, although bland, feedback.
• Again, they have no chance of rebuttal or dialogue there and then to discuss context of the feedback unless …
• …they go back to their desk knowing that one of their team gave them shitty feedback and now aren’t sure how to broach the subject.

This doesn’t suck because:

• Same as the above.

Team 360

The whole team goes to the pub (or cafe, whatever) and they take it turns to offer feedback on each other. Starting with me as a warmup so they don’t feel shy when it’s there turn (this is great for me, I’ll get LOADS of feedback). You go round the table one at a time and everyone on the team feeds back to me – positive and negative – and write it all down. Then someone else volunteers and so on until everyone has had a go.

Developers drinking...

You need trust in the team for this and a good bond. This isn’t going to work with a new (or a ‘forming’) team and I’d advise something different (not the above, maybe just one-to-one coaching until the team are up to cruising altitude). But for established teams, or those stuck in a retrospective rut, I think this is a great idea.

I’ve run one trial of this method before putting it out to vote and the team had some positive feedback on the process (and each other!). It’s tough to do, but giving and receiving feedback is always tough, and the idea of doing it face-to-face with people you work with every day is challenging, but you should do it. Nut up and prove to your peers that you’re a grown up and can and need to learn something about yourself that you didn’t know before. This is about improving yourself in ways you didn’t know you could improve and making sure you’re not annoying your team.

This idea isn’t new, although I wish I’d thought of it, I originally read it in Management 3.0 by Jurgen Appello (the book is good, as are his talks, but his slides suck – well, he does draw them with MS Paint…)

What about … ?

Well, I mentioned product owners and stakeholders above. I’m undecided yet (but, I’ll probably let the team decide) on whether to include product owners in a team 360. They do spend a lot of time with the time and can probably offer some good feedback – it does depend on the relationship with the PO. Even though we don’t foster the feeling (and, Affiliate Window isn’t alone in this I’m sure) there’s a little ‘them’ and ‘us’ between the developers and the product team – but maybe this is a good start in breaking down that status quo.

Also, for stakeholders, having those in the team 360 would be pointless – they don’t have day-to-day dealings with the team, mostly it’s just input and output with the odd nudge in between, but we need their input. This is what the release retrospective is for but I’ll cover that in another post!

Edit: Stupid WordPress Y U NO EMbED GOOGLE DOC?

To see it, please go here: http://bit.ly/zs3ptD

This is not my cake - image by notanyron

My loyal readers. I’m very, very sorry. I’ve totally neglected you of late (it’s been a month since my last post). A lot has happened in this time. Not including Christmas and New Year, some things have changed which have taken up large chunks of my time: I’m no longer an agile coach, I’ve been promoted to a Head of Development.

This is a great move for me, I’m doing much the same role, but I have bigger teeth and can affect greater positive change for the people in my teams. I already have good relationships with the people in my department and I spent my days coaching and teaching and nudging the guys into improving one way or another. Now, however, I have the ability to do it officially and sanction their individual and team growth in ways I couldn’t before (mostly because I don’t have to ask before I spend money… )

I want them to tell me how this department should function and I’ll make it happen. Already we’re pushing each other to create and achieve short-term goals for improvement and, while the rest of the company is having an appraisal and Personal Development Plan rolled upon them, I’m letting my team decide how they would like to be appraised themselves.

It’s an exciting time and I’m hoping that, with the department in charge of it’s own destiny, we can create some exceptional software, improve and grow quickly as both teams and individuals and, above all, delight our clients.

What does this mean for the blog? Nothing much, I still intend to blog about agile and frameworks, but you’ll probably see more management stuff, training, goals that kind of thing as it becomes more a part of my role. We’re also looking for a scrum master to head up a couple of the teams, so, if you’re looking for a permanent position as a new scrum master, then let me know. I’m looking for someone with a little experience, but who needs more and wants to learn.

ticktickticktickBING - An Old Timer by hiro008 on Flickr

Estimating a backlog should be easy, especially if your Product Owner has looked after it, knows how to write good stories that mean something to the developers and the business and is able to prioritize based on business value (or, customer delight!). However, estimation meetings, poker planning, planning two or whatever you call it, can often be painful events that descend into chaos, anarchy and heated debate. While these things are all fun, estimation should be fast and simple, afterall applying arbitrary numbers, whose only measure is relatively sized, to amorphous items of work can’t be rocket science, so why would you want to spend much time on it?

Trouble is, developers and engineers are paid to solve problems, that’s what they love to do, so they begin the moment the problem is presented! This is to be applauded, but doesn’t really nail what should be fast conversations about stories!

We’ve recently been coarse estimating the next releases’ worth of stories for each if our products, the backlogs for these products contain between eight and 38 stories, depending on the goal. When we started estimating these, it was clear that it was going to be painful, so I created ‘The Rules’ (to be clear, they’re guidelines, remember the Shu Ha Ri!):

1. Reset the countdown timer to five minutes.
2. Product Owner reads story and acceptance criteria.
3. Team ask questions to clarify their understanding of the feature. No technical discussion.
4. When no more questions, the team estimates.
5. If estimates converge or there is consensus, GOTO 1 and start a new story.
6. If no consensus, start more discussion. Technical discussion is OK here.
7. When the conversation dries up, or the time ends, whichever is first, the team estimates again.
8. If estimates converge or there is consensus, GOTO 1 and start a new story.
9. If a consensus isn’t reached, reset the time for another five minutes.
10. When the conversation dries up, or the time ends, whichever is first, the team estimates again.
11. If a consensus still hasn’t been reached after 10 minutes, put a question mark next to the story and GOTO 1 and start a new story.
12. Optionally: create a spike story to discover more information in order to estimate the difficult story.

Where I am right now, we manage our product backlogs using Google Docs. This works for us as it allows for flexibility when prioritising, we can move from room to room and, means we don’t have a large, messy surface of stories (although, I’m convinced this would help us – watch this space). One thing we do suffer from, is the transition of these stories stored digitally, to stories stored on a sprint backlog physically. Writing the stories by hand does mean there are sometimes further conversations around the stories, which is no bad thing, but it also means that often detail is missed from the cards, which causes problems later. This is due to the stories being written in a shortened form and, unfortunately often, a complete lack of acceptance criteria.

So, because of this, I put on my developers hat and created the Story Printer. This is a simple web-app, which allows you to upload a .CSV file and have it turned into printable story cards. At the moment, it’s very simple, but I’ve a few extra things on the roadmap which will add more useful features. But, for now, it does what it says on the tin.

Using the Story Printer, we now have a sprint backlog, with story cards that are identical to the stories in the backlog. Time will tell whether this prototype will prove useful.

Feel free to use it yourself and please contact me with new features, bugs or other stuff. I’d love to know if you use it, or would find it useful with additional features.

The Story Printer

Horses, going slowly. Photo by The Library of Congress - http://flic.kr/p/a88fYb

Henry Ford is quoted as saying “If I’d asked my customers what they wanted, they would have asked for a faster horse!”. While this might be true, this is a short sighted view of product management.

Often, our customers will ask us for something they want, but they’ll frame it in the context of something they already have. This seems to them to be the right thing to do. It’s helping us out as the people who build their products, right? Kind of. If we were to take the view that customers always know what they want, then I suppose so. However, our customers will endeavour to give us a solution to the problem they have, instead of being clear about their problem and letting the problem solvers have at it instead.

If your customer says “I want to be able to send an email to all my users informing them of X,Y and Z.”, You’d think they what they wanted to do was send an email to customers about X, Y and Z. But is that what they really want?

If you probe a little deeper, by asking open questions, you might find a different answer:

“What is X, Y and Z?”, you ask.
“Well, it’s the new promotions we offer, we want to tell our users about them as they might not find them in the promotion list.” Replies your customer.
“How does the promotion list currently show them?” you probe.
“It’s ordered with the newest on top, but if our customers aren’t looking for promotions, they might miss them.”
“So, you need a way of highlighting your newest promotions?”
“Yeah, I guess so. But we’d like to be able to send them emails about other things as well, like changes to our terms, or new features.”
“OK, so am I right in saying you need some way of informing your customers of new features, promotions and other pertinent information?”
“Yes!”

Now you have the real problem, which turns out to have little to do with email and there are many ways to solve this kind of problem. It’s now a case of discussing these ideas further with the customer and the team in order to find the right solution … which might not be a complex email system.

So, if Henry Ford had asked his customers: “What do you want?” and they said “A faster horse!”, he might have asked, “What do you need a faster horse for?” and the answer might well have been, “Duhh! To go faster!” Which is the real requirement. One that he fulfilled quite well.

Originally published on Technorati.

Are you ready? Image by Kevin Dooley on Flickr

Development teams use the idea of a definition of done (DoD) to decide when they think a user story is ready to be shown to the stakeholder for review. The DoD is like a bouncer or doorman, ticking technical criteria off on a list before the story is allowed in to party. The DoD is a powerful tool, and while its explicit value is obvious in ensuring the quality of a user story before review, its implicit value is equally, if not more, important. The DoD forms a contract between the development team and the product owner (PO). This contract not only ensures that stories meet a baseline of quality but it also creates a bond of trust. The PO knows that, with a DoD, he can trust the team to deliver a quality technical solution, and in agile software development, trust is key to your success. The acceptance criteria form a similar bond between the PO and the stakeholder or business. The criteria are designed to help a PO decide if a story meets the stakeholder’s requirements. It’s this list—defined in conjunction with the stakeholder—that creates trust on the stakeholder’s side. They know that their PO will deliver what they need, because it says so on the story. The DoD and the acceptance criteria combine to make a powerful ally for your team’s success. But both of these things require that the user story itself is sensibly written and defined and that the acceptance criteria aren’t some magical pie-in-the-sky, moon-on-a-stick list of ridiculous demands that would give a hostage negotiator nightmares! The PO can make use of a similar DoD called the definition of ready (DoR). This can be used for all the same reasons the DoD is used for the team. It’s useful if the Scrum team helps the PO come up with a DoR, help her define things about stories that make them easy to understand:

• small enough to be manageable in a sprint
• contain enough detail to estimate accurately and
• create acceptance criteria that really help define “done.”

POs don’t just pluck an idea out of the air, write a user story, and drop it onto the backlog (we hope). Stories go through a process just like the software they drive does. The PO has a responsibility to the team to create user stories for them to estimate and, at some stage, work on, that aren’t badly defined or not thought through. Team members don’t want to have to do a bunch of the PO’s work in order for them do their own work and deliver value. To this end, a PO and the Scrum team might find the DoR useful. This is a contract that the PO has with the team in order to say “Before I put a story in front of you, I will have done everything I can do make it not suck.” Some examples of criteria on a DoR are:

• Story contains actors, problem, and value
• Story should fit in a sprint
• Story should be appropriately documented (does it require wireframes? User-journeys?)
• Value should be obvious, if not, it should be explicitly stated
• Story should have reasonable conditions of satisfaction
• Story should focus on problems, not solutions

Using the above example, we could ensure that the user story: Show users other products that they can buy before they checkout which begins life as a throwaway request from a stakeholder at an audio-visual online storecan be rewritten using the DoR as: As a customer, I would like to see products that I might like to buy at the same time as my television, hi-fi, or other product, so that I can be certain I have everything I need. Acceptance Criteria:

• Show users products that other customers, purchasing the same products as this user has chosen, have bought also
• Based on what the user has added to his basket, show him products that could potentially be used with it, e.g., if he has chosen a TV, then show him cables, TV stands, and Blu-Ray players
• Show ratings and percentage of customers who ended up adding the additional products to their basket.

This shows the actor, problem, and value for the customer. The value for the business is implicit in that it will increase uplift. The story is appropriately documented with reasonable acceptance criteria, however it doesn’t tell the developers how it should be done technically. I’m a big fan of release planning meetings. These meetings include going over the team’s DoD to see if there are any changes team members want to make in conjunction with the PO or stakeholders before they start sprinting. This is an ideal time to create your DoR as well. In addition to the explicit value you get from having a contract between the Scrum team and the PO, the DoR also goes a long way to fostering trust (as long as the PO follows through) in the same way that the DoD and the acceptance criteria do. If you have a bad sprint, during the retrospective, you can review your DoD and your DoR. Did the story require more work before it went into the sprint backlog? The DoR provides a similar yardstick to that of the DoD when looking for root causes of failure. Try adding a DoR to your process, especially if you’re having trouble with your stories being difficult to estimate or work on. You’ll reap benefits immediately, building trust and creating stories that have real value.

Jenny by jamesfischer on Flickr

Women, it is said, have a higher pain threshold than men. I saw evidence of this as I watched my wife give birth … twice. She went through something that I can’t even imagine having to endure. I’d have screamed ‘epidural!’ the moment the first contraction hit, but then I am known to be a bit of a wuss. My wife however, gritted her teeth and got on with it, I’ve never been more proud.

I’ve witnessed a similar thing with scrum teams. Some of the teams I coach have an extremely high pain threshold when it comes to dealing with impediments. It’s often been one or two days later that I’ve even heard about the impediment, let alone had a chance to deal with it. I suspect this might happen in other teams too and it’s worrisome; it may mean that the team doesn’t believe their SM will be able to remove the impediment (which would illustrate a trust issue and is the subject of another post), it might be a show of machismo to tough out the impediment themselves and resolve it without bothering anyone. This is an honourable motive, but chaps, this isn’t 12th century Japan, if you need help, you can, and should, ask for it. Understanding when you’re impeded and recognising the need to seek help is a more macho thing than flexing your muscles and baring your teeth, it also makes the ladies swoon*.

However, the most likely reason that people don’t raise the issue, is the team simply don’t see it as an impediment in the first place. In standups, or in just day-to-day team chat, the term “I’m waiting for…” crops up quite frequently, usually in reference to the design or operations team. This term is poisonous, it’s a pseudonym for “I’m impeded by…” and teams don’t recognise this is the case.

If you’re waiting for something to occur before you can do something else, you’re impeded by it and your best course of action, if you’re unable to un-impede it yourself, is to raise it to your SM (or your coach. ) and have them try and remove the block for you. Next time you catching yourself saying “I’m waiting for…” remember, you’re impeded.

Don’t tough it out, leave the high pain threshold stuff to the mothers of the world, they’re much better at it.

*Probably, I have no data for this, I made it up.

Adventure lies EVERYWHERE! Image by Daniel Voyager

We’ve been doing scrum at Affiliate Window for a couple of years now. We go through the inspect and adapt cycle regularly and we’ve made few, if any, changes to our process, only our engineering practices. Recently, however, we’ve been working on a couple of projects which have required some groundwork and lots of backend work. This kind of work doesn’t really lend itself to the ideal of having something to show the stakeholders at the end of every iteration. We still have the review, describe what we’ve done and then take a look at the backlog with the stakeholders to decide what the priorities are for the next iteration.

This has raised a question from one of the teams about moving over to kanban and it got me thinking about what organisations can do to start on an agile journey, should they start with scrum, or kanban? What about established teams? Can they transition from scrum to kanban, or vice versa? Why should they? Should they even do it?

Now, there’s no reason why you can’t continue doing scrum (which is what we’ve decided to do), even with backend heavy work. Afterall, it’s simply a framework designed to offer constraints in order to create fast feedback (amongst other benefits), but kanban is attractive in that it allows you to decide when you demo/review and so gives you the benefit of time in order to actually have something tangible to show the stakeholders. Kanban is also attractive for those coming to agile afresh. It allows you to start integrating some agile practices and get a view of your issues (in order to solve them) without changing your heirarchy or existing process.

For Kanban to really work, you need to make sure you’re setting up a pull system that describes your entire process, from inception to delivery – not just a column based todo board (which, unfortunately, you see a lot described as ‘kanban’). To be able to do kanban well and retain the holistic view of your work required by the product team to make educated guesses on delivery and suchlike, the team needs to be mature enough to do kanban well. This means; mapping out the different states in your system, working out WIP limits and, importantly, deriving cycle time (how long it takes an item on the board to get from left to right) in order to estimate delivery/scope/cost etc. Herein lies the rub (I’ve always wanted to put that in a blogpost!).

If you’re not able to use scrum to help you deliver backend-heavy, large work items, then it’s unlikely that kanban can help either. The constraints of scrum help you stay on target and be accountable for what you have or haven’t done and make tweaks and adjustments to perform better in the coming iterations. Once you’ve nailed scrum and you have a product backlog with well defined stories, which are easily estimatable, then you’re ready to mature to a really valuable, efficient and data-driven kanban implementation. Eventually, when you’re able to size your stories all the same, you can do away with estimating as your cycle time will remain constant. Allowing you to set regular reviews and inspect/adapt cycles. You’re one step closer to programmer anarchy!

So, should you start with scrum, or kanban? Kanban allows you to start your agile journey without upsetting the status quo; you don’t change any names, or add/remove roles. You simply illustrate your process on a big visible board and become accountable, as a team and a company for the work you do. You can implement any agile practise you like (standups, backlogs, user stories, etc) and see how they work for you without rocking the boat. Scrum, on the other hand, requires a reboot and an installation of a new process, one with constraints *built in*, but the benefits are numerous and valuable right off the bat.

Should you start with scrum, or kanban? The answer, I think, is ‘it depends’. If your organisation, including those at the top are comfortable with scrapping your current process and starting something new, even with it’s inevitable lead time, then go for it. Use scrum and the constraints will help you become agile. If your organisation is reticent to start, or you have buy-in from teams, but not the business, then start with kanban. It’s lightweight and non-intrusive and will still allow you to raise your impediments and issues (but solving them often requires bold and honest action, beware!).

Should teams transation from scrum to kanban? Probably, but make sure it is for the right reasons and that your team is mature enough to make the most of it, if you’re not sure, then try transitioning via scrum-ban, it’ll help you see the benefits and enable you to get better at the things which make kaban most useful, without changing more than you are comfortable with.

I’d be interested to know how others started their agile journey, or whether many transition from scrum to kanban (or the other way). Drop me a mail, tweet or leave a note in the comments!