Before I begin, I have to make sure you’re not fixed on a misconception. The Daily Scrum is not a status meeting, nor a report back to the team. It’s a planning event. You can read some more here: [What is The Daily Scrum for?]
Years back, in the beginning of my adventures with Scrum, I worked with a remarkable organization. They produced very complex software for hardware resting. They were able to emulate elements of a complex network for the purposes of testing, and supplied simulators and testing environments for over 30 independent devices and another dozens for their versions.
The organization struggled with quality due to such a complex system. Even though all simulators acted as services, they were not completely independent. Teams struggled with common protocols, hardware upgrades, shared libraries and dozens of dependent remotely-called procedures. On top of that, some simulators used exotic languages, uncommon technologies and internal scripts that barely anybody understood.
Let me tell you a story of four teams working in this environment. Let’s call them Spring, Summer, Autumn and Winter. These names also greatly illustrate those team’s tempers. I worked with Autumn and Summer.
One day, Marek, one of the smartest people I know, brought a requirement from a demanding customer. They needed a completely new device simulated. A new technology had been developed by our competition, and these devices were starting to appear on networks. Other impediments, such as language barriers weren’t helping either. The requirement was also very time-sensitive, as the market expected them supported in few months. Development teams were currently working on physical devices, so that had to be manually tested. Simulation was crucial.
To make it happen faster we needed four teams of 7-9 great analytical minds who would be able to break a new device apart, see how exactly it worked (it was partially a black box) and emulate it for a testing environment. It wasn’t a piece of cake. And still it was dependent on the core of the product – independently developed by another three teams. Out of those people some were sought after specialists, so their work would have been dependent on other tasks they would have to provide. No others were available.
Imagine the number of dependencies in this environment. Starting with hardware elements, going through knowledge, simply technological core, availability, abilities, of team members, the Product Backlog and many, many others.
So we started working. We decided to start using the practice known from scaled environments – the Scrum of Scrums. And we tiered it. Firstly we did our simple Daily Scrum. Then we did the simulator Scrum of Scrums. In the end, the block was crowned with an organization-wide three element Scrum of Scrums. I particularly remember one of them.
Daily Scrum
– And how is the hard protocol part going?
– Don’t even remind me of this. It’s a f*cking mess. I can’t get to terms with any of the protocol guys.
– Did you try talking to Simon?
– Of course I did, but there is a decision involved on the product level. So our PO number 7 has to make it.
– Does he know about it?
– I hope. I wasn’t able to locate him all week. He must have been off or something. But he’s here.
– So, should we go chase him down after the SoS?
– Sure, tag along. The more the merrier. I will also take the representation duty since I have the problem.
– Small Scrum of Scrums
– And our team has problems with the hard protocol part.
– Um, wasn’t that supposed to be postponed until the next sprint? Core teams aren’t ready yet, I heard
– Postponed? That’s a first time I’m hearing that. Where did you hear that?
– PO number 5 told me.
– Isn’t he supposed to care of the Core teams?
– Yes, but you know him.
– S*it, I have to visit a couple of people then.
– We both have to go to the big SoS.
A quick getting back to the team before the big SoS
– You wouldn’t believe what I just heard. Number 5 postponed the feature. Ana, can you come with me to the big SoS? Looks like we have some impasse.
– Wait – said Angel – isn’t five supposed to care for the core?
– That’s what I said, but apparently not.
– I’m coming with you.
– Big Scrum of Scrums
– And one more big thing. We have some problems with the hard protocol part.
– It’s almost done on our side – said someone from the core.
– Wait … – said the guy from the remaining so-called Small Fly teams –didn’t PO number 8 erase that one?
– Say what? Erased by the customer specialist, postponed by the Core PO, unknown by the rest of the crew. What’s up with this feature? Can we get all our POs here before this blows up in our faces? We know that protocols are the most important now. So what’s happening?
We managed to gather all present POs (9 out of 12)
– Alright, so what’s up with protocols feature?
– It’s postponed. Don’t you know? – said number 2
– No, it’s not anymore – said 7 – I didn’t make that decision. I only thought of it.
– Really? – said 8 – but I cancelled it last week. It was supposed to be realized by the external plugin we’ve just bought.
– No, that plugin is for something completely different – said Marek. It can’t help us.
– But that’s what the Core team told me!
– They couldn’t have. It’s not possible to do this with this plugin. Let’s get someone from Core to here.
Few minutes later
– Tom, why did you claim this can be done with this plugin?
– What? I said it CANNOT be done with this plugin. Don’t you get sarcasm?
– Seriously? All this because of one sarcastic comment?
– That’s what you get for acting with 12 POs…
And this is what we attributed everything to. The 12 POs. Since we could do nothing about it, we just accepted the status quo.
Did you encounter a situation like this? If you did, remember what happened.
And now imagine how it would look like if we STARTED with the big Scrum of Scrums. And pulled work and dependencies as we go along into our teams. In this particular situation, it would save us hours of our time. And situations like this happened every few days. Had we planned top-down we wouldn’t have wasted few hours every several days just to make a decision, and then go back to the SoS group with the decision and back.
That is EXACTLY WHY this pattern has been incorporated into the Nexus Framework as a recommended way of doing the Nexus Daily Scrum.
Try it. You’ll like it. And it will save you lots of time and money. 🙂
I have been an organizational coach for quite a while now. Some companies come to me with issues in the people zone, some suffer from quality problems and some fail to deliver enough value to their customers. But there is one problem that seems to pop up continously.
Let me tell you a little story.
One day a company asked me to look after three developing teams that have just been set in an offshoring location. They have a very nice culture – lots of trust, agility installed naturally (a 20-people organization) and openness in all communication.
When I came in for the first time, I saw two teams. One was vigorous and collaborative, the other was much quieter, not partaking in the discussion where it seemed necessary. One person appeared to be the cause of it. I asked their Scrum Master about the situation in the group, and he explained that one of the developers will become a team manager and to minimize the impact, he will be shifted to the other team.
That worried me – this usually ends up in smothering team collaboration and energy level. I didn’t want to be prejudiced, so I wrote down all possible observable causes of this difference of collaboration:
- Scrum Master lead actively the Daily Scrum instead of allowing the team to self-organize,
- The energetic team was getting real results from the market on what they did from their PO
- Both teams lacked sprint goals
- There was no visible progress from retrospectives
- Teams didn’t have enough knowledge on discussion facilitation
- Sprint Backlogs appeared unclear (but then it might have been only perceived by a bystander)
- The future team leader had an overwhelming personality with inclinations towards command and control approach
When I came in for the second time I saw the situation reversed – the second team was collaborative and energetic, while the first’s energy level and discussions went down. In both teams two things have been corrected already – goals and retrospective findings, so I had to rule those out as the cause. And one thing changed – the new leader was appointed and changed teams. His body language suggested a position of power. It immediately showed in the team collaboration level.
Don’t get me wrong, I see that the new leader is a remarkable specialist and a person with communication and collaboration skills. It looks like with the strength of his personality, formalizing his position he already managed to smother team collaboration.
The Greiner Curve (graphic comes from Accel-team.com)
A similar scenario is happening amazingly often. It usually starts when a company has between 60 and 100 people (the company described is about 100).
This situation is described in the Greiner organizational growth model and is called the Control Crisis. From innovative and entrepreneurial organization it starts to become formal and stiff. Controlling culture emerges, where collaboration thrived. There is a shift in culture across the Schneider Model.
The Schneider Culture Model Graphic from Infoq.com
How does this impact our organization?
Power
There is more than just one form of power. (for the 5 Forms of Power description take a look here: https://controlyourchaos.wordpress.com/2013/12/17/scrum-masters-toolkit-french-ravens-5-6-forms-of-power/)
The problem with powers is that the lower the number, the more primitive the power is. If we have all five, in the moment of stress, we will use the instinctive one. And if we have a complex problem to solve we will make people obey – which limits our team to the intelligence of the person having powers 1 & 2 – others will only comply. That’s why having team coaches or SMs (they have powers 4 & 5), working with teams instead of managers is so effective. There is a reason why all the most innovative companies in the world limit overseeing their teams on the personal level, and concentrate only on the results they produce.
The Lucifer Effect
Philip Zimbardo includes a stunning description of this power paradox in his book “Lucifer Effect”. I encoureage greatly reading something about this phenomeon. It shows how good people turned bad, when given a specific role. Regulations, procedures and hierarchy support that effect greatly.
Leadership quality & career path
As you know, finding a good leader isn’t easy. Especially if we’re talking about team behavior. In IT we generally have people who love technology, they are remarkable technical people, but when it comes to managing they are also remarkably technical. I’m not saying that they don’t have people skills, because the statistics show that IT doesn’t vary much from other industries in this regard. But IT managers tend to manage numbers and technology, not people. Why is that? Because in the majority of companies, there is no clear technical career path, and the only way to advance is to become a manager. And I have seen that prove to be destructive many times already. Good people leaders are rare, and they also rarely seek power, because they already have it, granted by the group. They are catalysts of change, they bring out the good in others, rather than themselves. And they usually don’t want their power to be formalized, because they understand that their relationship with their team will change to less open. I have experienced it – from a Scrum Master I have become a manager of a team. Their behavior changed within a day.
Cultural differences – distance to power
This is a measure introduced by Geert Hofstede in his report on cultural differences. It’s way greater in Poland than in any other European countries (3x as high as in Anglo-Saxon cultures), which is the inability to say no to your superior. It’ all cultural, it’s audible in language and it’s nuances. It prevents people from speaking up when this would be beneficial for the team or the product.
What’s the cause of this?
It appears as if setting a hierarchy is a natural thing to do. But we’re educated to do so and we’re not questioning if it’s the right way.
We’re used to apply solutions that appear simple instead of ones that work.
Lack of measures
Organizations under 50 people rarely measure if what they’re doing actually works. How would you know if your product is successful if you don’t know the market share, the return on investment or how happy your people are? Measure. But measure wisely. If you measure the time your developers sit at their desks, you will have people sitting at their desks. Make sure to base your decisions on evidence: https://hbr.org/2006/01/evidence-based-management
Scrum Master’s responsibility
Another element that comes into play is the depth of Scrum Master’s responsibility. Each Scrum Master has three areas of responsibility –
- The Development Team
- The Product Owner
- The Organization
Working with the organization includes chasing people and goals, so that the environment in which his teams operate is most welcoming. But from what I have seen many times, Scrum Masters fail to do so.
And this is why I’m not really surprised that a big need for management and overseeing teams appears.
One of the primary responsibilities of the Scrum Master is to support the organization in their overarching goals, by not only providing transparency, but also acting as an advisory body to the management of higher levels. In companies where the number of people exceeds 60 this is crucial to avoid or minimize the effects of Control Crisis in organizational growth. This is something that will enable the organization to scale and remain healthy and as productive as possible without smothering effects of close management.
Also if you have Scrum Masters that share their responsibility with the role of a Development Team member it’s virtually impossible for them to pay attention to the organizational zone of their work.
If you encounter this situation in your organization ask yourself one question – do your Scrum Masters give you enough transparency that you can feel safe, or do they fail to do so and you need closer supervision to make sure your products thrive and people develop in the way they want and according to the organizational goals?
My recommendation: if you think you need managers in your teams, please think twice whether you would like to impede your organization this way.
User stories may be by far the most abused and misused XP practice ever conceived. First, look at the name. It’s a USER story. So you need an actual live human being to even meet the naming criteria.
As a <certain type of user>
I want/need <some functionality>
So that <business reason>
The Green Part:
This is a description of a certain user. Be as specific as you can be. Ideally there will be the first and last name of an actual user of the functionality. If you write “As a user I want …” this doesn’t really count as a user story.
The Red Part:
This is the part where you actually write the functionality you think will work in this case. Easy-peasy.
The Blue Part:
This is the hardest part. You actually need to know why does your user need that piece of functionality. Heavens, you will have to actually TALK to the human to know that. Or your Product Owner (I just got chills … ooooh …).
So a little trivia for you:
- Which part of the User Story is the most important and you can’t write one without it?
- Which part is optional?
- Which part is usually the only one used?
Give yourself a couple of minutes before decoding the correct colors of answers:
- #9BBB59
- #C0504D
- #C0504D
So user stories need to have a live person behind them and they can’t go without a reason. So let’s see some examples of VERY BAD user stories:
As a system module I need an interface to communicate with the report section so that I can generate reports
As a user I need a login
As an administrator I need a panel
As a report I need something to generate me
As a registered user I need a login to log me in
So just don’t. Pretty please!
Few examples of neat user stories:
As a registered user I need something to identify me for the website.
As an elderly shop owner I need my new administrative panel so that I can get new functionalities along with old ones that were easy to use for me.
As a football coach I need an administration panel so that I can automatically bribe referees without leaving traces on my personal accounts.
As any polish politician I need a mute button on the media so that I can silence critique.
So if you’re going to use User Stories use them wisely. And the wisest way to write them is to omit the red part. Really. It’s hard, but pays off!
Splitting your user stories
Sometimes user stories are big. Some people call them epics then. We don’t obsess with the naming – use the one you like the most. But the one thing you have to remember is to ALWAYS keep them big enough to hold business value. How will you know that? As long as the BLUE PART is making sense, the story has business value. I know that v-word will be haunting you over and over. Get used to it. It’s not going away.
So let’s see how we can split user stories so that they have business value. This is sometimes referred to as the Concept of Travelling Light – why? Because if you shine a beam of light on one end of the system it should be visible on the other end with the same user story. Short – you have to span all the layers of the system (UI, Logic, Persistence, Abstractions etc.)
Let’s take an example User Story to split:
As a credit card owner I need to be able to input my correct payment information so that I can pay for my plane ticket.
Tough one, eh? Maybe not that bad. Let’s see how can we split it.
- Sub-user type: Credit Card Type
As a [Mastercard/Visa/Amex/Discover] owner I need to be able to input my correct payment information so that I can pay for my plane ticket.
- Data: What payment information do we need
As a credit card owner I need to be able to input my correct [name, card number, expiry date, CVV code, billing address, messaging confirmation code] so that I can pay for my plane ticket.
- Payment steps/elements
As a credit card owner I need to be able to input any payment information so that I can make sure I can use my credit card
As a credit card owner I need to be able to input credit card information so that I can make sure it’s valid
As a credit card owner who has secondary security measures on I need to be able to input the validation code so that I can feel safe while processing my payment
- Maybe you see another line of division?
Price is what you pay, value is what you get.
This V-word will be your partner throughout your Scrum life. Get acquainted.
What’s business value? It’s the quantification of the goal your customer wants to reach with the product you’re building. Basically it answers the question: what for?
It’s amazing how often people don’t pay attention to this. And that’s where the statistics of 35% of requirements changing and 65% of functionality not being used (or barely) come from. You might have noticed that these two numbers add up to 100%. So what the heck are we building?
The problem lays in the fact that the only measurement used nowadays is money. And since software is intangible you only know about its quality when something goes horribly wrong. With cars for example, estimating the value you get from them is relatively easy (even if the seller isn’t completely honest with you) – you can see how they’re made, how much the gearbox is screeching, it it’s big (or small) enough, if it has the right mileage and you can check the opinion of the model with other drivers. You can easily say if you’re willing to pay the price for this beauty.
Would you buy a $100 car with beautiful outside, but with no engine and lacking a couple of front seats? Unless you need it for body part reselling, you will probably choose a $10 000 car with good engine, comfy seats and reasonable fuel consumption (or fun factor). So you’re willing to pay for quality. Or you’ll pay twice.
What usually happens in IT is when you’re gathering requirements, you tend to get as much as possible in fear that if you don’t – you will never be able to get them. That produces quite a lot of waste. You also wouldn’t buy a car that has everything in the world. That makes it ekhm… Homer-Simpson-like?
So how do you measure Business Value?
Your Product Owner is responsible for that. There is even a required column in your Product Backlog that should contain Business Value. If it doesn’t – bug your PO for it.
Sometimes you can measure Business Value directly. If you’re making a system that will speed something up or save money, you can get the exact value it will bring and put it in the Product Backlog.
But if you don’t have that kind of luxury, your PO can estimate it. In some abstract scale – it can be something like Story Points for business value (your PO and stakeholders can play Planning Poker to get it) or completely abstract things like materials, t-shirt sizes, fruit etc.
Oh and one small thing. Paying back your technical debt has NO VALUE. It’s paying your loans, it doesn’t bring you joy.
Hello Again!
Happy new year! Hope you’re all full of good food, nice feelings and excitement to come back to what you do best 🙂
Today I will give you a simple tool – a poster that you can give to your teams, that can really help.
Few years ago, on a conference I met a great guy – his name was Chris Avery. He mainly works with leaders and high-level management. He introduced me to his Responsibility Process, which I really like. It’s based on a model that you can use in your daily work. And if you’d like to know more visit his website.
So what is this all about? Simply: about responsibility. In English, there are two words very close to each other, but with a major distinction. I noticed that not only in Polish, but also in many other languages Responsibility and Accountability are the same word. So please, check in your language if this isn’t the case. And if is, stress the difference on every occasion!
So why a model or a process? Can’t a person just be responsible? It’s a little more complex than that. Children learn responsibility as they grow up and experience more. As adults we can also go through this process every time something happens. So let me explain how it works with an example – I lost my keys.
Quit – you can always quit and just not solve the problem. In the case of losing keys, I would call my boyfriend and say I’m stating with him tonight.
Denial
“No, no no! I couldn’t have lost those keys!” – I rummage through my purse again and again with hope of finding it. Denial is basically a refusal to admit something happened. Kids would go with “It’s not broken” when confronted with a broken vase.
Lay Blame
“This stupid cashier! She was so abrasive, I must have lost those keys because of her!” – this level usually involves some anger. With kids “He/She did it!” is very popular. Basically you blame someone else.
Justify
“It was raining, it was dark, all the stuff was heavy, because all of this I lost those keys” – I am trying to justify that there was no other way, I must have lost those keys. With kids it would be “It happened itself!”. We are trying to lay blame on all natural or supernatural powers we can imagine. But still we don’t admit it may be us.
Shame
“I’m so stupid, I lost those keys again …” – I am blaming myself. Nothing good comes out of it, I just bring some bad mood on myself. Kids who admit they did something bad, are usually taught to feel ashamed “Shame on you!”. It’s a step forward, at least we admit there is some of our fault. But still, nothing gets fixed.
Obligation
Also known as “Accountability”. “Man, I lost those keys, so I HAVE TO call that witch, landlord again… and I’m so bad on the phone”. If you feel you have to do something, but for some reason you don’t really feel like it, that’s obligation. Obligation towards your boss or yourself. Kids usually go with “My mom/dad told me to”. You fix the problem, but out of necessity, not because you want to.
Responsibility
This is the highest level. You don’t look at whose fault that is. You don’t blame yourself. It happened – sh*t happens. “[phone rings] Honey, can I come by your place to pick up my spare keys? I just lost mine. – Thanks, bye!” – something happened? Just go and fix it. That’s responsibility. Doesn’t matter if there were 0,00003% of your fault. Just do it. With intrinsic motivation, not being coerced.
Every person has a certain level of responsibility in specific areas of life. For example – your love life, you can be on the Shame level. You blame yourself for everything that happens. Or you can be on Lay Blame at work – “It’s their fault” or “That’s not my job, it’s theirs”. Usually with your kids, you’re always Responsible. You can also change the level you’re on. Up or down.
Most important thing about this model is that you can’t impose it on anyone. It has to be their decision. When using it as a team, you can post a poster on the wall and whenever someone says “It’s not my job” you can ask – what level was this comment on? Works like a charm 🙂
Good hunting!
Kate
Hello again 🙂
Just like I promised – the second Toolkit post is 2 weeks later. Just click on the tag, it will show you all the toolkit posts.
Today I wanted to show you how humans differ from other living creatures and why we should take advantage of that in our work.
First, we have to understand what Power is. One major thing about power is that only you can grant someone else power over yourself. Sometimes it’s in exchange for something, sometimes it’s just because you want to. Let’s take an extreme case – you have a knife on your throat. Someone holding it demands you do something. You still have a choice whether you do it or not. The price is high, but still, it’s your decision.
So let’s take a look what kinds of power are there, and what benefits they bring.
1&2 – Rewarding & Coercive
These two forms are the most common in nature. Every animal is susceptible to those. Basically they mean that you can do something for someone in order to receive a reward or avoid punishment. This is exactly the carrot & stick. If you use this power, you will get obedience. But nothing more. So if you want your dog to obey, you can give him or her treats to reinforce good behavior and punish bad. But remember, even if you do that , you might not be able to take control over your dog. Because when you turn around, the sausage will still disappear. Exactly the same applies to humans. If you reward and punish, everything will go towards what you reward and what you punish will be hidden. But apart from that, no creativity can be expected.
3 – Given/Formal/Legitimate
This power is only present in creatures who build societies. Did you ever watch The Dog Whisperer with Cesar Millan? If you did, try to remember what he wanted to achieve. He was the Pack Leader for the dog and taught owners how to do the same. He wanted the dog to be submissive. And this is exactly what you will have if you have formal power over someone – like a manager or a police officer. Someone who is high in social ranks, somehow culturally above someone else. But if you operate with this power, you will have submission and submission only. There is still very little creativity involved.
4. Expert
Expert power is something that can be described as being respected, because you know a lot or can do something. This is something that has not been observed in any creatures, besides human. Some researchers believe dolphins, elephants, apes and crows may exhibit that power as well, but no hard proof has been found yet. Working with someone with that power over you, gives you wings to learn. You want to become just like this example someone, so you listen, follow footsteps and try to master this subject. This power gives you learning and conquering difficulties.
5. Referent
This is a power that’s closest to trust. In large quantities it’s perceived as Charisma. It’s something that produces good feelings and engagement. It’s a power that’s easiest to lose and hardest to gain. You feel that this person is just right, you follow their lead. It’s something good leaders have.
6*. Informational
Why is there an asterisk here? Because this power was added later on, it wasn’t in the original research. This is a power that is present only in informational societies. Where having, withholding or manipulating information is possible. Some also argue if this is not only a different manifestation of a rewarding or coercive power. I will leave it for your consideration.
So why should I bother knowing this?
Because the higher the power number is, the harder it is to gain, but the bigger the benefits are. It’s easy to coerce someone to do something, threatening them to sack them or promising a yearly bonus.
Also because coercive and rewarding powers are encoded in our reptilian brain, they are our instincts and it’s extremely hard in a critical situation not to use them. Same applies to given power – only if you give in to your instincts, the more primitive one will take over – the carrot and the stick.
And in critical situations we need creativity, learning and engagement the most – to quickly get out of that crisis.
That’s why Scrum Masters have to have Expert and Referent power but not formal, coercive or rewarding ones. So that they can get the most of people any time.
Use this knowledge wisely 🙂
Kate
Hi Everyone 🙂
Today I am starting a new series. We’ll see how regularly I will be able to update it, but the two posts will be there before Christmas.
So why a Scrum Master’s toolkit? Because lots of SM’s and managers/leaders who would like to build better Teams and Scrum Teams struggle with good sources of knowledge. Of course there is Patrick Leoncioni, the Heath brothers, Tom DeMarco, Esther Derby, Diana Larssen, Lyssa Adkins, Seth Godin, Steve Denning, Ken Schwaber, Ken Blanchard, John Kotter, Jurgen Appelo, Uncle Bob, and many, many others. You can read all of their books, and actually you should. But what about someone that has just started working as a SM or a manager? They should start assembling their own understanding-and-exercising toolkit right away and I would like to give them a digest and a direction where they should go. And to point more experienced ones into terrains they may have never explored before.
Let’s start with one of the most important models for knowledge and skill development. Many know about the SHU-HA-RI model. Good! If you don’t then go ahead and google it. Or not J. The Dreyfus Model is the SHU-HA-RI extended and for me way better explained.
Where did this model come from? In the ‘70s (maybe even ‘60s) of the past century, brothers Dreyfus worked with pilots.
As you can imagine, simulators, just like pilot schools have today were not invented yet. So there had to be some other way of knowing whether a pilot knows enough no to kill their passengers when something bad will happen mid-air. They observed lots of people and finally in 1980 they published a paper where they summed up everything they knew.
So let me explain how the model works. I will use an example that most of us can relate to: learning how to drive.
Novice
You start learning how to drive with your instructor, parent, guardian or sibling. Take a moment how it felt – clutch, gearbox, safety belts, blinkers, wipers, RPMs, speed, the sound of the engine, the big metal box you just sat in to operate. A lot to take in. And a lot of rules: when you change the gear, push the clutch. Release it slowly. Blinker! There is a 40 speed limit here. At this speed change the gear. Lights! … and so on. You were so consumed with getting to know the rules, you needed someone to remind you about some of them you were just currently not concentrating on.
Advanced Beginner
This is the moment when you start to grasp it. Your leg automatically pushes the clutch when you’re changing gears, you don’t even think about the blinker, you just turn it on, sometimes even when you don’t need it. Seatbelt? Automatic when you sit behind the wheel. Mirrors? You know what they are for. But wait. Now, because your processor load with all the mechanics is off, you start seeing the environment around you. You actually see the road signs your instructor was telling you about. You remember here is a 40 speed limit, but suddenly you understand why – there is a sign!
But wait, there is more – there is traffic! There are other people! They are DRIVING! You suddenly start noticing the environment. It doesn’t happen at once of course, but gradually. But this is when you’re not a novice anymore. You gain perception of the environment.
Competent
This is when you just drive. You got your license some time ago, you know your way around town. You don’t worry about operating the car anymore, you just do it automatically and it just listens to what you want to do, not how you want to do it. You drive confidently and you can actually predict what will happen in simple situations. A car coming too fast from a street on your right? You just slow down and watch him closely. Someone isn’t going at a straight line? He may be intoxicated, let’s pay close attention and maybe call 112/911. Rules are in your blood, you can see the environment and you can envision negative consequences of breaking those rules. This is what a competent driver does.
Proficient
Proficient would be an experienced driver. Not their first car, they drove quite a few. Maybe even other vehicles. They have their license for 6, 10, 15 years now. Not only they can envision consequences of breaking the rules, but they bend them and understand why. They can predict even complex situations they have never seen before. For example, a truck driver starts slowly turning left. Something’s not right. That driver may not be aware what is wrong, but his brain will know and put him in high-alert mode. He will be able to predict what speed limit will is where, even without looking at the signs. He may not even remember it. He also may bend the rules – speed limit? RPM limit on that gear? Getting out of skidding? The fact that you have to speed up to do this, may be incomprehensible for a less proficient driver. So a proficient one automatically sees that something’s wrong and bends rules understanding what it brings.
Expert
Most of us will not be experts. WRC drivers or F1 drivers would be experts. Professional truck drivers would. These people intentionally break the rules to achieve something more. And they risk a lot with it. Regular drivers may not be able to operate in an environment when your car weighs 30 tons and you have 2 gearboxes and 20 gears at your disposal. Or when you have to speed up to 130 KM/h to be able to turn. This is the environment where only experts can go.
They also sometimes have kind of supernatural powers. There is a story of an F1 driver that just stopped in the middle of a race. He couldn’t explain why he did that. There were high walls on the track with fans on the top that could see all the action. Drivers couldn’t see more than few
hundred meters ahead. But he just stopped – and as it came out – it saved his life. Right around the corner there was a huge accident, involving several cars. Later everyone started wondering – how did he do that? Does he have some supernatural powers? After further analysis of the footage from the race, it came out that he must have seen the crowd on the top of the fence – they weren’t cheering, as usual, they were looking to their right. He must have spotted it with a corner of his eye and his body just reacted, braking and stopping right before it. It saved lives of few other drivers behind him too. Unfortunately I was unable to find the name of this driver. Maybe someone can help me here?
But there is a catch in all this. Do you know when young drivers crash the most? 6 months after getting their license. Why? Because of the Dunning-Kruger effect. 
You are still a beginner, or start being competent, but you think you’re an expert already. That’s when you start breaking the rules and you either crash or break the engine, or the gearbox. Because you don’t understand consequences as well as an expert would. If you are aware of this effect, you can act.
If you are a Scrum Master, you can watch for that in your team. If they are introducing Scrum for example and after 3 sprints they decide to ditch the Review, you can see the Dunning-Kruger effect is happening. And you can tell then why they should wait a little more, until they actually see the environment.
It applies to everything. Learning to play an instrument, cooking, programming, drawing, simply everything.
It will help 🙂
Kate
Hello, long time no see 🙂
New Scrum Guide is out, so let’s update the PTOS!
Thanks to Fredrik Wendt‘s comments I also updated the Daily Scrum section by adding the Sprint Goal to it. Grooming changed into Refinement and some minor changes were made to Planning.
Enjoy!
Disclaimer: opinions expressed in this post are not meant to offend anyone; they are highly subjective and based on my own experiences.
Just yesterday @thels6 pointed me to a blog post by @pawelbrodzinski on women in IT. Looks like my opinion is sought after 🙂
I have read this post and the preceding one few times and the only sure thing here is I cannot take a side. Let me explain by scratching the surface of the subject in the longest pos I have written on this blog so far.
Availability of IT girls on Polish market
Let’s start with a story from some years ago, when I was seeking a job as a junior developer, right out of studies. A male friend did the same at the same time. We finished the same school, had almost exactly the same experience (I even had a little more) and tried finding a job in the same city. Result? He sent 12 applications, had three interviews and in 2 months he was in. I sent 96 applications, had 5 interviews (3 of them in the same company) and it took me over 6 months to start working. And later I found out that it was only my experience as a manager and some leadership traits that got me this position. It did occur to me that maybe I was just a lousy developer, but I passed all technical tests and interviews. Especially when I was talking to my female friend who had a similar experience few years back – this time it was 2 vs. 20 with her male friend. Third girl confirmed same scenario few months later. So I’m not alone.
Same situation from another perspective: as a manager I observed good influence of girls on teams, so I was very happy when my team asked for one. Hundreds of CVs, dozens of interviews and a total of female candidates: 3. One of them didn’t know what a hexadecimal is, second didn’t show for an interview and the third one failed at writing an algorithm for a Fibonacci sequence. Finally I was able to get girls, but only via friends already on the team or scavenging from a dismantled project.
Why is that? And this is my subjective view:
Girls are really rare in IT in Poland. In one of the corporations I worked with, girls made 11% of the staff, including HR and administration. This is freakishly low. During my studies I was one with 76 guys. There was another girl, but it was temporary.
What I observed was that girls are either brilliant and they excel at almost everything or are just ones trying to go through unsuitable studies to find a husband (and it’s not as rare as one may think). So if there is a team that catches the brilliant one, they refuse to let her go regardless of the price. The rest is just the ones that somehow got through the IT studies and now are looking for any job.
Taking this into account look at the cultural implications of a tradition where a woman cannot learn engineering or maths because she is believed to be genetically impaired towards this knowledge. Once in few hundred there is that one girl who is encouraged by parents to pursue what she was good at, wasn’t brilliant, but good. This is a phenomenon employers don’t really know, thus are afraid of it – will she be as bad as the other girls? Should I risk the simplicity of the male hierarchy for her?
Best are headhunted, worst are suspended between employers. No wonder there is almost no valuable female material on the market. And if there is, it’s a pure gemstone, nobody knows what to do with.
Team building, engineering and too much good stuff
If you come to an open space of a corporation, wander a little and listen you can hear an interesting correlation: if there is a space or a room with no women, the frequency of swearwords is significantly greater. If you introduce a girl to this team, the intensity and frequency of these words diminishes. I have observed this in three corporations in Poland, each one affiliated with a different country, so looks like this is not a factor.
Second thing I observed was the decision making process. Girls acted as catalysts and there were two types – the fighters and the quiet ones. The fighters stood up to what they believed in and argued their point until either they won or someone came up with something better. The quiet type just sat there in silence for the majority of the meeting, but the moment she opens her mouth, everyone goes silent. Her opinion and expertise is extremely valued. In both cases the impact on decisions made was positive – less quarrel later on and braver ideas, but better thought through.
So why I prefer to work with men rather than women? I like to have a female friend in a group, but not too many. Why? Let me tell you another story.
A professor in my negotiations class once conducted an experiment. At first it was supposed to be a joke, but it turned out to be scientifically interesting. The experiment exercise was based on two groups of interests – fruit growers and producers of local vodka. Both, not knowing what the goals of the others are, where supposed to gather points that were later summed up by the agreement they all signed. The maximum amount of points a group could gather was around 20.
The control group consisted of few groups of mixed gender: 2+1, 1+2 and 2+2. In these cases negotiations took between 20 and 40 minutes, and the producers beat growers by around 5 points, resulting in average in 8 vs. 13. So the exercise was skewed somewhat towards the producers, rather than growers. Then professor started dividing groups by gender and giving them same exercise.
When both groups consisted of men, the negotiations took less than 20 minutes each time, resulting in low scores for both. Guys just quickly agreed on something and left to take a break. Scores almost never exceeded 10 points, regardless of the side.
If there was girls vs. boys group, girls almost always crushed boys. It was very hard to get a negative score in this exercise, but somehow guys managed to do this few times.
But when there were girls vs. girls, there was fire. The competitive nature of women showed – only few groups managed to finish within the class time (1.5 hour) and the score was about the same as the control group. So no gain here, just more smoke.
Why was that? My explanation is that women’s competitiveness and attention to detail resulted in discussing and quarrelling about every little thing there was to discuss. Men looked at the broader picture and strived towards a common goal of having a longer break in the end of the class.
Looking at this exercise and my observations I believe the healthiest groups are mixed ones. Don’t strive for too many girls – they may impede the course of work.
In addition in 2010 or 2011 in HBR there was a study published that analyzed gender distribution on executive boards of big companies. The interesting thing was that the more women, the better, but if there was more than three, the correlation stopped. Generally the executive boards with up to 3 women generated about 11% more revenue, but with 4 or more it was less (I couldn’t find the article online, I will scan my paper archive if someone is interested).
It all corresponds with what Anita Woolley wrote, I’m only curious about the team sizes she researched. Teams with women on them tend to do better, because of their emotional intelligence and instincts they naturally facilitate group discussions and create a bond in a team. They also increase the mutual respect. As long as someone else doesn’t show up in the same dress 😉
Cultures and countries
All my observations concern Poland and our cultural implications. I suspect there is a major difference between how women are perceived and what impact do they have in Poland and outside it and I had some opportunities to observe it – mainly in USA and India, but also in Finland and Austria. There are two major differences I wanted to point out.
First – general cultural perception. In Poland it’s customary to let a woman though the door first, to help her with an obstacle, not let her carry heavy stuff, introduce yourself first and things like this. It’s absent or barely present abroad.
Second – treating women seriously. And this is a huge problem I’m observing. If a girl is just standing there, looking good or mingling, all is great, she is respected and adored. When she is an expert in something, she has to work three times as hard to prove herself. It takes me way more time to prove I have something interesting to contribute than my male friends. Same happens with my female technical friends. Unless we have been introduced by someone that knows us, we have to wrestle someone down or prove someone wrong before being respected in a male group. This is exceptionally visible in conventions and conferences. I also talked with two transgender professionals and they both agreed that their life became harder as experts when they became women.
And again – this is something I failed to observe or was barely there in the countries I mentioned above. It was completely non-existent in India, where women make 50% of the staff and are encouraged by their male colleagues to pursue what they are good at. Interestingly it’s generally testing, but I attribute it to the attention to detail and ability to multitask.
Conclusions
Employ girls. But not at any price and every single one. Treat them equally – look for your own bias, if there is one, but don’t choose a girl if she is a worse candidate. I once was lured by the prospect of diversity in a team and failed.
Girls in teams rock – just don’t compose a team solely out of girls.
And for the technical discussion – forget there is a difference in gender as hard as it may sound.
P.S.
Girls – don’t wear red to work or to an interview. Unless you want to be subconsciously perceived as an object or a beautiful background by all straight men around. It’s in human nature and you can’t overrun it with the most impressive technical demonstration.
You can read previous episodes here and here
So here we are, the team is doing fine, and they fixed all of their major problems, so why conduct a revolution?
The answer is: optimization.
Scrum is a fantastic tool for enabling agile; making sure everyone gets the mechanics and bringing some order into chaos. And that’s what happened. So, if we have an understanding team who knows what they are doing, Scrum is not needed anymore. It’s too heavy for flowing work. Since they fixed everything big, the system went into the maintenance mode. No large functionalities were to be added, mainly small elements, configuration and fixes. New technologies were supposed to be supported by a new solution currently built next door.
Optimization kicked in. Let’s see what they did. First, they visited the admins team (exactly this one: Combining Kanban and Scrum) and made themselves familiar with what they came up with. Their conclusions led to a nice Scrum-Kanban hybrid that was becoming lighter and lighter every week.
First, they took the sprint backlog out. It was kept in an electronic form on a server so that clients could see, but it proved to be useless to them, so the team decided to take up a physical board. Boy, I wish I had a picture – a fantastic, color coded board, with magnets, people and an impressive palm tree on the back. Suddenly everything became clear and people had a nice excuse to stand up and stretch 🙂
Second change was sprints – they resigned from them and started the morning 15 minute plannings and daily standups mashup. Soon they took no more than 15 minutes together.
Their work started flowing, but they never forgot about retrospectives. They were as regular as ever – every week, in the meeting room.
Soon they started lowering the WIP limits on their work and introducing some new people to the team.
Their lead time started to drop and improvements came into place.
But then this is not a fairy tale either. Someone from the management didn’t like that this team was different. Few months later they were forced to go back to Scrum. It wasn’t bad, but it was a heavy process after months of the lightest framework they could imagine. Later it came out that the management needed more visibility, because the system that was supposed to replace this one failed. And of course this system is still supported and works fine 🙂
So why did they adopt Kanban and why it worked?
First – they knew what they were doing. They worked through a tough time together and became a strong team able to self-organize.
Second – it was their conscious decision. Nobody forced this solution on them.
Third – they drove their own transition. I only supported their efforts. This way they were in control and could probe what worked and what didn’t.
Fourth – they learned from other’s mistakes – the first thing they did was to visit a team that did something similar and exchange experiences.
Control Your Chaos 
