The Onion method, or how to facilitate conflict solving without tears

October 31, 2014 Leave a comment

I was recently working as a coach for a client in the financial sector. Their ways of working were very traditional and the IT department was running on fear of failure. As a remedy, they had introduced heavy processes, rigid gates and strict approval procedures.

The proponents of Agile, me included, wanted to relax the rules and have less BDUF (Big Design Up Front). We wanted to follow work on the wall, not in an electronic tool. Backlogs could be in Excel, not in Quality Center. Decisions would be made in workshops and conversations, not in meetings and tools.

On the other side of the argument were Process Owners. They were highly respected individuals who had full authority over their process. Examples of processes were “Testing”, “Architecture” and “Project management”.

When the conflict turned so hot that no-one could ignore it, our Agile Transformation Team called together a pow-wow to discuss about the situation and steps forward. The meeting went extremely well and I want to share with you some tools we used to defuse the bomb.

Start off on the right foot

We started the workshop by asking expectations from everyone. To our surprise, the expectation was not to have own opinion winning but “common understanding about what is mandatory in the process and what is not“. This was a good start; “common understanding” was valuable currency in the discussion. Another important point was that we agreed there can be rules. Agile does not mean throwing everything into the waste basket.

Tool #1: Slicing

One root cause for the conflict was generalisation. When someone said “Testing” then everything about testing became under discussion (tools, methods, practises,documents etc). This made all discussions so huge, that common agreement about “this” over “that” was never possible.

We recognised four components related to any work:
1) Artefact: Document or other output
2) Process: Identifiable steps in the process (for example “Do X before Y” or “Create A during B”)
3) Working practice: How the activity is done (for example meeting or workshop, who need to be invited)
4) Tool: What tools are used and how

This helped to create structure in discussion. Instead saying “Financial Supervision (FiVa) requires that we have specification documents in ShareNet” we can say “FiVa requires that specifications are documented“. This opens completely different discussions.

Tool #2: The Onion

The Onion helps to break the Does/Doesn’t debate into more fruitful conversation. Most conflicts are caused by false dichotomies; arguments about “Always vs. Never” or “Black vs. White“.

The layers of the onion in our case were:
Mandatory: Has to de done every time using the pre-defined way of working
Alternative: Something you have to do, but you have alternative ways of working
Recommended: Not mandatory, but a recommended practise to avoid conflicts
Optional: Something you can do or leave undone and there are recommendations for good practises available

After introducing the two tools, the Process Owner created a list of items in their area: what Artefacts, Tools, Work steps or Practices there are and which level they are in the Onion Model. As you guess, most Mandatory items were Artefacts or Tools. However, there were great insights, for example proposing that a mandatory meeting would be replaced by workshop with less strict agenda.

At the end we had a very good list of well-argumented needs from each participant, for example:
– “Testing can be done using BDD, but in that case the tool should be JBehave” (Optional working practise with Mandatory tool)
– “In order to follow the Architecture Process, team must have discussion with Architecture Steering Group before projects starts. It is recommended to follow Architecture Process also in Agile projects” (Mandatory working practice with Recommended process)

Example of topics discussed with Onion Model

Example of topics discussed with Onion Model

My key takeaways from the workshop and the tools were:
1) People have a desire for common understanding. Having this said in a meeting helps to find a solution.
2) People have desire to hold on to their important things and anchor them into larger entities (“I need to have requirements in written form, therefore I command a tool and process for that”)
3) Creating alternative structure and “baskets” helps people let go things that are not really important (things that are just proxies to get something that is important)
4) False dichotomy is the enemy of conversation. Offering 3 or more alternative levels facilitates agreement.

 

Työllistymisuskoa IT-ammattilaisille Reaktorin ScrumMaster-kurssilla

September 1, 2014 Leave a comment

Reaktor tarjosi maksuttoman ScrumMaster-kurssin työttömille IT-alan ammattilaisille 14.-15.8.2014. Kurssi oli huima menestys: 25 osallistujan luokka täyttyi heti kun ilmoittautuminen avattiin heinäkuussa ja vielä saman päivän aikana 60 kiinnostunutta ilmoittautui jonoon. Tässä blogissa kerron tunnelmia kurssilta ja ajatuksiani liittyen IT-alan ammattilaisten työllistymisen tukemiseen.

Keväällä sain idean: voisinko tehdä osaamisellani jotain hyvää, auttaa niitä joilla on eniten tarvetta ja vähiten resursseja ammattitaitonsa ylläpitämiseen. Ajatus kypsyi otsikoksi “Ketteryys kuuluu kaikille” ja toteutukseksi valikoitui Certified ScrumMaster -kurssi (CSM). Työnantajani Reaktor auttoi: järjesti koulutustilat yhdessä Scandic Hotels -ketjun kanssa, hoiti markkinoinnin, keräsi osallistujat, maksoi kurssimateriaalin painatuksen ja huolehti kaiken muunkin logistiikan.

Ennen kurssia mietin millaisia osallistujia on kurssilla, joka on ilmainen? Millaisia projekteja he ovat tehneet? Yhdistävä tekijä omille pohdinnoille oli: olisiko tämä kurssi jotenkin erilainen?

Heti kurssin alussa huoleni osoittautuivat turhiksi. Kurssiluokka oli ihan tavallinen: taustat, työkokemus, Scrum-osaaminen ja etukäteisasenne Scrumiin oli hyvin samanlaista kuin millä tahansa kurssillani. Pöytäryhmäkeskusteluissa nousi esille samanlaisia kysymyksiä ja oivalluksia. Kuitenkin kurssissa ja sen tunnelmassa oli jotain hyvin erityistä.  Huomasin ajattelevani heti ensimmäisen aamupäivän aikana useaan otteeseen, että tämä on “tavallisen erityinen kurssi”.

Nautin kurssin kouluttamisesta. Kokeilin muutamia uusia harjoituksia ja sain osallistujilta ideoita kurssin aiheiden vielä parempaan läpikäyntiin. Luokka oli isohko (yli 20 hlöä), mytta siitä huolimatta kaikilla riitti energiaa ja innostusta loppuun saakka. Omaa kivaa jännitettä kurssille toi toimittajan ja valokuvaajan saapuminen toisen päivän aamuna tekemään lehtijuttua. Scandic Grand Marinan ruoat olivat herkullisia ja koulutusluokan ikkunoista avautui upeat näköalat.

Kurssin lopuksi keräämäni palaute oli erinomaisen kiittävää. Kaikki osallistujat kokivat saaneensa kurssista paljon hyödyllistä. Keskusteluissa kurssin aikana nousi esille se, miten paljon tarvetta Suomessa olisi ketteryyden ja Scrumin ymmärtämiselle. Toivottavasti koulutuksen käyneet ihmiset pääsevät hyvään työpaikkaan ja saavat auttaa työnantajansa kohti parempaa tekemisen kulttuuria.

Haastoin kesällä muita koulutusfirmoja mukaan talkoisiin: meillä kaikilla on annettavaa IT-ammattilaisten työllistymisen helpottamiseen. Tähän mennessä Nitor on vastannut haasteeseen ja tarjoaa Toyota Kata -kurssin. Kuinkas muut, tuletteko mukaan?

Kiitos kaikille kurssin tekemiseen osallistuneille ja etenkin kurssilaisille. Tämä oli todella mahtavaa ja ehkäpä joskus uudestaan?

Linkkejä:

Kurssin alkupotku Reaktorin blogeissa: http://reaktor.fi/blog/ketteryys-kuuluu-kaikille/

Ennen kurssia Tekniikka&Talous julkaisi artikkelin kurssista (koko artikkelin lukeminen vaatii rekisteröitymisen)

Kurssin jälkeen Tekniikka&Talous-printtilehdessä jukaistu juttu löytyy myös arkistosta (sähköinen versio vaatii rekisteröitymisen, painettu T&T julkaistu 22.8.2014)

Categories: Agile and Lean, Sami Lilja

Ketteryys kuuluu kaikille

June 23, 2014 Leave a comment

Ketterät menetelmät ovat ohjelmisto- ja palvelukehityksen valtavirtaa. Ketteryys, Agile, Scrum ja Kanban ovat työpaikkailmoitusten vakiosanastoa ja kaikkialla haetaan parempaa onnistumista ketteryyden avulla.

Minulle ketteryys tarkoittaa oikeiden asioiden tekemistä.

Vaihtoehtona on asioiden tekeminen oikein. Prosessit, työkalut ja standardit olivat johtamisen työkaluja silloin kun minä aloitin työelämässä. Projekteissa keskityttiin tekemään asioita oikein; sääntöjen, ohjeiden ja kriteerien mukaisesti. Välillä tuntui, ettei lopputuloksella ole niin väliä, kunhan vaan prosessia noudatetaan.

Pääsin itse mukaan ketterään tekemiseen jo vuonna 2007. Onnekseni tapasin ihmisiä, jotka osasivat kysyä oikeita kysymyksiä. Miten saisimme asioita valmiiksi? Kuinka vähennämme turhan työn määrää? Miten voimme tiiminä tehdä juuri niitä asioita, joita asiakas tarvitsee?

Ketteryys ei ole vain kaunis ajatus vaan oikeasti toimiva tapa tehdä työn suunnittelua ja ohjausta. Helppoa se ei ole, mutta onnistuu kun riittävän moni organisaatiossa ymmärtää ketteryyden taustalla olevan ajattelun.

Ketteryys kuuluu kaikille — ei pelkästään johtajille, Scrum Mastereille tai projektipäälliköille.

Olen tavannut paljon lahjakkuutta, joka hukataan. Hyvät ihmiset hukkuvat projektien työkuormaan ja kiireeseen. Aikaa itsensä kehittämiseen ei ole. Viime vuosikymmenen “best practise” ei ole ollut enää pitkään aikaan hyvä tapa tehdä tietotyötä, mutta mahdollisuutta uuden oppimiseen on niukasti. Pahimmillaan käy niin, että lahjakas tiimi hiipuu, osaaminen katoaa, omaksi otettu teknologia vanhentuu ja edessä on irtisanominen. Työuraan tulee katko, eikä edes itsestä johtuen.

Ketteryys kuuluu kaikille — ei pelkästää heille, jotka sattuvat olemaan juuri nyt työelämässä.

Olen siinä onnellisessa asemassa, että saan olla tietotyön tekemisen aallonharjalla. Pääsen oppimaan ja opettamaan uusinta uutta. Olen myös siinä kiitollisessa asemassa, että minulla on mahdollisuus jakaa tietämystä myös heille, joilla eivät muuten pääse kursseille.

Järjestän 14.-15.8.2014 Certified Scrum Master -kurssin, joka on suunnattu työttömille IT-alan ammattilaisille. Upean ja ihanan työnantajani, Reaktorin, sekä yhteistyökumppanien avulla voimme tarjota tämän kurssin maksutta.

Scrum-kurssissa ei ole kyse vain siitä, että osallistujat saavat itselleen tietotaitoa, joka auttaa uuden työn löytymisessä. Meillä yhteiskuntana ja Suomena ei ole varaa hukata stä lahjakkuutta ja potentiaalia, joka on pudonnut töiden väliin.

Yksilön ja yhteiskunnan auttamisen lisäksi, haluan auttaa suomalaisia yrityksiä. Kurssin osallistujat saattavat olla niitä, jotka pääsevät  käynnistämään muutosta ketteryyteen. Suomessa on vielä paljon organisaatioita, joissa todellinen ketteryys on vielä toteutumatta. Rekrytoimalla Scrum-osaajan he saattavat saada juuri sen piristysruiskeen, jota todellinen työn parantaminen vaatii.

Jos olet työtä vailla ja haluat päivittää osaamisesi 2010-luvulle, ilmoittaudu kurssille (ilmoittautumislinkki päivittyy tähän kesäkuun aikana, seuraa tätä blogia ja Twitterissä @samililja).

Jos olet työelämässä ja haluat jakaa viestiä piireissäsi, laita tämän blogin linkki jakoon.

Loppuun vielä haaste: Suomessa on paljon lahjakkaita kouluttajia ja jakamisen arvoisia ideoita. Haluaisitko sinä, arvoisa kouluttajakollega, osallistua talkoisiin ja tuoda oman osaamisesi tarjolle myös heille, jotka eivät työttömyyden takia pääse kursseille?

Categories: Agile and Lean

The TOP-5 wrong reasons to do large projects

April 9, 2014 Leave a comment

Software and service development projects do not need to be large. Knowledge work has the advantage over other domains (e.g. manufacturing or civil engineering) that we can do great things with small group of people.

Actually, doing things with smaller group is a competitive advantage: having less people during development and truly understanding the value for customer, the service or product can be done with less costs. I am not talking 5%-10% here; I am talking 5x or 10x improvement.

However, large projects do exist and their existence is defended with plausible-sounding arguments. Here are the TOP-5 arguments I hear when I propose doing things in a smaller scale.

#5: “You can not build a multi-national safety-critical air-traffic control system with a small team”

No, I can not. But what limits other people in other context shouldn’t be limitation in my work. The fact that some things may need to be large does not mean that everything could be large. Luckily this argument is more on the “academic discussion” side and easy to overcome in a discussion about a real project.

#4: “If we do a project with 20 great people instead of our normal 500 people, then will those 480 people lose their jobs?”

I don’t see how a company would fire people when it starts doing same value with less people (i.e. ROI improves). Could the other 480 people do more value in other small projects? Well, they could lose their jobs if they were hired to do things that should not be done at all.

This is a weird argument, as if someone would enjoy working as a clog in a large machine or purpose of the organization would be doing large projects. But hey, it gives an impression that manager cares about people.

#3: “Large projects are actually a good thing, cost-effective and all that”

They are not.  The interesting part here is what “cost-effective” means. Yes, with 500 people you probably have smaller relative cost of setup and project management cost (visible overhead) than with a project of 50 people. But the invisible cost — internal failure demand — for large projects is huge. People sit in meetings, wait for others and fix problems that late integration brings. But that looks efficient, because everyone is busy.

#2: “Large projects are not good, unless you do it Lean” (or any other current fad)

This sounds more plausible than #3. But then again: if Lean is the magic word, would not it give even greater benefit if you apply it for a small project? You would get best of both worlds: less fixed costs + the benefit of Lean.

What is interesting here, Lean (and other) are often used to fix a problem that should not even exist. “With our Lean approach you can manage the whole value-chain” raises a question “Why did you screw up your value-chain so badly it needs management?

#1: “You don’t have anything that would make our projects smaller overnight” (..so we continue doing large projects)

I call this “The stretch pants argument”. In other words: “I have grown out of my clothes and need to wear something tomorrow, so the only thing I can do is to buy stretch pants“.

This arguments true: There is no silver bullet. Changing from “big band, big upfront design, silo organization and tons of failure demand” is not going to be easy! It requires not only discipline but also new kind of thinking. It requires that organization stops organizing itself inside-out and start organizing outside-in, against value demand.

You can not delay your fitness program any further. If you have pressure from competition, downhill in sales and de-motivated personnel, the only thing you can do is to change how the work works. Trying to “do Agile in large projects” or “manage backlogs between the teams” is not going to take you much further.

It is unfortunate that these arguments take the discussion away from the real problems. Large-scale is a problem and it is caused by some harmful system conditions. Becoming fast, Agile and successful requires change in system conditions. Stop being big in your next project and change anything you need to achieve that. If not, what is your favorite excuse?

What if supermarket would be organized like an IT department?

March 28, 2014 Leave a comment

Imagine a supermarket. You visit there daily or weekly, buy food and beverages and other things you need in your life. The shop has a purpose for you. You probably visit the same store every time, maybe it is convenient or has the right selection or least queues.

What if supermarkets would be organized like knowledge work?

This is what happens.

The items still remain on shelves, that is a proven best practice, and you pick them to your cart. You arrive at the checkout counters and empty your cart on the belts: dairy products on belt #1, vegetables and fruits on belt #2, candy on belt #5, cigarettes on belt #11 and finally washing powder all the way at the end on belt #21.

You move on the other side of the checkout counters to wait for your purchases. A gentleman next to you holds a box of chocolate and tells you he only waits for his toothpaste to leave. A lady walks out of the door, lucky one, she only came for a loaf of bread and she got it through before the counter was closed and resources were moved to dairy line to handle the queue.

When you pack the groceries and are about to leave, you see shop personnel gathering together on the other side of the counters. They look worried at the queues and start franticly moving check-out personnel from a belt to another. Some employees are filling in the shelves, they move next to queues and start counting how many people are waiting, reporting that number to shop manager.

Next weeks things seem to have changed. Belts are now moving 10% faster to increase throughput and check-out personnel is standing so they can move items faster through the scanner. Everyone has also been to “Smile to Customers”-training, queue managers have taken 3-day Queue Management workshop and shop manager organized a well-being day for everyone because employees were feeling bad at work. “Cigarettes” belt is combined with “Diapers”, because both lines had sometimes <100% utilization.

Sounds too far fetched? Nobody would be that stupid!

Yet that is the way we organize most of our IT services and SW product development. We create competency silos and integrate very late. We split customer need into small tasks and make sure the tasks move fast. We use Scrum and Kanban and whatnot to make sure things proceed swiftly. We put time and effort to discuss about queues and make organization changes to balance workload.

But, hey, IT work is knowledge work and hence more complex than working at a check-out register at local shop? Yes, exactly. And therefore people doing knowledge work should pay even more attention to flow, customer value and getting things truly done. Instead of splitting work and managing resources, we should manage work and let people organize around the flow.

Next time you go to you local supermarket, think about how cool it would be to get your IT service out equally fast!

The TOP-3×3 signs you are in a command & control organization

March 5, 2014 Leave a comment

Lists are great and here is my list: TOP-3×3 Signs You Are In A Command And Control Organization.

The signs are divided into three categories, hence 3×3 in the title, and the categories are

  • The Obvious,
  • The Unexpected and
  • The Hilarious

Before the lists, let’s see what is command and control. It is a management thinking pattern that assumes the organization must have

  • Up-front planning
  • Reporting and metrics against the plan
  • Defined roles and responsibilities
  • Hierarchies that support the defined responsibilities
  • Best practices and harmonized work process to achieve efficiency

Command and Control is built on an assumption that people in power know what and how needs to be done, and its is their duty to inform others about this. Communication from “doers” to “decision makers” is done mainly via reporting. The other direction is work orders, tasks and evaluations.

The Lists 

The Obvious are signs that almost all command & control managers create around them. Here are my TOP-3 of those.

  1. Hierarchies. This is a sure sign of command and control mindset. This is an obsession to draw organization charts. Also phrases “reports to” or “is a subordinate” show that the hierarchies dominate.
  2. Reorganizations. Related to the previous, organization structure is the symbol of hierarchies. Organization may have low hierarchies, but if it reacts to impulses by doing a reorganization, then it surely is command & control. Click here to see Dogbert meet with C&C boss.
  3. Performance management. This comes in many flavors: incentives, individual bonuses, target setting and annual performance reviews. All of them are rooted in thinking that someone else knows best how to do work.

The Unexpected are signs that on the first look seem harmless, but closer look shows they are Command & Control in disguise.

  1. Lync, Skype and other communication tools. What? These are useful! Yes, they may be good in some occasions, but these tools drive low-bandwidth communication. Once you have Lync installed, why not skip all face-to-face meetings? Phone / video fits well to giving orders and delivering reports, i.e Command and Control . Worse even, organizations tend to acquire messaging tools to hide the fact that they are not capable to put people work together.
  2. Metrics. Again, these could be useful if they were derived from purpose and customer demand. Unfortunately, almost always these are  merely process metrics: “Are we doing the things right“, “Are we on track” and “Are my commands being executed properly“. Metrics are a great antidote to learning.
  3. Support functions. Human Resources, Premises Management, Finance&Control and so on. These are based on thinking that specialization is a good thing. But this detaches decision making from work and creates system where “someone else knows better” and “do your work so that mine is easier“. Oh, and if anyone comes to you and say they have “Agile X” (X represents any support function), then be very worried. It is just command and control in camouflage.

The Hilarious are signs that are just too absurd to be true. But they are and tell a lot about management mindset

  1. Policies: “Nice that you are doing Scrum, but you can not purchase whiteboards without 3rd level manager approval“. And at the same time the organization buys everyone a $500 license to an Agile Lifecycle Management Software.
  2. Access rights. Both physical world (doors) and virtual world (information systems). If you have trouble getting through doors to your colleagues, then there are significant trust issues in the organization. Interestingly, the more the leaders emphasize openness in all-hands meetings, the more difficult it is to get access rights in the real life.
  3. Institutionalized dysfunctions. Dysfunction is something that is wrong in design and management of work. Dysfunction becomes institutionalized when management creates process or tool to go around the problem and the discussion moves from the problem to the workaround. The original problem remains. If you see a lot of weird meetings talking about things that should not even exist, then you know organization sees a tool or process as a solution to every problem. Command and Control.

None of the items in the list above (except “Performance Management”) as such are harmful to people. Command & Control is not about mis-treating people or imposing punishment (while those do occur). Command and Control is about attitude towards work and it impacts how people in power treat other people, but C&C management is not “evil”. This often confuses managers, because they think they are nice, “people-oriented” and good coaches. Sorry, doing Command and Control more “softly” is not going to help. The problem lies in thinking, not in how the thinking is implemented.

How many of the items on the list you have seen today in your work?

But how do I know it works?

November 21, 2013 Leave a comment

There is an old joke about a lumberjack who – back in 1950s – got his first chainsaw

I want my money back“, says the lumberjack walking into a hardware store.

Well .. why?“, asks the shop owner.

You promised I can cut and prune ten times more trees with this“, replies the angry lumberjack, “but I barely make the same amount I did with axe and saw“.

OK, let’s take a look“, says the shop owner. He pulls the cord and chainsaw engine starts with a roaring noise.

Hey, what is that sound?“, asks the lumberjack.

Have you ever been in same situation? You take a new tool or a new process into use. The promise is more results or more speed or more anything you want.

Then, after a while, you realize that little has changed or things have gone worse. You fail in all new ways.

I see this when I meet with teams and managers who struggle with their work. They tell me about agility and how Scrum or Kanban is the prevailing way of doing work. “We are Agile“, they say, “but it does not help. Can you tell us what to do next?“.

I ask: “How do you know if Scrum (or Kanban) is working?“. Or more bluntly: “How do you know you are doing it right?

The answer is almost always a silence, followed by a deep sigh and question back to me: “That’s a good question. Could you tell us how it should work?“.

Whatever we do, there must be a way to see if we are getting what we are supposed to get. It must be observable: transparencylearning or responsiveness are nice words, but not enough. How do I know, that I’m getting what I’m supposed to get.

The point of Scrum is not the rituals, backlogs and roles. The point of Kanban is not to hang tasks on the wall on colorful Post-It notes.

For me, “The Meaning of Scrum” is: If you create a potentially shippable increment at the end of every Sprint so that it tells you exactly where you are with regards to product vision, then you are doing Scrum right.

Regarding the purpose of Kanban, please take a look at my earlier post “Importance of pull, WIP limits and Kanban system“.

Final note: It’s more important to do right things that do things right. But you will never get your work working, unless you understand why a method works or does not work.

Categories: Agile and Lean, Sami Lilja
Follow

Get every new post delivered to your Inbox.