Official Huitale Blog

Presentation: Maneuver Warfare and Other Badass Habits of a Lean Product Developer at Tampere Goes Agile

2011-09-19T21:40:00.003+03:00

Here are the slides for a presentation I gave in Tampere Agile Days.

Maneuver Warfare and Other Badass Habits of a Lean Product Developer 

View more presentations from Marko Taipale

The feedback I got:

29 green, 3 yellow, 3 reds.

What went well:
"It is great someone is emphasizing the customer side - at last"

"Completely new learnings"

"Excellent summaries of the things I already know"

"Excellent concrete examples without going too deep to them."

"This gives me new items on my to-learn backlog."

"One of the best presentations lately"

"Best slides of the day"

"Excellent structure."

"I really liked the way you described the inventory - it opened my eyes."

"Very good real-life examples."

To improve:

"I would hope to get even more concrete stuff."

"You could have spend more time explaining 5whys and A3."

"Maybe too analytic."

"Consider not using the word 'lean' at all."

"Your delivery was a bit static."

"Talk without slides or read all your slides" (My note: I missed this one as I had to read&point out some things from the slides.. maybe the feedback was about something else..)

"Several topics mentioned twice." (My note: True, but in different context - measurement and learning is different thing - maybe I was not clear on that..)

Few things I noticed by myself:

Always make sure the slides are front of you so that you do not loose the connection with the audience.

Pay attention where you stand - closer the audience the better.

What everybody should know about systems thinking

2011-03-12T10:00:00.006+02:00

I thought I would share few vids about systems thinking and complexity theory that I think everybody should watch.

Russ Ackoff on" Beyond Continuous Improvement"

How to organise a Children's Party (Dave Snowden)

Dr. Deming - The 5 Deadly Diseases 1984

Presentation: Continuous Deployment – Nextdoor.fi released every day at Scan-Agile 2011

2011-03-07T09:37:00.003+02:00

Here are the slides for a presentation I gave at Scan-Agile 2011.

Continuous Deployment – Nextdoor.fi released every day at Scan-Agile 2011

View more presentations from Marko Taipale

Challenges with "We sell agile teams"

2011-02-13T10:16:00.012+02:00

I recently chatted with some rather talented programmers who are considering entrepreneurship. Their business model would be to provide agile software development team to whomever who wants to get their software done. The value proposition is rather bound to agile software deliveries.

I wrote them an email that consisted the following points:

Some challenges:

Customers do not know what agile means or they have no method to make agile RFQs. It is hard to get to make a value proposition as the "get the team to do it" is rather late in the purchase process. The RFQs have already been made and they usually are not considering agile delivery model.
Say that the customer would be willing and would have the knowledge how to make an agile bid. The challenge is still the surrounding ecosystem that will affect to the delivery (contracts, organizational boundaries, multi-vendor projects where some are applying waterfall, merging the team into the project organization..)
Product Owner issues that block the successful delivery of the proposed value: PO cannot make the decisions or does not know what should be get done and why. The code might be clear but the implementation would not serve the purpose.

Small software development companies are forced to be rather opportunistic. They often end up selling "resources" (= individual programmers) to projects via larger company (either another subcontractor or pure resource renting house). Selling projects requires some mass and commercial investments. Small subcontractor is seen as risky business from the customers point of view - no matter how skillful or agile they might be.

However we need the enthusiasm that has created such a great companies like energizedwork and Reaktor - so be brave and go for it! :)

Something to checkout for anybody considering to become an entrepreneur (by Steve Blank):

photo credits: soldiersmediacenter

"Where does the QA fit into Scrum" - common suboptimal implementation of Scrum

2010-12-12T09:46:00.008+02:00

Here is quite common and very suboptimal implementation of scrum ("Where does the QA fit into Agile"). I have seen this multiple times in the context of multivendor projects where "testing" is externalized to one company and development for yet another company.

I commented the post in the following way:

Sorry to say but this is common suboptimal "implementation of scrum", some refer it "scrumfall" and some think that it is not scrum at all. You simply get feedback "an iteration too late" and your software is never done when "exiting the development phase". Smell of this implementation is usually definition of done saying "ready to be tested".

Anyway, here is how to make it better:

Form a cross-funtional team with developers AND testers in it - their definition of done is "releasable product/project increment" that is tested
There might not be sense to have analysis as "iteration", analysis is continuous flow

How does the tester then participate in the development sprint to get the items you highlighted done:

New feature testing

In sprint planning the testers will help the team to figure out the acceptance criteria for the incoming feature. They might even express that as executable acceptance test (see: http://www.slideshare.net/tcmak/atdd-in-practice) or they might do that within the sprint.
During the sprint testers are doing exploratory testing to find the corner cases of the feature and "how it fits to the whole".
In the demonstration testers help the product owner to see that the acceptance criterias pass and they are there also to make sure that if something is not done then it won't be demoed

Feature integration testing

Integration in the large: testers may work on emulating the external systems or testing these cases (by automating the regression suite)

Regression testing

This is the "product" that testers will do step by step by automating the acceptance tests

It might sound that testers need to be developers. The testing is collaborative activity taken by the "team". If testers need something to be developed then the developers will develop that. Pairing helps a lot in here. Sometimes testers even help the developers to do unit testing because a tester has different point of view which is usually very beneficial.

Many teams (including ours) have successfully managed to build security and performance testing suite that can be executed part of the continuous integration/deployment and have also continuous monitoring in place (to improve these suites). Still there is testing (usability comes into my mind) that might be very hard to fit into sprints .. even by taking 1 small piece in the time.

Edit: Ron Jeffries has also written reply on his blog.

Single product owner model is broken. Problem and Solution team to the rescue?

2010-12-10T09:49:00.032+02:00

It is more important to build the right thing than build the thing right. That's why this is important.

This post is based on personal experiences and the feedback that I've gotten from hundreds of individuals I've been working with: "Product owner (PO) model seems to be broken", "PO is a superman, nobody can do that", "single PO is bad idea" etc.

The motivations to write this is are: 1) find better models 2) provoke you to share about your experiences 3) provoke the community to challenge existing models 4) Books and courses about product ownership seem to concentrate on backlog management and scrum. I find that secondary to figuring out what should be done and when 5) .. finally describe the problem to some people asking me about "why do you think single product owner model is broken" in twitter. (@rowanb @hkokko @romanpichler @toolsforagile ...) :o)

What is a product owner by definition and how it is broken:

1. "the Product Owner, who is responsible for maximizing the value of the work that the Scrum Team does"
We together as organization are here to max value. It should not be only PO's responsibility though it might be a good idea to have one person looking after that value constantly. Team should challenge the value proposition that PO is stating in order to improve it. Team should be driven by the goal(s) to maximize the value instead of externalizing it to PO role.

2. ".. The Team consists of developers with all the skills to turn the Product Owner’s requirements into a potentially releasable piece ..."

This underlines the PO bottleneck problem. They are not truly POs requirements but stakeholders'/customer's requirements that are flowing trough a PO proxy. It is a bad idea to form such a bottleneck for information flow. In addition I would not like to have "one hearsay" talking about what the customer wants.

The guide and CSM courses have notion that ScrumMaster can teach PO. That's just naive - Most of the certified scrum masters/practitioners that I know have zero knowledge how to study the demand from the customer to understand how the value could be maximized. They often do know how to do backlog management.. but that is typing exercise once you know what needs to be build. Very few ScrumMasters know anything about customer development, business model generation, feature injection, defining MVP etc.

What makes this even worse is that organizations "promote" their POs from "ex-QA guy" or "ex-project manager" who has not been working with these kind of tools. CSPO (certified product owner) does not help here either - you get to hear about storymaps/product visioning, but it is not a product management/business analysis training (I am not saying it even should be).

3. "The Product Owner is the one and only person responsible for managing the Product Backlog and ensuring the value of the work the Team performs."

Yes, we need one being eventually accountable might be the PO or might not.

Ensuring value is just a joke. Customer and your market will tell if you are producing value and you should not give that as "responsibility" to single person in your organization. I rather have transparency to the realized value all the time and want my people to think how to improve on it. For most of the organization "definition of done" ends to "stuff released" and they might be happy about their velocity ("we are so productive") but that all is meaningless as long as you do not measure the realized value and act on it (for instance by removing not used/invaluable features).

For project organization that works on subcontracting "stuff released" though might be "good enough" - if your contracts are not aligned with customer's goals (realized value).

4. "For commercial development, the Product Owner may be the product manager."
Not such a good idea. Here is a slide deck explaining the difference of there roles. One practical issue is that product managers are so busy on figuring out the problem to be solved that they won't be there to support the team (as PO role is defined)

5. "Committees may exist that advise or influence this person, but people who want to change an item’s priority have to convince the Product Owner."
So there we have it, we should have a team to help the PO.

PO is a collaborator for the team ... which is good ... but shouldn't he be studying and developing customers? Smell of contradicting priorities - who to serve and when. I do not want to have this bottleneck.

6. "The Product Owner identifies what has been done and what hasn’t been done."

Why? Why don't we have agree definitions and better transparency - we should all know when it is done and we all are working for the same goal.

On practical side of the things: we do not demonstrate the results of our work for our CEO (who could be the product owner) as we found that to be bottleneck for getting the stuff out. This of course requires that we have very good understanding of the goals and we have evolved our "Definition of Ready and Done" into something that our CEO can trust.

If you are subcontractor you might want to have the "demo acceptance" by "a customer representative". Context.

7. "The Product Owner is responsible for the Product Backlog, its contents, its availability, and its prioritization."

This leads to waiting as items are not available / good enough to be developed. The people doing the work are best to estimate when something is good enough to be developed - POs usually do not have that skill and if they are more than "backlog management PO proxies" they wont have the time to do this.

8. "The Product Owner keeps an updated Product Backlog list Release Backlog Burndown posted at all times."

Anyone can do this, it is about .. big word .. trust.

Context

You might find my angle weird. Take a look at this slide and ask yourself which product owner role you have in your organization. I am talking about big Ps preferably in goal driven context.

Alternative: Problem and Solution team

"All models are broken, but some are useful". Some are even more useful than others so here is model that I think works better than single PO model. Some might find this model familiar since it is mentioned several times in various #leanstartup sessions.

I start by sharing two diagrams: 1) customer development as a parallel process to product development. You might not be doing customer development but you are doing "something to figure out what should be done" - consider that as your parallel process.

Second diagram to demonstrate how the problem and solution teams are working on these processes:

The teams are working simultaneously, exchanging hypotheses, findings, problems and solutions.

Problem team

The goal of the problem team is to find out and define the problem to be solved. This team is all about "what".

Members:
- Sales
- Marketing
- Executive(s) (accountability)
- Technology
- Usability
- Quality (testing, QA/QC whatnot)
- Support

Solution team

The goal of the solution team is to figure out best possible way to solve the defined problem. This team is all about "how".

Members:
- Cross-functional development team including:
- Same technology representative who is in Problem team
- Same quality representative who is in Problem team
- Same usability representative who is in Problem team

Collaboration (overlapping)

Both teams try together to maximize the value. Problem team is trying to achieve this by figuring out who is the customer and what is a problem that is worth of solving. Solution team is providing transparency to the market feedback .. usually in form of solution based statistics.

.. within a context

Startup

In startup the teams may overlap heavily - it may be that the team members for both teams are the same.

Enterprise

In enterprise the teams may exist for each product line / project and the overlap might be restricted to only few team members.

Benefits compared to single product owner model

According to my experience problem-solution team model (compared to single product owner model) provides:

Improved information and knowledge sharing about the problem and the solution
Better alignment towards the goal and shared responsibility about value creation
Multiple views on customer's needs (for instance not only product vision but also architecture and usability vision)
Channel for constructive feedback (in a form of feedback loop from the solution team)
Multiple communication points avoiding the issue of "PO knows it all as he is only one talking to the customer"
Focus on shared team vision and discipline instead of "individuals and interactions"

Things to consider

If you are in a context where you just "execute the big-upfront-planned-requirements" .. you just need "requirements management"
If you need firewall for the team from several stakeholders then you might prefer single product owner model (or proxy between solution/problem teams)
Contracting model (in subcontracting) may prefer single product owner model
Maybe you do not need either models. You might have working model and your product managers in place with their MBAs - beware dogma - product ownership is a function to be carried out not a role :o)

Real life examples

Energized work product stream
Huitale's problem-solution team

Photo credit: Darwin Bell @ flickr

Presentation: Case Nextdoor at LESS2010

2010-11-27T10:04:00.003+02:00

Here are the slides for a presentation I gave at LESS2010).

Case Nextdoor.fi at LESS2010

View more presentations from Marko Taipale.

Presentation: Lean Startup for AaltoES Summer of Startups

2010-07-19T20:49:00.003+03:00

Here are the video and slides for a presentation I gave on July 2010 at Summer of Startups organized by Aalto Venture Garage which is a project of Aalto Entrepreneurship Society).

Video:

Marko Taipale from Aaltoes on Vimeo.

Slides:

Lean Startup for AaltoES Summer of Startups

View more presentations from Marko Taipale.

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

2010-05-16T08:41:00.010+03:00

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

8 lessons learned from becoming agile

View more presentations from Marko Taipale.

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)

Scrum Guide in Finnish

2010-05-04T10:19:00.003+03:00

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/

Commenting Iterations versus Continuous flow

2010-05-03T17:00:00.003+03:00

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.

How to allocate time for bug fixes in agile?

2010-03-31T19:51:00.005+03:00

Recently I have been discussing with various people about bug fixing and getting high quality software. as part of that I happened to comment a blog entry about incentive driven bug fixing activity called "Bug Week" and thought it to be bad practice due to Deming's points about incentives and the personal experience I have for developing software and managing the development of software. The discussion went even further.. I might address the "objective of zero defects" later as it is a whole different topic addressed by lots of people.

Nate however asked very common question that I have heard from various agile teams:

"How to allocate time for bug fixes in sprints while continuing to add new capabilities to the product."

I have multiple non-incentive driven solutions that I have tried with various teams:

1. The Huitale Way - Drop sprints, Stop-and-Fix

As you might know, we in Huitale practice stop-and-fix as our bug fixing practice.

2. Allocate X% of your velocity for bug fixing and other maintenance tasks

If you need to support an existing version of the product while you are sprinting it is a good idea to allocate time for support/unplanned work/maintenance/bug fixing in all your sprints.

3. Bugs as backlog items

Fixing bug must be valuable. Why not to estimate that business value and prioritize the bugs as items in your product backlog? Some bugs might even not be worth of fixing.

4. Have limit for bugs

Some teams have set a limit for bugs. They try to keep number of known issues less than that limit. When the limit is about to be exceeded by a new bug they will start fixing some bug immediately to make room for the new bug.

5. If you are running Kanban, have a swimlane/SLA/Urgent slot for urgent work

Community members have already described urgent slot, swimlanes, and SLAs so I won't do it here.

In the end of the day it is about everyone taking responsibility and being responsible about the product. If you do not have that, no incentive, set objective or practice will help.

The Huitale Way - Our Value Stream Map

2010-03-23T22:22:00.020+02:00

I previously blogged about The Huitale Way and How we release our product every day. The comments on those encouraged me to share our simplified value stream map with the community. My motivation? 1) get feedback in order to improve and 2) give you some ideas. Here it goes:

The stated cycle times (in green) are averages that we measure and keep updated. Orange icons are the buffers in our system to ensure smooth flow and to have independent cadences for business to figure out WHAT we should build and development to BUILD it. Please keep in mind that all our developers are part timers (we do agile and lean consulting besides the development).

MMF stands for a Minimum Marketable Feature that is the smallest possible set of functionality that, by itself, has value in the marketplace. Read more about MMFs from Karl's blog.

DWT stands for Disneyland Wait Time. It is the expected wait time to get full backlog (7 MMF s) DONE, which is good information for our Product Owner.

Discovering themes

Our product development has several inputs:

we try to meet users (Finnish) in a brainstorming session every month in our office
we have done feature voting, surveys and get-together with our community
we try to engage discussions with our users via Facebook group, monthly newsletter (Finnish) and Twitter
we are lucky enough to get feedback from our users via email
we dig into our metrics and business reports (AARRR etc.) to figure our what works (we also look for features that are just waste)
we look into competition and new partnerships
we try to come up with new bright ideas for our product

I think we are still learning and improving our ways to do customer development... Anyway, from these inputs we formulate common themes. Once we have the themes formulated we select up to three themes (WIP limit 3) that we should work on next. The selection is based on what direction we want to take as a company. Naturally we can come back to these themes at any given time to steer the product development according our company objectives - in the end of the day product development exists for the business :o)

Figuring out the Minimum Marketable Features (MMFs)

Once the themes are selected, we work on those until we have MMFs to serve the theme in best possible way. We argue the business value of each MMF and figure out the T-shirt size of each MMF (have been thinking of using Story Maps, Kano model etc. here. So far it has been just list of MMFs each having relative value that is based on our business value model, this is definitely an area that we sould also improve) and finally our Product owner chooses up to seven items to "product backlog" (WIP limit 7), which is actually just queue of NOT-STARTED MMFs, not necessarily in prioritized order as real product backlog would be. Why you might ask.. because developers cannot pull items from there as they are not READY yet.

From NOT-STARTED to DONE aka when are we READY and when are we DONE?

Product owner prioritizes the MMFs and starts working together with the team to get top items READY.

So what's our definition for READY?

No immediate blocker for developing the MMF
If MMF has impact on language content the content is available. It might not be final.
If MMF has impact on look & feel the content is available (GUI layouts, graphics..). It might not be final.
If MMF has impact on emails sent to the users the email templates are available. They might not be final.
If MMF has impact on reports the expected changes are communicated.
If MMF has impact on third party services/integrations the expected changes are listed. List might (and usually is not) final.

Once the MMF is ready it can be pulled to development. We have WIP limit of 2 for development items in order to keep the cycle time as short as possible. Currently our average development time for a MMF is 6 days.

What does it mean that MMF is DONE according our definition of DONE?

MMF can be released
code has unit tests and automated acceptance tests that execute successfully
code passes tests in CI environment
code is refactored and the design is simple
code passes automated QA checks (checkstyle, pmd/cpd & whatnot)
new feature is documented (if applicable, sometimes for third parties)
peer review is done (if applicable, sometimes for critical paths)

What if there is a bug? We stop the line (no MMF moves from a column to another column) and we work on the bug instead until it is DONE. We tried of having separate swimlane for bugs/ ad-hoc tasks, but then we noticed that we do not really need it.

Our current Kanban board

The bright blue boxes (SMART goals etc.) are kind of rules that we have for items that belong to a column.

You might be wondering how we divide the labor between "biz and tech". The following illustration demonstrates our Problem and Solution "teams":

They are heavily overlapping due that we are doing tons of collaboration in each process step.

Have an idea to share? Please also comment for suggesting a topic for next post - I was thinking of showing what exactly is our MMF (internals) or maybe how we work on GUI as it seems to be hot topic in agile community right now.

Turku Agile Day 2010 Presentation: "How to sell agile to my manager?"

2010-03-19T11:02:00.006+02:00

Here are the slides for a presentation I gave on 18th of March at Turku Agile Day 2010.

How to sell agile to my manager?

View more presentations from Marko Taipale.

Notes

In order to sell anything you need to 1) Know your product 2) Know your customer 3) Understand her need.

Knowing our product is hard as it involves software development practices, values, principles, people skills. In addition one should understand the limitations of the product and alternatives for the product (competition).

Traditionally sales is about making value proposition. Value proposition consists of financial benefit (how much money you can save or generate with the product), functional benefit (time-to-market, quality, predictability, embracing business changes) and emotional benefit (happiness, well-being, sustainability.. team/customer/organization level).

If you list all the possible benefits that one could get from agile and you get it sold (or a consultant gets it sold) you should be really worried. Agility as such should not be the goal, but any organization adopting agile should consider why they want to be agile.

Pilots fail cause the management expectations are wrong and you seldom get truly cross-functional team working for the pilot. Pilots are about learning not about getting all the possible benefits that agile could bring. Make sure your management understands that building the knowledge should be the goal for your first agile pilot. Organization should be really interested looking into impediments that will surface once the pilot is kicked off.

Find out what is the current problem in your organization and see if agile could help there. Do not be dogmatic, sometimes agile is not the answer. If your organization is about to adopt agile make sure that you understand the goal and that it is SMART goal.

Turku Agile Day 2010 Retrospective

2010-03-19T09:00:00.012+02:00

I participated to Turku Agile Day 2010 and thought about sharing my insights about the conference.

What went well

Organizers were helpful and you could feel their excitement. Thanks.
There was some buzz. That's a good sign.
6 presentations talked about goals from different angles - having a goal is truly important (as is having a method)!
Presentations were good. Too bad I missed the Kanban talk while having my own session. Luckily got a chance to share ideas with Joakim later on :o)
Socializing events were excellent.

What to improve and how

Awareness room was way too big - hard to get "connected" with the speaker. Get a smaller room.
I (as a presenter) want some feedback - People should tweet more, be proactive :o). I hope hearing some feedback from the organizers in order to improve.
I felt that the presentations did not necessarily met the majority of the audience (some individuals yes..).

Other thoughts

Pascal's & Portia's keynote got people involved. Need to think about applying some of their presentation methods :o)
Vasco's session was very good and I enjoyed it a lot. I personally would have taken the path from business to R&D instead starting from R&D and kind of leveraging it to business - even the cases are "bottom-up". R&D is there for the business so presenting that direction might help the audience to grok the presented ideas.
Petri Heiramo's talk was about training the customer. Once again solid and well articulated presentation from Petri. It would have been interesting to share ideas how to overcome investment policies ("we need budget for the total investment!") that some companies have and look a bit more into contractual aspects.
Elisabeth had interesting case and lots of energy in her talk about "Get Real". "Spec" mean speculation :o). I tried to ask about how she has overcome the problem of Product Owner speculating as according to my experience there are lots of teams doing the WRONG thing RIGHT. In addition I think it is not Lean to learn what is the RIGHT thing to do by iterating it with implementation and demonstrations. I felt I failed to deliver the question so I might get back to Elisabeth about it. So far I have heard Eric Ries talking about solving this issue with Customer Development and it would be nice to hear how others are solving it. (How Eric has done it (compare the slides 21 and 22)). I feel Customer Development is not been discussed enough in agile conferences as we have Product Owners to abstract that issue (but very rarely ScrumMasters/kanbanists are able to coach the Product Owner to do customer development...).
It was interesting to hear Ola speaking about sex. :o)
Enjoyed the dinner with Lars and Lasse ;o)

Overall it was a good conference.

OO Day 2009 presentation: Scrum Is Not Enough

2009-12-11T13:36:00.005+02:00

Here are the slides for a presentation I gave with Ari on 9th of December at OO Day 2009 in Tampere, Finland.

Since the presentation was in Finnish so are the slides. I and Ari might write more on the subject later on.

Scrum Is Not Enough

View more documents from markoot.

The Huitale Way - Is it Scrum or is it Kanban?

2009-10-22T20:07:00.013+03:00

Last week I was sitting together with Jim Coplien and Karl Scotland in Scan-Agile 2009 "speaker dinner" and talking about various things. One of the topics was the way we do product development in Huitale. Jim thought that our way is "red pill Scrum" but another CST (Petri Heiramo) thought it is not any form of Scrum as it does not have timeboxing. Later on I talked with Karl (both over some beers and in the open space session) and got impression that he would consider this to be Kanban.

I noticed that there was a question in Karl's blog about what was the implementation discussed with Jim hence I thought to share our way.

I would like to know which is it in order to be able to discuss with the community about it. I do not favor Scrum over Kanban nor Kanban over Scrum but I feel both are useful and even complementary tools.

Evolution of our Scrum implementation

We started with "pretty close textbook Scrum" and after 26 sprints we had molded our implementation quite a bit based on the results from internal Kaizen events.

Version 1.0: Release story by story
* Note: Blue box is our Scrum wall. It has columns Not Started, In Progress, Done (todo, IP, Done in the picture). Green arrow is daily standup, red arrow is sprint.

At this stage we did sprint plannings and planned work for two weeks sprints. We had continuous integration and deployment capability so we thought that we would like to release story by story instead wait for the end of the sprint. Demos took place on demand, but plannings and retrospectives were taking place every 2 weeks. Progress was shown with burndowns.

Version 1.1: Introduce explicit Work-in-Progress limit

We dropped sprint backlog and burndowns. We were working one to two backlog items at any given time (this was probably true previously as well, but this time it was explicit), measured cycle time and used that as feedback for planning. We still did sprint plannings and retros every two weeks.

Version 1.2: Planning on demand

We introduced WIP limit also for "Not Started (todo) column". Product owner would prepare planning at any given time when there was less than 7 items in that column. It seems we got "pull system" in place as planning, demos, releases and retrospectives took place on demand and features were pulled from "Not Started to In Progress". Some sizing was put also in place and cycle time for each size was measured. As you can see we did not have any timeboxes any more.

Version 1.3: Ready column and Cadence for retrospectives

We noticed that sometimes the items on In Progress did not progress and they jammed the system. In retrospectives we came up that we need some intermediate stage with rules so that unprepared items would not stop the flow. Ready column was defined with limit of 2 and now that became the "pull signal" for Product owner to start preparing some items from "Not Started" to meet the "Ready" criteria. Interesting that Jeff Sutherland is mentioning that 1% of Scrum teams are having similar "Ready" in his blog (EDIT: link fixed, thanks Anu for noticing that :) ). We also noticed that "on demand" retrospectives could be neglected and decided to set cadence for them.

This is our current implementation of Scrum/Kanban that was discussed in the dinner. Do you think it is Scrum? Do you think it is Kanban? .. or do you think it is both?

Why do I care? I would like to discuss the implementation with the community in order to learn from others and it would help me tremendously if we'd have common terminology :o)

TETRAsim Agile Transformation @ Scan-Agile 2009

2009-10-14T11:57:00.002+03:00

I would like to highlight one of our customer cases that is going to be presented in Scandinavian Agile Conference 2009. Go and see Olli explaining how it was done in TETRAsim.

There are still some seats left so you can still register.

Managing "shared resources" in Agile way

2009-08-31T12:29:00.014+03:00

I hate the term "shared resources", but sometimes my customers tend to have them and they are wondering how that fits into agile. Mumbling about cross-functionality and "whole team" just usually irritates them; they want to get their stuff done, even it is suboptimal.

I demonstrate what we did in one of my customers about year ago to solve this issue before they got cross-functional.

Two scrum teams, one shared resource (Database developer).

In the beginning they had one database developer for a department having multiple scrum teams. It was really common that since the database developer commited to Team 1 sprint, he could not serve the others (he was PART of the team 1). Product Owners (PO) got pissed off about not getting their stuff done and always waiting for the "shared resource" to be assigned to help their team.

We figured that we need get the database developer to help the team 2 in middle of the sprint in case the team 1 database related stories would take a day or two to complete. So we moved the guy in between.

Of course we had to ask ourselves how would he know which team to help at any given time, how to prioritize, how to get visibility what he is up to and so on. It was obvious that the "shared resource" would need some kind of "to do" list. I had previously seen kanban used to manage work done in technical operations, so I thought maybe we could use kanban here aswell.

Product owners would still have their backlogs so it would be natural for them to feed the kanban with those.

How to get that done in synchronized manner with everything else? We decided to setup a shared resources meeting before the sprint planning meeting so that the PO1 and PO2 could take the shared resource into consideration while sorting out their individual backlogs. The meeting takes place between POs and the shared resource(s). In following picture the meeting is visualized by dashed circle.

So how does the kanban look alike? Here is a simple example kanban for database developer:

The red counters are Work-In-Process limits. As there was one database developer, we decided to have limit of one item for the "In Progress" column. As you see, each item on the kanban board describes also which team is involved. As this PHYSICAL board is placed on the corridor of the development department, anybody can tell where the database developer is working (he sits together with the team that is visible in "In Progress" column.

It turned out that the solution really worked. POs were really happy to have visibility to their shared resources and they also were amazed how big of a constraint (being visual now) it was for their organization. Another improvement was the increased motivation for the "shared resource" - he got visibility for his future assingments by having them on the kanban board and also he ws in control of his tasks as they were not "hidden" as part of something else.

Conclusion

I would not recommend to have shared resources even with help of what is presented here. Cross-functional teams are more optimal, but if you are on your way to get there, maybe you found this useful.

Please do not hesitate to give me feedback by commenting or sending me an email to marko dot taipale (at) huitale dot com. I am also interested to hear if yu have found some other ways to manage your shared resources :o)

UPDATE - some comments

I got some feedback from various people so here are their comments:

Jonas Lindström

problem comes when not all sees the benefit and it isnt followed up upon, for it to have any value at all we need to be able to trust the kanban at all time... but that's a completely different issue :)

My response to Jonas

Yeah, if the kanban is not up to date then it is basically lying -> no information maybe better than misinformation

Jani Vesterinen

This is quite good note, not that I've seen this kind of problem.. ;)

One important thing, which in my mind is forgotten nowadays easily with all these different work practices and tools, is people coaching. E.g. with shared resource, you should use most of the time for coaching and teaching the people in organization what does it mean if there ... Read moreare shared resources AND that screwing around has to end AND this is the way we try to solve it - Using Kanban board.

p.s. I would even recommend that these shared resources would need dedicated person (Scrum Master or just some bad ass mfucker) who says no if needed as long as everyone understands and is used to work with this kind of concept.

Jonas Lindström (response to Jani)

well, if the work is pulled from a prioritized task list and the only way you get work done is if its on the list you shouldn't have to use a 'no' person... and if you see that you often have too much work that cannot wait a day or 2 for it to be prioritized you might have other issues you should be looking at :)

btw, what is there really to teach and coach here, seems pretty straight forward?

Jani Vesterinen
Hmm.. Shouldn't this be a topic in Scan-Agile - the power of coaching?

Ari Tanninen

Liked the blog! Good basic stuff, a great example and clearly put. :)

Ari Tanninen (response to Jani and Jonas)

Are you guys talking about coaching or tools or processes or what? A Kanban board is just a tool, and no tool will serve is used wrongly. Nor will it compensate bad management nor coaching. Duh? :)

Toyota QC Circle Example

2009-04-27T15:40:00.003+03:00

Imagine having this on A3.

I like it and I do not see too many companies doing this even with their fancy "improvement processes".

Huitale Kanban

2009-04-07T14:35:00.010+03:00

First I want to thank Henrik for publishing ScrumVsKanban as it helps me to describe our way of writing software and getting stuff done. Hopefully we can co-operate at some point to make this all a bit clearer to the community as there obviously is some interest.

I need to stress that I am no way saying that Scrum is bad or you should not do it; I have seen Scrum working in various teams already but found Kanban more appropriate for Huitale internal development :)

We stopped sprinting and doing Scrum after 26 sprints in Huitale. Here is some of the "whys":

We felt that splitting stories is artificial
Estimating sucks, even though it is 20% correct
What we need iterations for?
We can release every day, the process needs to serve us, not vice a versa
What if we have subcontractors and things take just more than 2 weeks?*
Stories are a bit weak, all the teams that I have worked with have trouble with stories (sure you can do something else in Scrum aswell..)
Splitting is about focusing but it is also about loosing some information (see pitfall)

Iterations

YES, we need them for reflective improvement (do we need to wait?)
NO, we do not need them for demo (why wait?)
NO, we do not need them to split stories (leads to problems)

So we do Kanban instead. By Henrik's description we are "Kanban team #3".

“We trigger a planning meeting whenever we start running out of stuff to do. We trigger a release whenever there is a MMF (minimum marketable feature set) ready for release. We trigger a spontaneous quality circle whenever we bump into the same problem the second time. We also do a more in-depth retrospective every fourth week.”

In practice it means that

No sprints nor iterations
No sprint planning
No complexity estimation (no story points)
Flow is more important than iterations

We value more getting a Minimum Marketable Feature out than having multiple stories that have no meaning (as they are parts of something more meaningful) for the business out

Huitale Way

Here is a picture demonstrating our way.

Some acronyms explained
PBL = Product backlog
NS = Not Started
IP = In Progress

As you see, we take 7 items from the backlog to our Kanban board. Why 7? Because that is the amount of items we can keep in our heads at any given time.

Here is a picture of our actual Kanban board

Red numbers are our queue size limits and as you see we allow two items to be In Progress. We have also defined a way how we cope with bugs, how we track waste etc. but I have left them out for simplicity.

Here is (imaginary) example of a Minimum Marketable Feature (yellow card on the previous Kanban board).

We add data to the MMF as it moves in the board. In addition to the board and the item itself we have so called Engineering Board where we keep all the relevant data per In Progress item.

How do we demo?

We have applied scrum-like demos, but we do demonstration per story. If the story is accepted by the Product Owner it will be deployed to production next day thanks to our capability to release every day.

What metrics we follow?

We gather the following metrics

Kanban board cycle time (from Not Started to Done per MMF)
Overall cycle time (From Idea to Done)
Number of defects
Waste

How do we plan or even roadmap?

Based on our cycle times we get average wait times per MMF (we call it Disneyland Wait Time as it won't be precise) . From there we can tell how long it takes to get stuff done. In order to get something done faster our Product Owner simply repriotizes. All data is naturally empirical and currently our wait time is 3 weeks. So 7 items in Not Started means that 7th item will be done after 21 weeks (7 x 3) if In Progress is empty.

Previously we have also tried some sizing based on t-shirt sizes (S, M, L, XL). Each size has been tracked (cycle time for each size adjusted based on empirical data) and they have been relative (3xS = M, 3xM = L, 3xL = XL). I would recommend new teams to start with sizing and then seeing if it works for them.

How do we retrospect?

I think cadence is good for reflective improvement so we have kept the "iterations" for retrospectives. Naturally the team members are actively improving "on the spot" any practice as there is no reason to wait for the retrospective to take place in order to reflect. However, I feel that we need the pulse for retropectives - it reminds us in case we may forget to do it.

Do not hesitate to contact me (marko.taipale at huitale.com) in case this raised some questions or you have similar experiences to share. You can also drop by our office to see it yourself - we have already had some ;)

Fastest Agile Certificate

2009-03-30T15:05:00.003+03:00

Too busy to sit down for 2 days to get certified? No worries, get yours at
http://www.agilecertificationnow.com/

Scandinavian Agile Conference 2009

2009-03-28T00:46:00.003+02:00

I am proud to be member of the organizers also this year. Check the status of the conference or go and do a submission at http://confluence.agilefinland.com/display/af/Scandinavian+Agile+Conference+2009

Is business value model overrated?

2009-03-22T22:49:00.005+02:00

I often get asked how do we calculate business value for our backlog items. We have a (relative based) way to do it, but more importantly I have been wondering how much estimation is actually needed.

James blogged about "Maximizing Value with Agile.." and came out the following:

Work on One Project at a Time
Release Early and Often
Adapt Your Plans
Keep Your Options Open
Plan at the Last Responsible Moment

If your company has clear vision where it wants to go ("we want to have more users for our website"), then your prioritization should be pretty easy.

Is your company just missing the focus and hiding it with a complex business value model?

Exposing Huitale Way - take 2

2009-03-17T08:12:00.004+02:00

Again we are getting visitors from companies to see how we do agile. This time the guests are from Accenture and Leonidas.