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?
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?
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!
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 Obvious are signs that almost all command & control managers create around them. Here are my TOP-3 of those.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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
- 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.
- 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.
- 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?
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: transparency, learning 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.
This blog entry is a summary of my session in Scrum Gathering Las Vegas. You can view a video of the session (31 minutes) in YouTube and the slides are available in SlideShare.
1. Systems Thinking
Systems Thinking is an approach to understand the performance of organizations. It looks at organization as a System which consist of interconnected parts that together create the characteristics of the entire system. Instead of looking at the parts separated, Systems Thinking takes a holistic view to understand how the parts fit together.
Parts of the system affect each others. This means that cause-effect relations in a system are cyclic: a results of an event can be also the cause of the event. For example, development team doesn’t automate tests. Team analyzes the causes and finds that problem is the excessive workload causing lack of time. However, when they study consequences of missing tests, they notice that their product has lot of bugs which causes extra work. The effect of a problem is also a cause for the problem.
This brings up an important lesson about system improvement: Getting rid of what you don’t want does not give you what you do want.
Organizations as systems have a Purpose. A system as a whole works to achieve the purpose.
Why it is important to understand Systems? W. Edwards Deming has said that 95% of variation in the performance of the system is caused by the system itself and only 5% can be accounted for the people. This may sound counter-intuitive. You can check my blog post about “Exercise to illustrate 95/5 rule” to see that it is actually quite true. “A bad system beats a good person every time“, says Deming. Similarly, bad people fail in a good system. We need to create a good system and find good people to work there.
2. Thinking – System – Performance
Organizations are created by Thinking: the way we understand cause-effect relations. Thinking creates the system which creates the sustainable performance of an organization.
Unless we change our thinking we are constrained to create systems that repeat the errors of previous systems. For example, if we think all work should be done in projects then we are constrained to fiddle with project details rather than find radical improvement through new thinking (for example continuous delivery).
In order to improve we must have two things
- See the system to understand it
- Change thinking to improve
3. System Conditions
How can we see the system?
System Conditions are visible, tangible things that help to see the system. They are direct or indirect results of design and management of work. Here are some common System Conditions (click to enlarge).
Picture by Hermanni Hyytiälä (Twitter @hemppah)
System Conditions are important for several reasons: (i) They drive the performance of the organization, (ii) In order to improve at least some of them needs to be changed and (iii) They tell us about management thinking.
Everyone wants good for the company so why do we have harmful system conditions? The reason is that people who are responsible for system lack knowledge about the nature of work being done. They do not know how the work works.
4. Change strategies
How can we change something once we see it?
We can change with three strategies. Power-Coercive strategy uses carrot and stick, it rewards following the new rules and punishes for disobedience. Empirical-Rational uses logical arguments to rationalize the benefits of new behavior. Normative-Reeducative uses observation and action, collects information and understanding before changing.
Normative is the only strategy that creates sustainable change.
Imagine 3 year old child learning that fire can be dangerous. Coercive learning would be telling him that touching the fire will result a punishment. Rational learning is telling him that fire is hot. Normative learning is that he sticks his finger in the fire, immediately changes his assumptions about safety of fire, cries a little and learns a lot.
5. Systems Thinking and Scrum
Scrum allows two paths to improve the system. We can deploy Scrum and immediately get rid of some harmful system conditions. Secondly, we can use Scrum as to see the system and experiment with new thinking.
When deploying Scrum, we can have the following improvement just by doing Scrum
- From competing projects to single product backlog
- From functional silos to cross-functional teams
- From long feedback cycles to daily feedback
- From project model to continuous delivery
However, deploying Scrum sounds like a Coercive change. At its best is will be Rational. By it is not Normative, especially if “deployment” involves harmonization of practices or top-down push for Scrum.
A better way to use Scrum is to get transparency, see the system and learn through experiments.
Scrum creates transparency to the work at hand. How do you know Scrum works? If you know, at the end of each Sprint, exactly where you are — then Scrum is working.
Systems have a Purpose. Purpose comes from understanding demand that customers have. Scrum allows teams self-organize to fulfill the Purpose.
Teams and organizations should measure their performance against the purpose. Unfortunately, teams often measure some proxy variable that has no value for the end customer, e.g. velocity.
Second effective pattern in Scrum is experiments. Each Sprint is an experiment. Each improvement that team does is an experiment. This pattern has two benefits. First, it allows to change harmful system conditions gradually through experimentation. For example, “Let’s try to limit work-in-progress in the next Sprint and work on one item at the time”. Usually this has better buy in that pushing changes.
Another benefit of experiments is that it creates culture of experimentation in organization. When teams are doing enough experiments, also management moves away from “analysis paralysis” towards trying new things.
- Organizations are systems, created by Thinking
- System Conditions help to see the System
- Scrum helps to see the system
- Scrum can be used to create Normative change in Thinking
W. Edwards Deming has said that 95% of variation in the performance of a system (organization) is caused by the system itself and only 5% is caused by the people.
This sounds counter-intuitive and training attendees often argue that having great people would solve the problems. Or at least people have greater impact than mere 5%. Many also argue that we should invest in people, coach them, motivate team members and do other “people stuff” to get better.
Unfortunately that will not work. “People issues are not the point of intervention“, says John Seddon and I fully agree. System is the point of intervention. By improving the system, we improve not only results but also motivation and well-being at the work.
Here is an exercise that I use in my trainings to illustrate how Deming’s 95/5 rule applies in knowledge work. This is a quick one, takes about 10-15 minutes including set-up and wrap-up.
1. Context: I draw the following picture on flip chart and tell the context. Joe works for an IT department of a large company. The IT system is used by customers to place orders on-line as well as company internal functions to manage invoices, inventory, sales forecast and marketing. Joe and the team have Product Owner who gets requests from customer help desk and suppliers.
(click to enlarge)
I start drawing from Joe, then the team -> product -> Product Owner -> help desk -> customer -> suppliers -> logistics department
2. Case: I explain people that “help desk receives a call from customer saying that it would be nice to follow order status on the web-site, e.g. estimated shipping date. Product Owner thinks this is a cool idea and puts it to backlog, ready for next Sprint”.
3. Task: After explaining the context and the case, I ask people to pick a pair (or in their table groups) to think “What could go wrong?”. What could happen between customer requirement and Joe so that Joe can not complete the work on time, with agreed content and good quality. I give 2 minutes for the discussion.
I also explain that SW development is a team effort, but in this case we assume that we look at Joe’s work. For example, why Joe (or his boss) would feel at the end of the Sprint that things went wrong.
4. Collecting answers: After discussion I collect answers to flip-chart. Usually the list has something of the following
- Unclear requirement
- Conflicting priorities
- Bad tools
- Bad working habits in the team
- To much work
- Joe’s competency (lack of)
- Misunderstanding customer need
- Lack of testing
- Poor communication with other teams
- ..and so on
5. System or Joe: The last part is to ask people “Who’s fault is this?”. If we have two baskets, System and Joe, which is the cause of the problem. I write on the flip-chart on each line “System” or “Joe” based on what the participants shout. Pretty soon the list is full of “System” and very few “Joe’s”.
This is a powerful way to show what is the impact of work design: When things go wrong, it is because the system. The point of intervention is system, not individuals.
Credits go to Richard Moir at Vanguard System for telling me this exercise. I have modified the original story (about plumbing) to fit the IT industry.