Agile smagile! - Scrum

Lessons learnt the hard way

Petar Shomov — Fri, 02 Oct 2009 22:35:50 GMT

I just got off a large project that one of our customers is running. I will not go into details but it should suffice to say that it is a rather large multi-phase project that is supposed to create the future IT backbone for that customer. Before I move on I though I should stop and analyze what we did right, what went wrong and what can I learn from this experience. And I thought I would share it with you dear reader ;)

1. Deploy by the end of the first month to a user
In large companies there are usually many reasons why a project cannot be deployed: dependency on another project which in turn depends on another project and so on, or someone has to get legal approval for something to be released. Yes, there are many excuses not to deploy, but in the end that's all they are - excuses. The business needs to see value, your team needs to get feedback from real users about the system otherwise you are risking building something no one is interested in and/or the business people loosing their business patience. My future rule of thumb would be - if you have not deployed to actual users by the end of the first month of the project, you need to do get angry and demand this to happen right away.

2. Do not accumulate technical debt, push back on Product Owner who does not understand technical debt
Technical debt(from here on referred to as tech-debt) is hard to explain to product owners that have not programmed. This is understandable and there is no easy way around it. We tried all kinds of metaphors but I don't think we succeeded in communicating what tech-debt is and why it is important. The best approach that I can see working is to negotiate a slice of each sprint to go into paying off tech-debt and demand extra on top of that at the first sign of trouble. Letting it pile and telling yourself that it is ok, that you are going to fix it "later" does not work. Never has, not for me. "Later" the debt is usually so big and the bad stuff has usually spread all over the place and fixing it becomes an all-or-nothing mini-rewrites that are very hard to do and are rather unpleasant and unsatisfying experiences.

3. Do not allow architectural astronauts to tell you what tools to use
It is a strange phenomenon but seems quite persistent: a company becomes mid-sized and someone decides that now they need to unify "how we do things around here". And then an Architect (may be even Chief Architect) is appointed who starts googling and creating a list of tools and technologies allowed to be used. And this is the moment when you start to be told what tools to use to do your job by the guy who has never done your job or it has been a while since he has last done your job. Do not let this happen, say "no" to company politics and demand that you decide what tools to use. The list of tools should be coming from you and the rest of the guys that are working in your organization. Architects can be valuable, but this is not the way. Do not buy into tool vendors based on power point presentations and one day carefully orchestrated demos from the salesman. You and your peers should be making the standard in your company. 'nough said.

4. Manage expectations so that they are achievable
I have come to appreciate marketing as a *very* important aspect of product development. The same product may be perceived as two complete opposites depending on how its being marketed. One thing that I've found out is not wise, is to proclaim that your product will be a universal panacea that will fix all there is to fix. This might sound obvious and plain common sense, but I am mentioning it for a reason: the larger the promise you make, the more difficult is to keep it. So I would advise to do small achievable projects and build software products incrementally and iteratively. And the product owners have always to be on the lookout how to generate value with minimum effort.

Well, I am off to the new project ... ;)

The Decline and Fall of Agile

Guðlaugur Stefán Egilsson — Mon, 17 Nov 2008 23:17:42 GMT

James Shore posted an excellent blog entry titled The Decline and Fall of Agile about what he's seeing happening with many Scrum teams, provoking a myriad of responses all over the agile blogosphere.

A few of the posts:

Robert C. Martin (Uncle Bob)

InfoQ

Jeremy Miller:

In my opinion, Scrum is a kind scaffolding around the team where value is actually created, used to construct the real process, one improvement at at time. And, if you know where you can go, those improvements should lead more or less towards XP engineering practices. The reality is that Scrum is a lot easier to sell than XP in its entirety, especially when it comes to getting people to rally around a process change to begin with. XP, on the other hand, with its 12 practices, can be mind boggling to start with if you don't have a coach who really knows the drills.

People, knowing only Scrum without the technical practices to make shorter cycles work in the long run, are going to get into trouble. It's as simple as that. Of course not everybody is going to be equally good at it, but awareness is a key element. If not believing something is possible makes sure it won't happen then not knowing about a possibility is an even better way to ensure it never happens. So introducing Scrum as a complete package into a company without at least ensuring awareness of the technical practices, is a risky practice IMHO.

We are fully aware of these risks here at Sprettur, and are ready to provide training in the engineering practices talked about in these posts. Contact us for details.

Hverju eigum við að brenna?

Daði Ingólfsson — Wed, 17 Sep 2008 16:58:15 GMT

Þau teymi sem vinna sína vinnu í sprettum/ítrunum þekkja flest svokölluð brennslurit, ekki satt?!?! Jæja, kannski ekki íslenska heitið en það sem á ensku kallast burndown chart. Þegar teymi vinna í sprettum inniheldur sprettsbackloggurinn (e. sprint backlog) sögur sem oftast eru í stærðarmældar í sögupunktum og tæknileg verk (e. technical task) sem mæld eru í ótrufluðum klukkutímum. Vaninn er að fylgjast með því hversu vel teyminu vindur fram innan spretts með því að plotta á línuriti tímana sem eftir eru miðað við dagafjölda spretts. Dæmi má sjá hér að neðan um brennslurit spretts.

Eins og sést þá má nota svona rit til að sjá, gróflega, hvort það sem teymið skuldbatt sig til að gera á áætlunarfundi sprettsins muni klárast fyrir lok sprettsins. Þessi rit eru lýsandi, auðveld í uppsetningu og viðhaldi, og segja okkur oft meira heldur en verkveggurinn okkar (e. task board). Gallinn við brennslurit sem sýna brennda klukkutíma er að þau segja okkur ekkert um hversu margar sögur teymið er búið að klára til enda. Það má náttúrulega segja að samvinna brennslurita og verkveggja ætti að nægja til að segja teyminu og hagsmunaaðilum hversu vel gengur að klára eitthvað sem verður hægt að skoða/prófa/nota í lok sprettsins. Þroskuð Agile/Scrum teymi færa sig þó oftar en ekki yfir í að mæla sögupunkta frekar en ótruflaða klukkutíma. Eitt teymi sem ég hef verið að vinna mikið með á þessu ári er að prófa sig áfram með að mæla bæði, eins og sjá má á eftirfarandi ljósmynd.

Eins og sést glöggt á þessu riti þá var teymið að klára tæknilegu verkin sín nokkuð jafnt og þétt en sögurnar sjálfar voru ekki að klárast fyrr en undir blálokin. Þetta eru mikilvægar upplýsingar sem geta sagt okkur ýmislegt um teymið og að skoða svona rit í ferlisskoðun (e. retrospective) getur hjálpað teyminu að ræða um hvernig það ætli sér að gera tilraunir til að bæta sögubrennslu sína í næsta spretti svo það sitji ekki eftir með mikið af tæknilegum verkum kláruðum en ekkert til að sýna á demói.

Hver er ykkar reynsla af brennsluritum sem þessum? Hafið þið endað uppi með fullt af tæknilegri vinnu unninni en ekkert til að sýna vörueigendunum á demóinu?