Meeting place: Silver Forum, Wroclaw, Strzegomska 2,
Date & Time: 18:00, 31.08.2009
Duration: 2,5 hours

Meeting summary:
Third Agilopolis Community Meeting is already only a memory. Very exciting, but unfortunately only a memory. Agilopolis team hopes that these minutes will give you at least small possibility to leave through it once more.

Word of the day: unassailable = niepodwazalny

According to schedule, there were three topics planned for ACD3:

• Kanban vs Agile
• Motivation
• Testing in agile

Unfortunately, despite moderator utmost commitment, due to heavy discussion about motivation, third topic was not covered.

Kanban vs Agile (Marcin Koltonowski, NSN)
As many fashion words from Japanease, Kaban has its roots in Toyota (Taichi Ohno is recognized as its father). The name in translation means: 'visual card' which quite good describes core part of this methodology.

The goal of reference implementation in Toyota was to eliminate local storages (e.g. parts produced by one part of manufacturing line but not yet used by next one) since these are the costs for company. In perfect company, production will be organized in such mode that there would be no need for additional storages since system will be able to do complete flow without any delays.

Due to that, the core concept of Kanban is a visualization and management of a workflow.

Before goining into details, first it is good to take a look at scale where at one end there are prescriptive methodologies and adaptive on the other one.
RUP with many artifacts and procedures is on the left side, Scrum is in the middle and Kanban just before chaos on the right one.

There are three main and only elements, which are required to be used by Kanban 'certified' organization:

• task board for visualization of workflow
• lead time for planning (how much the transition takes)
• definition of WIP (Work In Progress)

Additionally, company (team) must work according to Kaizen (small improvements each day) and Just in time (everything is done exactly when required - not produced and stored).

As you can see, Kanban does not provide many rules, so there is a risk that it can go out of control. Actually, there was quite a long discussion regarding this issue during the meeting. The outcome was that Kanban is suitable for a project with experienced team working for a long time on similar (sligthly different) projects so there is a time to learn how to work together.

The good example is a car manufacturing process where new card model is more or less build in the same way as previous one. Also maintenance can be seen as such process because it is long lasting and more or less repeatable.

During the presentation, Marcin provided comparison to Scrum (e.g. in scrum iteration length is fixed and there are predefined roles). Interesting fact is that Kanban fulfills agile manifesto but at the same time, can be used as a command&control process.

Advantages:

• optimalization of lead time
• optimalization of bottlenecks

Disadvantages:

• no rules, must be stable product
• depends on people

When to use:

• domain is well known and project is repeatable (please do not comment that this is against project definition)
• one team works on same project/projects for a long time

Summary: there is specific usage for a Kanban, not to be used always!
Very good for maintenance - since is less restrictive than agile(scrum).

Interesting question was raised - is there any case study that Kanban was successfully used in SW project? Unfortunately, it is still open question.

Lecture: The Goal

Motivation (Jerzy Wachala, NSN)
Second topic of ACD3 was motivation. The first important conclusion was that the goal of the presentation is not to provide answers, since there are no good answers to motivation topic but to provide feedback from experience and give some general guidelines.

Initially, the idea of MbO (Management by Objectives), defacto standard in corporate life was refreshed. The main idea is to set goal (what to do) and then verify according to this goal.

More formally:

• set SMART targets
• verify against targets
• reward based on targets accomplishment

Additionally, team feedback should be gathered.

These are general rules, however there are some additional considerations only for managers:

• look for most valuable people
• majority of people should at least 'meet expectations'
• look for showstopper people (least performing)

In general, MbO says that people should be evaluated according to their goals and their performance. In many case, it means that people should be evaluated based on results that are under their control. On first thought, it might seem as a good idea, however in the long run, it means that everyone is taking care about it small world but nobody is actually looking at whole picture. So my part can work, your part works perfectly well but at the end, company is going down since final product does not work.

MbO as all tools must be used carefully and with some degree of wisdom.

Extreme example is sometimes used in manufacturing companies.
In many production companies, there are no defined processes for project, person is assigned, feasibility study is done and based on that decision is made to proceed.
Project manager and team have full control are their evaluation is based purely on project result. =>You are as good as your last project.
According to statistics, such approach yield quite good results (gross margin of 87%) despite the fact that 10% of projects fails completely and additional 30% fails in some criteria.

After introduction, there was some kind of quotation about power by W. Edwards Demming, but it seems nobody got it :).

Problems with MbO (in case of successful project):

• competition within the team due to individual grades
• competition between the teams
• perception of unfairness (good work was done but anyway you are average)
• perception of impossibility - is it possible to change my mark as an average (there are two best and you are not able to reach them)
• sub-optimization - some KPIs impacts evaluation (e.g. some too general parameters lower motivation, like dependency on company profitability). On the other hand KPIs might be separate by function - OK for one project but for company it might not be very effective (e.g. lack of knowledge sharing)
• destroying intrinsic motivation - there are no advantages to do something better together, additionally - only most paid tasks are being done

Motivation Guideline:

• double level of promotion (technical/managerial) - senior developer, can earn more than manager
• clear fair location on the pay system - clear rules about grade)
• tie profit sharing to economic driver - but be reasonable, not for the whole company but e.g. on program level
• gratification is based on money that project bring to the company
• money are not the prior motivator
• Management role is to support employees - even ask to provide information about desired development plan

Especially, fifth point provided strong discussion, the outcome was that money should go after development of an employee. However, in Poland, we are still in lower level of Maslow Hierarchy so money is still quite important.
Later on discussion focused on parking places in NSN and their motivation impact... According to underground information, there is one developer with parking place!

Demotivators:

• wise words from the top
• paper certificates after successful project (with gratifications)
• inappropriate praise (musi byc sprawiedliwi)
• random public recognition (without clear rules or completely random)
• not required events (waste)
• cancerous team members
• planned forced overtime

Please also note that two most interesting questions from ACD3 are open on the forum, please feel free to provide your comments:

• How to motivate and handle the best employees (bright, working 12h a day), are they good for the team?
• Kanban - are there any successful stories in SW development?

Agilopolis is also looking for volunteers to lead presentation on ACD4! Comming soon!

Yours,
Agilopolis Team

P.S.>Please find some pictures from ACD3