Sunday, May 16, 2010

Agile Saturday Presentation: "8 Lessons Learned from Becoming Agile"

Here are the video and the slides for a presentation I gave on 15th of May at Agile Saturday organized by Agile Estonia.

Video




Slides


Lessons

1.Why do you want to be agile?
L1: Set a goal for being agile or you achieve nothing
L2: Commit to agile values and principles; your practices will follow
L3: Pilot is about learning. Learning is progress.

2.How to reach business agility?
L4: Business agility is about having adaptability and predictability
L5: Create product vision and validate it with customer development
L6: Find your Minimum Viable Product

3.Organization as a people system
L7:Optimize the whole
L8: Build great teams

Community notes
http://docs.google.com/Doc?docid=0AUfzp4C6wtyzZGcyZDVjdnFfMjhjZHhieHZjdg&hl=en

The books I mentioned

The Four steps to Epiphany (Customer development, twitter hashtags #custdev and #leanstartup): http://www.amazon.com/Four-Steps-Epiphany-Steven-Blank/dp/0976470705/ref=sr_1_1?ie=UTF8&s=books&qid=1273989212&sr=1-1

The Five Dysfuntions of a Team (must read for team leads / scrum masters / managers): http://www.amazon.com/dp/0787960756 Estonian translation: http://www.raamatukoi.ee/cgi-bin/raamat?164328 (cover picture):

Thanks to Erkki Kildvee for sending the cover picture :o)

Tuesday, May 4, 2010

Scrum Guide in Finnish

I and Samuli from Huitale are proud about participating to the translation. The first version of Finnish translation of the Scrum Guide is now available at http://ketteryys.files.wordpress.com/2010/03/scrum-guide-fi.pdf

Thanks to other participants: Arto Eskelinen, Petri Heiramo, Antti Järvinen, Lasse Koskela, Lare Lekman, Pentti Virtanen, Vesa Vänskä ja Lasse Ziegler.

Agile Finland will take the ownership from now on so if contact the association if you want to contribute.

More information about the translation (in Finnish): http://ketteryys.fi/2010/03/19/the-scrum-guide-suomeksi/

Monday, May 3, 2010

Commenting Iterations versus Continuous flow

I thought to share a comment I posted to very interesting blog post by @dennisstevens.

I asked few question from Dennis in twitter already but then I thought sharing and elaborating them here.

I am a co-founder & CTO in a startup that practices continuous flow in product development, though we used to practice time-boxed iterations. If you care to read how we changed our process just take a look at: http://huitale.blogspot.com/2009/10/huitale-way-is-it-scrum-or-is-it-kanban.html

And our current way with total value stream: http://huitale.blogspot.com/2010/03/huitale-way-our-value-stream-map.html

In twitter I challenged the point "Continuous flow makes most sense when the outcome is pretty clear and feedback is not as likely to impact subsequent work". For us it has been the opposite. It made sense to drop time-boxes to enhance the feedback cycle (one piece flow, faster cycle time, faster feedback from the market).

Eric Ries has defined A startup as "a human institution designed to deliver a product or service in conditions of extreme uncertainty" so it is has nothing to do with the size of the company, the sector of the economy or the industry the business is involved in. For me it means two things in this context: 1) there is no stable product 2) feedback from your internal iterations is less valuable than iterations that you do together with the customer (customer development is the thing that we talk in lean startups). Therefore getting stuff out faster (continuous flow instead waiting for the time-box to end) gets you the feedback faster.

Under these circumstances we practice continuous flow and it seems that our findings seem to contradict the claim that "time-boxed iterations work best at the outset with a new product, new technology, or substantially new set of features.". If I would have written similar blog entry, I would have told the opposite and that made me wondering is it just me :o)

I also happen to consult companies with agile & lean and usually help them start with iterative time-boxes. Why? Because time-box gives a boundary in their chaotic environment. Starting with continuous flow would be too hard as they do not know their WIP nor their value stream(s) and figuring out those will take some time.

So my conclusion would be:

Iterative time-boxed approach makes most sense when you have chaos and you need to establish a boundary to get something done.

Otherwise prefer continous flow.