Don't break your back going agile

When I was starting my first structured agile project, everyone said it was hard. There are many burnt out folks in the business.

I look at it like one of last spring's projects. I was quite annoyed by a bush at our entrance and suddenly I was in to my knees in dirt, digging out the thing. It took me the better part of a day and I saw no end to it. I just kept digging and finding more roots. The area where is stood was kind of small so I also had big problems finding a good place to stand while working. It was raging hot for a Swedish summer. I guess some people would have just cut the roots at an appropriate depth. But that is not me.

But finally, the thing moved when I shoved it and within an hour I could drag the thing from the earth. Success! Going agile feels sometimes the same. It just get worse and worse and you're at a really dirty small area while everyone else seems to be chilling in the shade.

The risk for physical harm is probably not so great in software scrum as in rugby scrum, but isn't it interesting that the risk for cervical spine injuries are the greatest to the hooker, who should be considered the rugby scrum's scrum master? Take care of your scrum master.

Where were you?

The reason for me working on Confessions of a serial product manager was that even if there are lots of books on scrum, story writing, agile planning, etc, I didn't have a book which brought it together from a product owner point of view. But guess what; Rob Galen of RGalen Consulting Group is just finishing the book I was looking for! The book is called Becoming a great product owner. You can read a free version at their web site. Here are some details from the download page concerning rights:

I've controlled access to the document, so you can't print or copy the contents. Nor do you have my permission to distribute the material--so please honor all aspects of the copyright. However, you can view / read the document as a reference and my hope is that it provides insights and value in that free form

R Galen digs into the deeper questions and details and I can highly recommend you product owners reading his (and mine, of course) view on product ownership.

Thanks Rob for sharing your experience with us!

Agile the reward, not the method

Some people failing following a diet says 'the diet does not work'. But most of them does not mean that if you follow the diet, they still does not loose weight. What they mean is that they cannot follow the diet.

Reading James Shore's excellent blog entry on the decline and fall of agile, I get the same feeling. When teams pick stuff from an agile methodology like scrum and call themselves a scrum team and it does not work they do not say "we couldn't follow the methodology" since it's easier to say the methodology does not work.

Here is a teaser (and perhaps now you see the parallells with diets):

These teams say they're Agile, but they're just planning (and replanning) frequently. Short cycles and the ability to re-plan are the benefit that Agile gives you. It's the reward, not the method. These psuedo-Agile teams are having dessert every night and skipping their vegetables. By leaving out all the other stuff--the stuff that's really Agile--they're setting themselves up for rotten teeth, an oversized waistline, and ultimate failure. They feel good now, but it won't last.

The blog entry is really recommended to you, thinking about going agile, or thinking about dropping agile.

The ultimate team

Have you ever felt there is someone missing on your team? Well, look at this scrum team who have found the missing role in scrum

At least it was not my fault

From Good to great is a book I often recommend. It goes to the root of an organisation and discusses some basic traits which gives ground for a successful business. And one of the basic rules is the type of leader the organisation has. Collins boils it down to the guy who looks in the mirror for the reason for failures and out the window for the reason for success.

But this is of course not just true for company bosses: it's an interesting trait for all of us, as Uncle Bob points out in his interesting post on scrumdrels. So who are you going to blame next time?

Cost Value Curve

Reading about Kanban, I've stumbled on this nice article on scrum and kanban in gaming industry by Clinton Keith. I know that the gaming industry is very different from other software industries, but since the author is very good at pointing this out and stressing the specifics of his industry, it's not a problem. So, it's a very good article, which I recommend.

But I did react to this simple diagram. It states that you come to a breaking point where added costs don't add so much more value to the customer. I believe that it is somewhat true, but there is a greater challenge to the product owner than just spotting the breaking point. All costs are not created equally.

Que?

No, what I mean is that if you have a functionality X with the requirements A, B, C and D which for just simplicity reasons are as costly, they probably do not add equally value to the customer. It might be that D is what makes it all worth it - for the actual user. I've often seen projects where the thing that makes it all worth while is cut. "Now we've spent enough on X so D have to wait".

And more often than not D is not the most costly feature. More often it's the feature the less vocal user identifies but does not stress enough. And not seldom it's the stuff you hear responses like "well, they'll get used to that" or "it's a learning issue" from someone who does not understand why this is important. And it's often the stuff that when you do implement it is hardly noted since it is taken for granted. So we return to expected behaviour. D is the stuff which makes X have an expected behaviour.

So how do you work this? Well, one method used by for example Mike Cohn is that when you calculate business value you don't just calculate how much value a feature introduce, you also calculate how much it costs when it's not included. D might not bring so much business value but it costs a lot if it's not implemented. I think this is one of the best methods to give room to usability issues. For more on this subject I recommend Agile Estimating and Planning by Cohn.

A manual

Not having written a handbook or educational material for many years, starting up with a manual was hard. My final effort at my current position will be giving ground for a user manual.

But my first question was: which space does user documentation have during an agile project, for example if you're using scrum?

I believe it is important to include the people formulating the user manual in the team and the user manual should be part of the iteration increment. And the reason is this:

1. You have failed a product increment if there is no useable software delivered.
2. You have failed a product increment if the result cannot be used by the users.

And how can the users find the new stuff and how do they know how to use it without documentation. Of course you have the delivery notes but should a user collect all the delivery notes and try to find their way?

I'm currently thinking about the best form for a user manual in an agile project. One solution is of course a wiki: just add new pages and specify which version this applies to. Or something. But how does this work in an offline setting? For example, technicians in the fields. And not everyone loves reading on the screen: they like something to hold. Otherwise there wouldn't be so many books on for example Microsoft Word. As with everything else in an agile project you need to go back to the users and their user stories: which process do they want to follow when they get updated or learn about the application?

So, I'll be doing a classic Microsoft Word document with pictures and lists. And I'll continue thinking about how to deliver user manuals in agile projects.

Get yourself educated

Looking back at this project going scrum and agile, there are many mistakes done, many experiences won. But the thing that made the most importance was training and knowledge. I've read many blogs and books: for me one important lesson was not just following the advice of one guru but listening to many and choosing the right path for your organisation. Toyota states that going lean is not just following a book on Toyota and expecting everything to work. The solution has to work for that line of business, that company, culture and so on. I do not suggest just picking and choosing: it is important to have a clear strategy. And you do not get a clear strategy if you only pick small stuff without any thought.

The thing that made the greatest impact on me was attending the certified product owner class I took early this year. And now I don't mean the title and stuff, but putting it all together during two days was awesome. It made me really understand the objectives of the stuff I'd read on the blogs and books and in all the advice. Now I had the privilage of attending the class with Mike Cohn, a pragmatic and direct no-nonsence-guy with a huge experience. Also, he knows this is not about being into the cool stuff for the moment, it's about delivering the right stuff to the right price and with the right quality. He discussed not only how you arrange post its but the really important tasks, most prominently: communication (with stakeholders and team) and estimations (of cost and time).

I know there are two day classes and one day classes: for me a two day class was really good. Going home and thinking things through made room for some interesting questions day two and there was also room for all these exercises. These were interesting in two ways: they illustrated some chores in scrum and since there were 50 or so product owners present one could also see how different personalities work with that role.

New tactics with free software

Being the kind of gal who reads Seth Godin and Chris Anderson, I'm of course interested in new ways of marketing products and concepts. And having a free version of software is a well used concept, but now I've really seen it with a new twist.

Scrumy is a product for handling sprint backlogs and like most others they have a free version and a pro version. And like most others they difference their versions with functionality. But not always the way you think: the free version has something the paid for version lacks: sometimes the free version shows Fresh Prince of Bel air. Since I could never stand the annoying guy when the show first aired, I would gladly pay to not have to see him. It's a wonderful idea. And their commercial is lovely! I hope their product is nice!

There are no magic pills

If you've read Lucky Luke you've seen them: the witch doctors which sold those magic pills which were supposed to cure every problem. Being a skeptic, I know there are no such things as magic pills. Not in medicine. Not anywere. Not even software development.

In accordance to Swedish IDG, Scrum is under heavy attack. Be happy that the story is written in Swedish, for I've seldom read such a sorry story. Ivar Jacobson, one of the fathers of RUP goes to "heavy attack" on Scrum. It is good for small agile projects but not on large ones with a service oriented architecure. Well, if one of the fathers of RUP weren't of that opinion, I would find that more strange. Or?

Then the writer of the article states that Jacobson is being backed up by a master's thesis from the university of Karlstad. The writer of the master thesis states that scrum is customized in larger projects. Well, that is only true for scrum. Right.

Then the story becomes really weird. The writer states that there is no room for sprint reviews. I had to re read this a couple of times and I still do not understand what the problem was, besides companies not taking time for retrospectives or acting on the result. And I guess that is not only true for scrum.

Scrum is no magic pill and I've never heard Ken Schwaber stating that. If you have a product owner who lacks domain knowledge, who doesn't participate in daily work, if the scrum master and product owner does not communicate properly to stakeholders, if there is no product backlog, if there is no product/project vision, there is a good chance the project will fail. No one has ever said that labeling a project as using scrum automatically makes it a success. What I've heard is that software development is no walk in the park. Scrum or no scrum.

Sprint backlog items of type Bug and Work item type Bug on Scrum dashboard /Conchango work item template

As I've discussed earlier, we're using the episerver scrum dashboard and while testing today, I've found a small issue for my team

If you haven't used the dashboard, it's based on the conchango work item template and it have a number of work item types, for example product backlog item, sprint backlog item and bug.

Product backlog item: stuff on the product backlog

Sprint backlog item: tasks to be performed during the sprint

Bug: bugs or defects

When you set the sprint on a product backlog item, this becomes visible on the scrum dashboard (the column on the left side). You can do the same with a work item of type bug: it then becomes visible on the left column)

You can then click a product backlog item or a bug and select a number of tasks: one of these being create related bug. But here is the trick: this is not a work item of type Bug, this is a sprint backlog item marked as a bug. So if you use the reports over active bugs these bugs will not show up. Why? Well, if the bugs are a result of defects during production you will probably not that those show up in release notes and should not clog up the statistics: when you look at the bug reports these are bugs in production. In other words:
* If the bug never makes it to production, it will become a sprint backlog item of type bug
* If the bug is spotted as a part of delivered functionality, it should be reported as a work item of type Bug.

Hard to understand? Well, I know my way around the work item types by now so I can understand it but how can I possibly explain this to a new acceptance tester. And how should this person be able to know if it's a Bug or a Sprint Backlog item of type Bug? Another problem is that you cannot report Work items of type Bug using the Scrum dashboard: you have to use the web access or ordinarie Windows client.

And also, if you have reported a sprint backlog item of type bug during the sprint and the problem is not addressed, you must remember to create a linked work item of type Bug.

(And don't hit me, I didn't come up with this solution)

Using Area in TFS work item templates

Migrating to Conchango scrum template, I've lost the fields for epic and themes on my product backlog. You can guess how much I long for Rosario's hierarchal structure for work items. This would truly solve my problems with epics, themes and small stories.

The problem is adding fields to the template makes upgrades a hardship. So we do not want that. Concatinating the epic/theme into for example the description field is not a good option: I use epics and themes for making pivot tables in Excel and that would just not make it worth it. The reason for me using pivot tables in Excel is that I can make all kinds of analysis of for example cost per epic or theme (to calculate if the functionality was worth the price).

It is also a good thing to calculate the ration of bugs on different themes or epics to know which areas are prone to be infested. Which should make us aware of which areas should be better automatically tested when changing the stuff again.

But back to the problem with epics and themes. As from Monday, I store this in the Area field on both bugs and product backlog items. On the highest level I keep the themes and under each theme I've defined a number of epics. Since the field is hierarchal, I haven't written the epics as true epics as described by Mike Cohn but rather a few words (for example theme resource planning with the epics choose the right resource and handle sick leave.
This is not optmal, since an epic can belong to many themes, but the cost for another solution is frankly too big.

New tactic during sprint planning meeting

This Monday we held a sprint planning session and I introduced an element from my days as a computer trainer. As always, I started by giving the objectives of the sprint. This time I printed this down in big letters on a paper.

Then, during the session whenever giving a statement I finished this with the questions: "do you know why?" and the developers could themselves present an answer. By doing so, they become more involved in the objectives and mis understandings were discussed up front.

I used this technique, common to many theories for education, all the time when I worked as a computer trainer. Why I dropped this when educating our developers on the problem domain is my failing to see the pattern.

The product backlog's back side

When you participate in scrum training sessions or when you read about scrum in all those books people like to sell, the product backlog is described as a list of stuff that need to be done. Well, that's the front page of the product backlog. And one of the needs.

But you also have the backside of the product backlog - what you have accomplished. I've sometimes seen these fancy project burn downs or product burn downs and they are a part of this question: what we have done. But the question is larger than that, especially for a project where muliple versions of a software is being used.

I'm talking release notes, delivery notes and information in the line of questions as "when did we change that stuff?" and "since I'm doing some acceptance testing, what should I be testing"?

When I came back from this summer, I found that the backside of my product backlog haden't been given any love. Everyone was focusing on getting stuff done that they didn't take really good care to documenting what had been done and it's taken me almost a month getting things sorted out - which bugs had been fixed, outdated and changed behaviour?

When you form your product backlog, think about your needs for history: do you want to dig into some code to know when a feature was implemented or a behaviour changed? I'm pretty bad at reading code so I'm happy for my delivery notes. And so is our customer operations. Find your objectives for the backside of your product backlog and do so before the questions start popping up. Fixing the backside is a small task if you do it regulary, but fixing it afterwards is boring, a hazzle and takes a lot of time.

Self organizing teams?

I believe much in personal freedom and responsibilty. From kids to old people, I think it's best if everyone can do stuff the way they want them done. Then there are of course rules which states if the ways are legal or appropriated. But the concept of being responsible for how you carry out a task should be very much up to you. I think most people work better then.

So, this is self organizing teams in for example Scrum: you get an objective and you are free to meet that objective they way you feel fit, following the standards for how things in general are done. So, if the guidelines states TDD, you can carry out the tasks any way you want, given you work test driven. Just an example.

What I've found, though, is that some believe that self organizing means setting your own objectives. I've heard management people complaining that self organizing stuff means the guys just do what they want and I've heard developers complain about objectives given because they are self organizing.

So, just as in the American legal system which separates setting the rules from implementation, this must be clear to everyone:

1. The company sets the standard - which are the basic rules for how things in general are done. Going lean and using TDD is a strategic decision and it's not up to the developer or a single user to decide if that is good or not. And like with legaslation, some rules are set by the highest authority (state<-->company leaders) and some rules are set in the municipal (city<-->team), because some rules needs to be applied on the organization as whole and some rules just applies to a small unit.
   
2. The product owner sets the current objectives for the coming sprint. And this should be read as "Do this, and I don't care how you do it" and the product owner shouldn't have to add "as long as you follow the guidelines/laws/rules".
   
3. The developers should work to carry out the objectives given by the product owner. As long as the objectives set by the product owner are met and the guidelines are followed they can work lying on the floor for all I care.
   

I see this as a contract between these three groups and once the contract has been breached, hell can break loose. The developer's don't like the objectives given by the PO, so they start developing what they think is best. The product owner think he/she knows how things should be made so he/she start pestering folks. And management start changing the objectives. The scrum horror show.

Link work items or copy them?

If you're using TFS and work item tracking, you've probably seen that there is something called copy work item and something called link work item. But if you use these functions and take a closer look under the links tab, you can see that both results in a link to the original work item.

One of the differences is that copy work item copies fields which have the same name. So, if the original work item has a field called Feedback and the new work item have that field to, the value is copied. So, I've used Copy a lot of the time, to enable this nice thingy. The problem is that this causes other problems.

At my company, we use the excellent Scrum Dashboard from former Elektropost, now EPI-server. If you copy the work items, the calculations of work does not work properly. So, I'm back at using links again.

Where to draw the line and developer's day off

When developing using agile methods, user and customer feedback should be important. True? And if the feedback is important, how do you make it worth while for the user/customer?

Well, if the user/customer feels that he/she is being listened to, this could make it worth while. Or?

So, it should be a good thing if the user sits next to the developer and points at something that he/she feels should be different?

Which brings us to the important phase: where to draw the line. The line between changing the scope of the task or giving input to the task in progress.

Let me give an example:
A developer guy calls over the sales person, who is giving a big demo for a potential customer in a few days. The developer shows the new form for entering orders and the sales person gives some good input on that. But then he sees that the Order form lacks support for attachments, something he wants to show the new customer. So he says:
- But you cannot add attachments. Can't you fix that?

Should the developer comply? Well, if the attachments were covered among the features committed to during the sprint start, he can say that it should be fixed. But otherwise: no.

Why? Well, it's not up to the individual developer to change the scope for the sprint or the story. It is not up to the individual developer to say that if there is time for additional features, he should be in charge of desiding what that feature should be. Or worse: if the attachments are added and other stuff is cut: this is disasterous. The product owner prioritizes new stories and features. And give the team freedom to implement those features and stories the way they feel fit. And if the stories are faulty: this should be up to the product owner to fix.

So, what happens to our developer? Well, if he complies to the sales person's wishes, what happens those few days later when the sales guy is up for a demo? Is there a slight chance he sneaks up to the developer and asks for some help getting a demo with that included? And what happened to those tasks the developer was supposed to do and which were left blocking the rest?

Does this mean that I'm a mean product owner? Some might say yes. But I think my job isn't being nice to the people who like ducking for the rules and who makes themselves and their situation "special". I'm nice to those dependant on me in that sense that I want to be able to keep my promises that we focus on the things that are highest on the priority. It is not demoing stuff one sales person found hot while others were waiting for critical bug fixes. And it's not nice when the bugs in the not so well thought through features surfaces. Because they do surface. Been there. Done that.

Complying to user input during the sprint should be aimed at solving the problems on the sprint backlog. (The developer in my case actually did stuff especially for the sales person, stuff that we had to remove to meet the delivery objectives. Not so much code in it self, but damaging to the team commitment.)

And finally: I do give the developers a day off in each sprint: after delivery they can all choose something they want to spend time on. Yes, they do have to explain what and why so we don't get the unknown code with unexpected behaviour and hopefully we miss out on the bugs.

How big are your stories?

The answer to that question is that depends. And it depends on what you are using them for. Stories that are far in the future is written to give people an idea of which stuff will be done "sometimes, but not now". These stories can be very big since if you're not going to build it, you don't know the details. That is self explaining: why would I want to know the details about stuff we're not building? But then you could say that sales people need details to be able to know which customers to target. But that problem should probably not be addressed by the product backlog, but the business plan. If you've targeted a specific client who have a specific need: simply write down on the product backlog item to take that customer into account when you're specify the details.

When you get closer in time: you break down the story into smaller stories, which can be handled and prioritized. Divide stories after the following principle:
* They can be prioritized independently - that is - they all have their own busines value
* If they are up for building in the near future, never make them larger than 1/3 of a sprint, so you don't risk having to finish a sprint without any completed stories
* Make them possible to build independently. If they are all connected and must be built at the same time, the previous advice is of no use.
* Don't divide the stories yourself: this is what you have story writing sessions for. Because only developers know which things can built independently and only the users know what has its own business value

Estimating the product backlog items - why using a relative scale

Why do you estimate? I see two big reasons, which are connected:

• You want to build the most business value for the least resources. Therefor you need to know how big stuff is so you know if it's worth it.
• You want to know when new or improved features can be put into production. This so sales people can sell them at the right time and the users to prepare (for example education, integrations and installations need to be planned).

If I were asked how long it takes to build a house of cards I can give you an estimate I could give you one in a second. And so can most people who know what a house of cards is. But if you have a room of 30 persons, you will probably get very different answers from most of the people. Some of the differences lies in:

• Perception of what a house of cards means. It could be two cards or it could be a deck of cards.
  
• Skill in creating houses of cards. Some people are good or skilled at it. Some are not.
  
• Difference in how you measure time. Is it an empty room, no one around and you get to work by yourself? Or what. This gives huge impact on the estimate.
  
• Tools available. If you're allowed to use glue or cards appropriate for building houses of cards you would probably give an other estimate than if you were using some old weak deck.

The list goes on and on with all those little things which affects how we give estimates. So, what can you do? One solution is getting better information. You specify exactly what you want and what the pre requisives are. What is wrong with this approach: well it takes too much time and it makes changes impossible. If you make one small change, well then the estimation falls. The only way to make a good estimation using this approach is building the house and afterwords saying how much time it took.

So, what can you do? Well, what you can do is look at two rough sketches of a house of cards and then ask: which one will take the longest to build? Do you think that it takes double the time or tripple the time?

It is probably hard to say it's 1,3 times harder so you need a scale which you can discuss from. A popular scale is 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40 and 100. And of course the higher the scale, the more insecure is the estimate.

Estimating using planning poker is fun, fast and amazingly accurate. I will not take trouble trying to explain it, because the Swedish consultant firm Crisp explains it much better on their web site. There you can also buy decks of cards (even if I love the Mountain Goat Cards). What I do miss on their page is the use of a Golden List. The Golden List is an example list of estimations. You identify a story of each size. By doing so you can ask questions like "well is it really twice as big as X". The Golden List should be made up by stories which you've finished but if you're starting up you can fake a list from previous projects or simply things people can relate to. Print the Golden List on a big sheet of paper and keep it visual during the estimation session. Break when discussions are going into hours and days: keep comparing!

But hey, this only answers one of my needs: the possibility to compare size to validaing we get the most business value for the least time. How do I know when things are released?

What can you find on the product backlog? Part 1: the user story

When you know what the objective is, you can start making a list of what you need to forfill that objective. This list is called a product backlog.

So, to be able to answer the question what you can find on the product backlog, you need to know what you lack to meet your goal.

There are many ways to form a product backlog item. I like user stories. This is a good form for a great part of the product backlog. So, what is a user story? The basic is that you specify a kind of user, what he want to be able to do and if it is not self explaining: why he needs that.

To be able to specify a user story, you need to know who are your users. You can use personas or you can hold a seminar with stakeholders. The important thing is that everyone that reads the product backlog should be able to understand which kind of user you are talking about.

For us, that has resulted in an hierachy of users and user groups. We first have the basic User, who can be anyone from an end user to our developers. You can say "everyone with access to the system". If you then take that general user you can divide him into different categories, for example after skill (first time user, experienced user, user with hearing disability, expert user), client (integration, mobile client, web client, windows client), access rights (basic rights, administrative rights) or user type (helpdesk, technician, super user, operations technician, developer) or a combination of many of these traits.

Why you specify the user type is that it is made clear to everyone for whom you're building and for whom you are not building. This does not only make it more clear to the developer how UI should be formed but also how business value is calculated - if the sales division wants to target a certain group the business value of stories targeted at that group can be lifted. It is also tactical to give different groups "something of their own" from time to time to make them feel prioritized and seen in the project. It also tells the developer whom they should ask for details - if the user with poor sight is targeted, well, such a user should be able to give some input!

After you've specified user, you say want you want built: for example:
As a mobile client user, I want to be able to view a case address on a map

If it is not self evident why a mobile client user would want that you can add a specification why:
As a mobile client user, I want to be able to view a case address on a map so I can find my way to the location

That is how easy you write a story. But who writes them and how do you store them? And where do you keep the details? To be continued...