Tuesday, December 11, 2007

Manifesto for Fragile Software Development

Some of my scrum team members came up with nice anti-agile manifesto that I at least found really hilarious. Especially as it highlights some of the things that are present in process-oriented organizations.

Manifesto for Fragile Software Development

We are uncovering worse ways of developing
software by writing about it and telling others about it.
Through this work we have come to value:

Messed-up processes and enterprise tools over people
Unfrozen and unfinished specs over working software
Hopelessness over happiness
Following an undetermined plan over responding to change

That is, while there is no value in the items on
the right, we only value the items on the left.



TODO: we need some signatures

Tuesday, December 4, 2007

Excellent takeaways from Agile Architecture training

Agile Architecture course given by James O. Coplien was really interesting. Here's summary about my learning experience:

  • Model-View-Controller pattern should be described as Model-View-Controller-User as the user is vital for communicating the pattern to others.
  • TDD can ruin your architecture, Coplien has written an thought provoking article about that.
  • Architecture is about "What the system is" and "What the system does". Extreme agilists usually concentrate only on the latter.
  • Object-Oriented Programming is rather about Roles than Classes. Jim has written nice blog about that as well.

I have been following the TDD dicussion taking place on various blogs and now it is getting really interesting. I have actually started doing an experience report for XP2008 about my personal findings in my current Scrum team with help of my good friend Ari Tanninen.

Thursday, November 22, 2007

Going to attend yet another Agile seminar, arranged by EGET

Going to participate an event organized by EGET.

Kind of waiting for it as the speakers include Jeff Sutherland and Henrik Kniberg both somewhat pioneers in Scrum.

Wednesday, November 14, 2007

Common Scrum Pitfalls - Killing your Scrum with a bad Definition of Done

When I educate teams or even organizations to apply scrum I often hear the question about "What should we include to our definition of done?". In some cases the PO (Product Owner) has set the definition of done (not the team, ouch).. Anyway, since this seems to be very common problem I wanted to address it here.

One common mistake is to introduce something that I call Coverage Killer. In some organizations Test Driven Development has been misunderstood as "creating a lot of tests to get good coverage" - this is wrong due to the fact that "you get what you measure". Imagine that some organizations have gone so far that they started to remove code to get better test coverage percent... duh. Well, you get what you measure ;) This is just part of the problem; when you (or your customer, Product Owner...) set something like "the minimum test coverage is 85%" you are about to introduce an overkill. Your development team will be writing tests just sake of coverage (not for ensuring that your business functionality works, which is far more important than coverage, eh).

Usually the team does not put Coverage Killer into their definition of done so to take care of this issue let your team define it's definition of done. Simple.

Another common mistake is to leave out refactoring from your definition of done. In practice I've seen several teams having "refactor "-tasks or stories in next sprint or even "stabilization" sprints. That demonstrates the fact that team is not committing quality code during the sprint and you could not "release" after every sprint (which should be the case if you play Scrum by the book). Even more scary would be a team not refactoring at all..

So how far you can go with your definition of done? I will get back to this so stay tuned :)

Wednesday, October 31, 2007

Training - Agile Architecture

I am going to participate Agile Architecture training. If you will be there, please don't hesitate to poke me ;)

If you cannot participate, but you are interested, stay tuned as the follow up will be posted to this blog.

Tuesday, October 30, 2007

Common Scrum Pitfalls - Weak Product Owner

Few days back I was giving "Applied Scrum"-training to Finnish consultancy company and later on I shared my views on one gaming company that I am working for besides Huitale. One the discussions with the gaming company's teams concluded that the challenge in taking the scrum into use is not the team nor even the ScrumMaster but actually Product Owner (PO); missing Product Ownership to be exact.

I started think about it more, and I figured that in old days (tm) stakeholders (anyone with money and power) had plenty of time to make their decision regarding the project at hand. After some analysis there was moment to say "go" or "no go" and then you just followed the Gant charts that never reflected the reality or were updated every 3 months or so. You had plenty of time to react and gather enough intel for making so called "good decision".



Think about scrum-world; if you are PO, you should first of all be available all the time and secondly be able to answer any business / product functionality related question almost on-the-spot. If you don't know the answer, the team will be impeded and won't work until you have it. You are ultimately in charge, responsible and you "ought to know". This creates huge pressure on PO and according to my experience most of the POs cannot handle it. Why?

PO may not actually be correct PO; he may not have big enough stake (he is just a random manager that got the job and actually is more busy with something more important), he might not have the "money" involved (so why should he care that much), he might not know what it means to be PO ("why these guys are bugging me all the time, just do your job, I trust you, you are smart guys...") and so on.


Let me give you one "bad example" based on real life.

Mr Old Requirement Engineer (lets call him Jack) was called to be Product Owner for a product that he was working with previously. In the past Jack had collect customer's wishes, made Requirements Specification document out of those wishes and then discussed with the customer about the requirements. Jack did not know anything about scrum but Product Owner sounded nice title (yes, title, not role) so he took it.

Let me emphasize that Jack is your average "Junior Developer" who never got to develop anything ("You better get some experience first, so we put you just with the customer talking about the software you may some day start develop with the senior developers"). He is a bit introvert, silent, shy but still jolly guy, who likes everybody and wishes that everybody likes him.

Once Jack meets the team he starts seeing that PO-role is something really serious in this "scrum"-thing. Well, he has already taken the title (& role) and he does not like to go to tell his boss that he is not up to the job (Mr Boss is one of those good old Mr Strong Project Managers); so instead of making the issue visible he just continues and hopes that everything goes smoothly. Team still likes him cause they go out every now and then and he still is a jolly fellow.

So the team is established, protected by fresh ScrumMaster (lets call him Sam) (no earlier experience, but has his certification) and Jack acting as PO. Since one of the team members (call him Fred) has some idea about scrum methodology he starts to create Product Backlog for the product for Jack as reference that then Jack should start filling up with real items. However, as Jack is busy guy and Sam is pushed by the boss to start the "new scrum" the teams starts working straight away without prioritized and estimated backlog (ouch).

I (as outsider) tell Fred that he cannot do the backlog, it is not his responsibility and he cannot take the responsibility away from Jack. I tell Fred to contact Sam (ScrumMaster) to tell that they cannot continue until the backlog is sorted out. Fred does it and Sam understands. However, Sam feels that they should not push Jack too much so he tells the team to continue.

Jack is busy guy, he has other projects (old requirement engineer hat) and he does not understand why he should be that interested about Sam & Fred or their project. He starts gathering some backlog, but he feels uncertain since the initial backlog (created by Fred) is so technical that he cannot really do anything about it. He is also feeling a bit guilty and he is afraid of Fred as Fred seems to understand these scrum concepts and all that.

After 2-3 sprints (team has done the items that were put into the backlog by Fred) there is Sprint Planning where Jack should present his backlog items (stories) to the team. In the meeting Jack is really afraid as the team starts asking all these questions "What do you mean by transaction history? What are the visible elements in this history? can it be sorted list? ..". He has no answers as he has not gone trough these with the real customer. He is feeling like a proxy without giving any value. Anyway, he has to shield himself so he asks the team if he can come back later with the answers and the team would just start off. Team declines as they cannot estimate nor understand and therefore not commit. Sam as the ScrumMaster calls the meeting off and says to Jack that the team is not working at all before Jack has the answers. Jack is nervous and confused; why he is pushed around, he is not the customer!?

Boss comes few days later to visit the team and Sam tells him that they are just hanging around, waiting for Jack to finish the backlog. Boss gets furious! "What the heck you guys are up to??!", Sam responds that they cannot commit to anything as everything is so vague. Boss asks what's the problem, as we are all smart guys and we can work things out.. Sam explains the problem of responsibility, the team cannot be responsible of defining what the customer wants; that would just lead to other problems.

Boss goes to Jack who is already wrecked. Jack promises that he will do the backlog so that the company can have some visibility (burndowns). He is still afraid to tell the boss that he cannot do this job, he is the wrong guy to do the ownership...

The story continues due to the fact that this is a real story. Lets see how it ends. :)

Anyway, I think that this demonstrates quite nicely the problem of product ownership and how companies misunderstand it. Imagine if the ScrumMaster would have let the team do the calls; end product would contains tons of features that are not used nor understood by the customer (sounds familiar eh? 45+% features implemented that are never used, Toyota calls this waste).

Till next time..