The infection is spreading

Today, while commuting, I saw a guy just in front of me reading Scrum and XP from the trenches, which I had the pleasure to read in 2008. I spotted it from the Crisp logo... does that officially make me a geek? or maybe just a nerd?

Be that as it may, I hope many more will follow the example and read it.

First Iteration in itinere

For the second time in the sprint - but the first one does not count because we merely cut funcionalities that were not needed anymore - our Burndown chart clearly express what everybody has felt in the last weeks, even if it was unsupported by facts (at least until yesterday): we will deliver.


Once more I'd like to stress the importance of such a tool: we always know what is going to happen, and we can take informed decisions.

As I said, the first big slope is a cut due to a modification of the contract; the second came after most architectural decisions had been tested and taken, just as expected. For this first iteration we choose the part of the system we knew best and that - not by chance - is the basis upon which we will build the whole system. Nevertheless, we mostly focused on architecture, even if we will deliver actual funcionality. The project follows a test driven approach and a domain driven design, and we just anticipated a little more than we needed at the time because we know we will need it within a couple of months (so the YAGNI thing does not apply here).

So the bar is green, our Hudson happily smiles and so do I; first demo next week, maybe more on this after the retrospective.

What do Scrum and Nintendo Wii have in common?

Find it out here.

Scrum for non software projects

I have written several times that I normally use Scrum for the manteinance works my house requires, never going down to the nuts and bolts of it. Starting from a discussion initiated from Terry, I finally decided to jot down something.

Sprints are necessarily timeboxed, as every iteration can only be run during weekends. My wife is the Product Owner, and I play the double role of Scrum Master and Team Member (or just team, as I'm practically the only one that gets his hands dirty...).

We have a ever growing product backlog that we (or should I say she) prioritize, extracting the sprint backlog - which is the stuff we plan to do for the weekend at hand. The product backlog includes things like installing the watering system for the garden, hanging pictures and mirrors, cleaning the garage, and so on and so forth.

During the week I, as a SM, try to remove the impediments, e.g. we know we will be needing a wheelbarrow so I have to borrow one. On Saturday and Sunday morning we have the standup meeting (actually it is a sitting meeting, as it happens at breakfast). Then, while she keeps an eye on the kids, I switch role and start working.

Then, tipically on Monday evening, we hold a retrospective.

It works great. And if you think that Scrum is not appropriate because the domain does not implies uncertainity and frequent changes, well, you're wrong as it really does!

Scrum in Under 10 Minutes

Another nice video on Scrum, particulary focused on backlogs and burndown charts.



Though I would have liked a little more on roles, planning and reviews the video is very clear and practical.

Agile Day - Result Day

During the fifth Italian Agile Day, held last November, I missed the Retrospective for the Italian Agile Community, but I read everything about it in the following days. The community proposed a "result day" in which we would share our experiences and verify our progresses since the agile day, to check whether we're really improving or are in a "one step up and two step back" situation. Gladly accepting the invitation, these are my comments.

A small foreword is due for better to grasp what's behind the result: some of our customers belong in a very politicized niche, and (also) for this reason they say they absolutely need to know in advance exactly what they will get, when they will get it and how much it will cost. Ok, this is almost true for non political organizations too. Anyway, except for small projects, this normally forces us to rate the analysis and give a guesstimate for the software, which will be specified and formalized at the end of the analysis phase.

In the last few months I have been involved, amongst other things, in an assessment project for one of our customers: they need a software and they need it quickly, and we offered them a solution.

Our proposal has a paragraph that explains how we will build the software. It expressely says that the system will be realized in an iterative and incremental way. It says that the estimates are based on user stories (which we verified with their IT manager - our Product Owner, I daresay - who in turn has checked them with his colleagues). It says that the customer will prioritize stories. It says that the project will be divided in 30 days iterations called sprints, and that it will be monitored using a product backlog, many sprint backlogs, burndown charts and running tested features charts. Most of all, it says that the system will be validated by automated acceptance tests.

Well, this is my result: it may be small, but I am really proud of it because it might be a turning point from just being "agile inside" to spreading the agile way of thinking amongst customers and their managers.

I must admit that the fact our customers cannot afford the time requested by a traditional waterfall process made my task easier, but that does not touch me particularly; on the contrary, just the fact that everybody agreed upon the fact that the waterfall process is a longer and more expensive one and that an agile process is needed (we never mentioned it, but you've already figured out we're talking about Scrum) is more than enough...

Many other posts for the result day can be found on the Italian Agile Movement forum page on the subject.

Agile and procedural

Today I partecipated in a discussion started by Dennis Morton who asked if anyone had succesfully adopted Scrum, XP or RUP on non-OO procedural based applications. A little rephrased, these are my thoughts.

Scrum is relatively easy. Implementing Scrum could not be that easy because you have to face several impediments: one of the biggest ones is that it clashes with the existing culture, but that does not depend on the particular language you use.

As Keith and Charlie pointed out, life is easier for OO programmers, as there's plenty of relatively inexpensive tools and technologies (if not inexpensive at all) that can help them: Junit, Cobertura, JMock, EasyMock, Hudson, CruiseControl, Eclipse, NetBeans, and so on and so forth in a sparse order, just to talk about Java.

I don't know of similar tools to be used in RPGLE ("inexpensive" and "IBM" cannot share the same sentence) but that might just be my ignorance, so it is up to the team to find a suitable solution (that could also be an expensive but affordable tool).

Anyway, I have to point out that Scrum is just (?) a very good set of techniques for project management, but it is not enough, as you must have in place the proper engineering practices to benefit from the advantages that Scrum offers.

It is useless to give a product owner the possibility to steer the project at every sprint planning meeting if a simple change requires tons of programming hours, as she always has to weight benefits against cost. You can be agile because you have test harnesses supporting your changes. You can be agile because you continuously refactor. You can be agile because all the team members own all the code. You can NOT be agile just because you use Scrum, as you're just exposing problems - problems that most of the times existed well before Scrum was implemented, so don't shoot the messenger. You also have to master the tools to resolve problems. And the first and most important tool is people, so I'm completely with Keith and Charlie who put them in the heart of the process.

We have to undergo a similar challenge as we'll embark on a very big project next year, almost completely based on IBM technologies. As we're starting from about 650 pages of detailed requirements, aged about one year, a remote customer, a distributed team with several new members (not to mention the rest), we'll surely have to cope with changing requirements (no, not the band in which Craig Larman plays in his free time) and lots of other variables and issues.

It is likely we'll have some answers within the next few months; up to now, as it is well understood that we'll have an application layer exposing services, the only thing that I could think of is the use JMeter as an acceptance testing tool. As always, inspect and adapt, rinse and repeat :-)

We're open to suggestions!

Single Choppable Neck

That's a good definition of the Product Owner... and as an add-on to last post, he's the one that gets the blame when he takes bad decisions. This time the product owner choose to prioritize a quick deliver instead of focusing on requirements, and this was not a happy choice. Luckily, his head has not been chopped and it is not going to be, but surely this taught him something.

Unluckily, the Product Owner is also the one who gets the blame when decisions were good but the outcome wasn't. Moreover, we have to remember that a bad decision is better than no decisions at all, as bad decisions can (almost) always be reversed, and that we firmly believe that everyone is always doing (trying to do) his best.

So what's the point in being a Product Owner? well, it is true that you have to carry the burden of insuccess, but you also are the shining star in case of success. Nevertheless, it is quite difficult to find someone who is willing to play this role when you're transitioning to Scrum, because of that axe always lurking above. Even more difficult when the Product Owner is an external customer.

The only way we have to persuade people is to educate them, showing that we are not looking for a single neck to chop, but we're looking for someone that could help us to reach a truly win-win situation.

Scrum Mind Maps

These are the mind maps we produced during our Scrum Master Certification Course (thanks to Pietro for posting the original photos).






They have been drawn iteratively, i.e. after our initial draft we started circulating between tables and inspecting the work of other groups. They are a very clean example of how a small set of simple techniques like Scrum can be perceived and represented in very different ways.

Scrum vs Lean?

Following this discussion I posted my thoughts on the subject. Even if I have just become a CSM, I have to agree about the importance of the certification itself; as our instructor Joseph Pelrine said, "I can only certify that we breathed the same air for a couple of days". This feeling seems to be shared by most hirers in the market. Nevertheless, I learned a lot in those two days, and I also had the opportunity to meet many skilled guys who share my very same interests.

That said, Scrum is about addressing the chaos you tipically get in a complex and fast changing environment, not about developing software: e.g. I always use it with my wife whenever we have to “refactor” our garden (ok, that’s not too complex an environment, but I’m sure you get the point). If you’re looking for practices to improve the quality of software, you’re looking in the wrong place. One word of caution: Scrum really fosters software quality improvement, but it does not provoke it. People improve software quality.

Scrum is not bad because you see many bad Scrum implementations; I’m sure you can find bad implementations of almost everything (OO is not bad because many programmers disguise their procedural code - which is not bad per se, but the mix of the two is often weird). I want to stress that a Scrum Master does not tell the team what to do, as he is not the leader; he is a servant to the team: sort of an istance of the “sacrifice one person” strategy by Cockburn, except maybe for the fact that in the latter you normally assign the sacrificed person a particular task.

I also agree with the fact that a team needs good leadership thus a good leader, even If I'm aware that many will not agree with that. I also think that the leader should emerge naturally in the team, and should not be superimposed. A team without a good leadership (I'm talking about an "internal" one) could easily end up out of action, especially an inexperienced one.

Scrum and XP from the Trenches

My friend Manuela suggested me "Scrum and XP from the Trenches", an introductory war story on Scrum written by Henrik Kniberg which I found very interesting.

I particularly liked the idea of a separate place for unplanned items on the whiteboard, as we normally pin them with the others, depending on the feature they address: even if the team knows why it's taking so long to get things done, the management always seems to not to. A huge cluster of unplanned items is a clear signal nobody can ignore :-)

This is another (working) example of the old bit "the simplest thing that could possibily work"... way to go whiteboard warriors!

Henrik and InfoQ provide a courtesy copy of the white paper here (you have to login first).

Scrum by the book

Talking about Scrum I got an objection which sounded more or less "you speak just like a Scrum book, don't you have more practical insights?".

That gave me something to think about. Scrum is really simple: the customer provides a "single choppable neck", called the product owner, who is responsible for the project and decides what he wants (on behalf of the company, of course), the team produces it, the scrum master makes sure everything goes smoothly. They periodically meet and review what has been done and plan for the next iteration. (If you aren't satisfied with this, and if you don't know Scrum you should, go get this book).

So... what's wrong when I say the customer should be involved? Or that communication should be the basis of every project? or that you have to let the team do their estimates? or that management has to trust the team without telling them exactly what to do (or better, without telling them how to fulfil the customer's needs)? I really don't get it.

Sometimes you sound like a book because if you talk your talk AND walk your walk AND hit your target... well you have no reasons to not to. You studied it, you tried it yourself, you got a piece of the action. That's it. You have to know and follow the rules before you can break them, or else you would miss the consequences. I normally pick XP as an example, where people think they can easily remove some practices: you can be quicker avoiding documentation, but this is compensated by having a customer on site (this is now called whole team). Forget that and you're doomed.

Maybe it's just hard to accept that someone else succeeded in something in which you failed (and if someone asks about the problems you'd get combining Scrum and XP this could be true). Or maybe it's just a provocation. As (our) actions speak louder than words I simply took it as a compliment - even if I'm sure it wasn't.

Face-to-face communication vs Documentation

Recently I partecipated in a discussion on the topic above; here are my thoughts.

Documentation has a big flaw: it gets out of date. And it has a cost. And is subject to interpretation, anyway. Face to face communication is a very good option, provided that you have access to the right people when you need them, as what is unclear can always be further discussed. There are many techniques that help, as active listening and many others.

But the real trick that avoids information loss (at least it minimizes the risks) is the continuous feedback that the team gets by the customer, typical in agile methods. In Scrum, e.g., at the end of each sprint (normally 30 days) the team holds a demo in which a working product is shown to the product owner (a "power proxy" for the customer), and that's where eventual misunderstandings pop up.

Another technique is having the customer write his own acceptance tests, using frameworks like FitNesse. That's also a very good documentation at system level, because tests describe exactly how the customer expects the system to behave. At code level, i.e. for developers, automated tests are the best documentation you can get, as they exactly describe how different pieces of software behave.

What level of documentation can be expected? it depends, and it's not only about how agile your process is. If defects in software could cause loss of lives you'll probably have a higher process ceremony, which means more and more detailed documentation, if software defects could only cause loss of comfort or discretionary money it's a whole different story.

A new Certified Scrum Master

After a very intensive and interesting course held by Joseph Pelrine, whom I recommend to everybody interested in Scrum, I am now, lo and behold, a Certified Scrum Master (trumpets playing, cheering and applause). That's not so strange, as I have been very involved in scrum(s) for almost 15 years, as a forward player and as a scrum half... even if that might not count!

By the way, I was shocked by a revelation: the scrum half is not the scrum master, as the name might imply... he is the product owner!

Ken Schwaber explains Scrum

Ever wondered what this Scrum method everybody seems to be talking about is? Well you happen to be lucky, as I run by chance into this conference in which Ken Schwaber, who co-developed this agile process with Jeff Sutherland, introduces it during the Google Tech Days in 2006.



As a former rugby player (thus a sort of a scrum master), my favourite line is in the introduction, where he says Scrum is an event in the game of rugby where people get together and politely discuss ownership of a ball. It might sound fun and weird, but... that's exactly how it happens!

Anyway, one of the best things I've heard is that, even if Scrum takes a lot of ideas from a particular project in which only the best of the best people were involved, Scrum perfectly works with idiots, and that makes everybody a candidate: there are no excuses! Scrum can be used by everyone, and not only for software project. Last weekend my wife was reading me an endless list of things I should have done in the next couple of days and I told her: "Hey! You'd better prioritize it, because there's no way I could possibily get all this stuff done by Sunday evening!". We had a backlog, we had a timeboxed iteration. She acted as a product owner, choosing what I should do; she acted as a scrum master, checking my progresses and shielding me from my kids who wanted to play outside in the garden in which I was tearing the soil; I acted as a team, as the picture shows. We had a Scrum project!

Another very interesting thing is about the transparency of the project: everyone knows where the team is at all times. This can be frightening, because somebody in the upper management can realize they choose a very bad way to spend their money (actually the money of the company) after just a copule of months of a three year project. But this transparency can give you all the informations you need to take the most beneficial decisions for the whole organization. And this happens iteration after iteration!

Last but not least, a note on quality. Sustainable pace is not only advocated in XP, it should be an unbreakable rule. Studies show that increasing work up to 12-14 hours a day can lead to increase defects rate by 60%, and a good team should say no to dropping quality, because it can only bring pain and suffering in the long run.