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.

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.

Overview

When estimating as a group, the team tends to be more accurate than an individual. The phenomenon known as the Wisdom Of The Crowd^[1] is a renowned effect widely used in multiple industries. This effect is especially strong when dealing with estimation of size^[2].

Everyone working with a Scrum Team can benefit from using the Planning Card Game. Main applications are estimating size and value of Product Backlog Items, but are not limited to them.  Teams estimating benefit in exchanging knowledge and the Product Owner benefits from values produced while playing.

Starting Conditions

Choosing estimation units

Before the estimation can begin, the estimating group has to choose their estimation unit. Units can be divided into two main groups – absolute and relative.

Absolute

It is possible to use the Planning Card Game using absolute units, but it has been observed that those units tend to turn into relative ones creating confusion of what they actually stand for (the Relativity Effect described below).

Humans in general tend to underestimate work when asked for an absolute value, for example hours^[3] or currency.  Also if using those, the work has to be re-estimated often as the team learns new things and can complete tasks in shorter time period. This time is actually wasted.

Relative

Relative estimation units are more natural. The chain of thought of human brain, even if estimating in absolute units, contains relative estimation implicitly. When asked to give hourly estimate, we first try to find something similar that we completed and then give the relative value.

Using relative units, like Story points we have to remember that they vary from team to team and are not comparable between them. They require a probation period, usually in the form of the first (or few) Sprint before they can be used for costing and future projections with reasonable error margin.

The process of estimation in form of the Planning Card Game takes a higher amount of man hours compared to estimates delivered by a single specialist, but it’s given in shorter time period and tends to be significantly more accurate.

If the team acquires a new skill and they are able to complete requirements in shorter time there is no need for re-estimation. Units are still relative to each other and it will be reflected in greater velocity.

Choosing or composing a deck

To begin playing The Planning Card Game it is essential to create a deck that would address possible dysfunctions and reinforce desired behaviors. For example, adding a ½ card in a deck used by a team with lots of people with attention to detail might lead into endless discussions whether an item should be a ½ or a 1. On the other hand if the team prefers to break items into very small pieces a ½ can be a desired figure.

Fibonacci Sequence and variations

The basic deck for the planning game consists of: 1,2,3,5,8 and 13. Some teams decide on extending it up by 20, 21, 35, 40, 44, 60 and so on.

Very large and infinity cards

Most commercial decks contain values up to ~40 and then a card marked  as an infinity or a “BIG” which means that the item is too big to estimate  it with a reasonable probability.

Half and Zero

Some decks contain “0”, which is used to mark that there is no work needed to perform to add this functionality. Usually it was done accidentally or is included in another item.  Another value in the deck is a ½ – it’s used exactly like other numerical values.

Coffee

It’s mainly used when playing long games (for example initial estimations of the whole project). Coffee indicates a need for a break.

Question Mark

Another variation is a question mark, which is widely used, especially with teams that grow, change members often, or where skill sets are very distinctive. It’s used to indicate “I have no idea how big this item might be”.  When having this card in the deck, game does not stop even when someone does not know anything about the subject. It also reduces the “safe five effect” This card is especially useful for increasing cross-functionality for the team. The person using it acts as a probe for people knowing the subject more. If they are able to understand and estimate the item, it has been clearly described and doubts have been removed.

Bomb

This card can be inserted instead of the infinity. It states that the item is either too big, too complex or needs to be broken down or investigated in order to proceed.

Other decks

There are also decks that consist of T-Shirt sizes (… XS, S, M, L, XL …), are the powers of two or basic numbers. Teams can also use classic playing cards.

Example numerical decks:

0, ½ , 1, 2, 3, 5, 8, 13, 20, 40, 60, 100, ?, ∞

0, 1, 2, 3, 5, 8, 13, 21, 44, ?, ∞

1, 2, 3, 5, 8, 13, 21, 100, ?, Coffee

Playing the game

Process

The process is simple.

1. The Product Backlog item to be estimated is presented and explained roughly.
2. Each estimator places one card out of his/her hand face down on the table.
3. When everyone has a card on the table, they are all flipped at once.
4. If all of the cards are identical, the estimate is valid. If there are differences, person with the highest and lowest number explains why did he/she choose this estimate.
5. After explanations there is another round. Again the highest and lowest estimate should be explained, but the moderator should concentrate on people that changed their estimate and investigate why.
6. Continue rounds until all estimates are the same. Value might be modified when item is already completed.

Safe Five Effect

The Safe Five Effect – it’s an effect that exhibits itself with a huge amount of fives in the estimated list. It can be caused by the fact that some team members are unfamiliar with either the domain or technology and they play a five each time to minimize the probability of being far off from other team members’ estimates.

Deadlock

If there are two adjacent numbers being shown for two or more rounds, for example a five and an eight, the team should accept a higher estimate. This is a safer way – in case the negative scenario happens, the estimate is correct.

Anchoring

In the process of playing it is forbidden to give hints on the size before the first round of estimates is revealed. If someone says “it’s easy”, especially a technical expert, whole team’s perception of the subject will then be shifted towards the suggestion and the valuable discussion will not occur.

Relativity Effect

When the Planning Card Game is used with absolute units, they can turn relative after some time. It can be spotted by the fact that the team burns more hours or man-days in a sprint than there is physically available. This effect is not necessarily negative, but it is recommended that if it occurs, the name of the unit to be changed.

Result

The game usually results in adding details to estimated items and changing some of them as more is uncovered in the discussion. It might also result in questions that have not been asked during the initial specification of items.

Intended Outcome

The Planning Card Game brings value to the Product Owner in form of the basis for further planning and costing.

The value to the Development Team is different. Although being aware of their velocity can be beneficial, the real power lays with the process of playing. While explaining estimates, the team experiences knowledge transfer among people with different skill sets. In addition some Product Backlog Items are clarified further, or lack of certain information is exposed, so that they can be provided later. The process also uncovers new aspects to requirements, so they have to be constantly clarified with the customer.

The value for the stakeholders corresponds to the value for the Product Owner. They are better informed on the progress of work, so that they can make conscious business decisions. True state of the product is revealed and stakeholders depending on it can adjust their plans accordingly.

Top-down Planning Game

There is a modification of the Planning Game for top-down estimates. It requires relative units.  A team might decide to use a bigger unit for bigger items or groups of them. This unit should be named differently than the smaller one.  A team can work on items already completed, to determine the scale. Then when a new set of items arrive, the team can use the process to estimate top-down

Introduction

Scrum promotes on self-organizing and cross-functional teams.  Each Development Team has to have all the skills to turn a Product Backlog Item into an increment of working software.

With large or multiple teams working on the same product it is hard to determine if they have all the skills needed in desired proportions. Same applies to new teams that have just been formed or changed. Creating the Competence Matrix will enable the Development Team to see what skills it possesses at a glance.

Any Development Team can build their own Competence Matrix to increase cross-functionality and show what competencies it might be lacking.

In large organizations a Product Owner might be looking for a Development Team to develop a new product. Having Competence Matrices available, he would be able to select the team best fitting his needs.

How to build a Competence Matrix?

Competence Matrices is a tool that is built in two steps: Identifying Competencies and Filling the matrix. After creating it requires periodical updating.

Identifying Competencies

The first step to building a competence matrix is identifying as many competencies as we can in the team. It can be done in many ways – by mind-mapping all skills in detail on the wall, identifying them on sticky notes and grouping, simply brainstorming on the whiteboard. The Development Team can use any desired exercise to identify those.

The resulting matrix should contain a categorized list of skills and knowledge that team members have.   The team building it cannot forget that knowledge about parts/modules/subsystems of their product are also skills that should be included in the matrix.

Example of a categorized list of competencies:

Filling the Matrix

Once competencies are identified, a table is built. Rows represent competencies and each group should be visibly separated. Columns in this table represent team members.  Every team member fills the matrix on their own. Later it can be refined by the whole team together. The table is filled using the following key:

When filling, cells are being colored according to the grade of the skill. The Development Team can use any color, as long as its pale, vivid and dark versions are easily distinguishable. It enables to evaluate skills at a glance, without concentrating on numbers.

A Competence Matrix built using competencies above might look like this:

From this table we can tell at a glance, that the Development Team would struggle if asked to work on the Reporting System. Further, one can see Brad has extensive experience with version control systems and Donna is the only one that knows a something about Storage, so we should have someone pair with her to increase general knowledge of this system throughout the Development Team.

Updating

Ideally, a Development Team Competency Matrix is updated once a month as part of the Sprint Retrospective. Minimally,

Updates are needed when there is a change in team’s composition, or some new competency is be required for upcoming work.

Intended Outcome

A simple Competence Matrix helps the Development Team plan better. When used during Sprint Planning can reduce or eliminate time-consuming Sprint simulations, where team members assign tasks to each person to determine whether anyone is overloaded or has not enough to do. Based on the Matrix a team might also introduce competency increasing Product Backlog Items. It might also be used to deliberately increase skills within the team or a tool of continuous improvement inspected at each Retrospective.

If there is a change in team composition, members can use the Matrix to pair efficiently, minimizing the amount of time needed to introduce a new team member or transfer knowledge from a leaving one.

Competence Matrix helps decrease risk to the product by exposing competencies concentrated within one person and enabling the Development Team to act on increasing cross-functionality.

The Product Owner can use the matrix to order the Product Backlog more effectively. Knowing that the team should have its members pair when completing PBIs he or she can inform the stakeholders if the delay will be significant ahead of time.

What to watch out for?

Creating a Competence Matrix requires a significant time investment and it needs updating so as to not become irrelevant.

Competency Matrices may contain sensitive information and may need to be a controlled document.

Used improperly, a Competency Matrix may be a tool for holding a Development Team accountable for increasing numbers in it, without regard for the practical need to do so.

When created it might also be easily forgotten, so all the effort put in preparing it will be lost.

Right after that I will go with part 3 of the Scrum turning into Kanban.

Thanks for your support and stay tuned!
KaTe

So I did something unexpected – I brought balloons into one of their meetings. Just plain, colorful balloons. And I kept the manager outside the door, he wasn’t allowed to enter. At first everyone looked at those balloons, some even grabbed a couple. Few minutes into the meeting, when the person being abroad finally got connected, some balloons were already in action. Making weird sounds, rocking on a chair, people had a distraction, so only if they heard a keyword they would pay more attention. It was a huge leap forward, from a lethargic state after 5 minutes, they were actually paying attention. The combo breaker happened few minutes later. One balloon popped, the guy trying to blow it fell down with his char. Real laughter bursted out, everyone started explaining what has happened to the girl on the other side of the phone line.

This was the turning point. The team realized that they don’t have to waste time on unproductive stuff, when they can spice it up a little. We introduced tight timeboxes and made adjustments to all our documents.

Changes in the technical elements were greater than ever. Everyone sat down creating a plan on how to save knowledge escaping with all the leaving people. The Competence Matrix came in very handy (I will describe it in the next post). Because of that they were able to identify who should pair with who on writing some useful documentation along with the code.

But most important is that they were setting their own goals. The new PO was starting to embark on this team, and steadily was bringing some stability. Sprint after sprint, new goals were achieved, instead of carrying things over, they were reprioritized in finally existing Product Backlog.

So what made the change possible?

1. Breaking the lethargic atmosphere. Here simple balloons worked, but that depends on the team
2. Self-organization and self-control – they understood that there are people waiting for the results of their work, so they didn’t need any other push. They started setting goals an achieving them one by one.
3. Clear direction – the new PO gave them a purpose. As soon as he arrived, even though he didn’t know everything about the product, he introduced a fresh perspective – “there are people counting on you”.

You may not believe, but 4 months later this team got rid of the bug queue completely. There was nothing there. Due to systematic exploration of the system and step-by-step creating learning materials while doing so, they were able to create a documentation to all elements of the system. Although it wasn’t complete, it was a help in exploring this unimaginably entangled solution.

Introducing new people got easier as well – due to tutorials and warning signs in the code, they at least didn’t mess up things. Pair working became their daily routine. Two new people joined the team and started completing their own tasks just after two weeks.

Their Definition Of Done evolved. Due to system’s complexity it was also very complex, but inspected very often. Tools were adjusted every few weeks to reflect team’s information and technical needs.

Let’s sum up. Four months later:

Technology: as complex as it can be. Every possible platform, every possible language. Still.
Documentation: Some guidelines and warning signs. Still episodes of huge use cases to investigate, but not every element. This bought A LOT of time to do cooler stuff!
Automation: First pieces started. Still needs work.
Tools: single tool for bug reporting, Excel files for Sprint Backlogs and Product Backlog. Easily modifiable and super simple.
Bug Queue: 0 elements. All bugs and problem resolved instantly.
Feature Queue – steady, with a stress on improvements
Time to speed* : 2-4 weeks

I still remember one moment when on one of the retrospectives a team member that visited the customer organization the most told us story:

“ You know, few months ago there was a huge red piece of paper in the middle of their main whiteboard saying ‘The Boss is down AGAIN’. It was there all the time. I went there today, and there was a tiny green sticky note in the corner saying “The Boss is OK”

But how does that lead to Kanban? That’s episode three.

Some say, that Daily Scrum is there to communicate. (I kinda feel like Jeremy Clarkson introducing Stig now …). Some even claim it’s a daily confession. Or a confirmation of what has been done yesterday. Or a report to the Scrum Master … That just gives me creeps.

Let me tell you a story.
A team of five, four guys and a girl. 10:00 AM again – everyone gets up from their chairs, slouching and with a zombie walk they crawl up to the empty corner of the room. So-called Scrum Master takes out a piece of paper and starts asking each of them:
- What have you done yesterday?
- I’ve been working on X
- What will you do today?
- I will be working on X
- Is anything impeding you?
- No.
- NEEEEEXT!

And so it continued with everyone.
People started looking more and more bored every second. Somebody yawned. When I asked them if they want to cancel their Daily Scrum they suddenly gained energy and all at once shouted: – YES!
- But to DO SCRUM you HAVE TO have a Daily Scrum! – The so-called Scrum Master protested very loudly.
- Yes – I replied – but Scrum only for the sake of Scrum gives you nothing. What is the daily Scrum for?
- Ugh … to communicate of course – he replied with that “of course” manner
- Why would you need a communication meeting if you sit in one room with everyone, you talk to everyone constantly?
- Because SCRUM SAYS SO! – he started shouting at everyone
- Leave Scrum be. I’m asking your common sense.
- My common sense does not matter. Scrum matters.

I was furious on the inside, but keeping cool on the outside. This is NOT what I taught them earlier! His stance was almost impenetrable, but suddenly I got some help from another direction.
- Hey! – the girl, Annie spoke up – we are trying to come to something! Just stop behaving like a kid and answer the question. Can’t you remember our own words – if you don’t know what to do use your common sense? Pull yourself together!
Suddenly his expression changed from an angry caveman to a regular person.
- I guess the common sense dictates that it’s not needed. But Scrum …
- Let’s see what Scrum says about that in just a moment, but I can assure you there is no confession or communication reason in the Scrum Guide. Guys – I spoke to the team – what’s your biggest problem right now?
- We’re having difficulties with planning our work within the sprint.
- So what could help?

After some short brainstorming they arrived at a conclusion that they would like to plan their activites a little more often than every two weeks. I recommended a simple solution: Once a day ask a question – How are you progressing towards the Sprint Goal?
I needed to deal with the so-called Scrum Master still, so I took him for a face to face session and settled the dispute.

Two weeks later I came in around 2PM. The room has changed. Instead of an empty corner, there was a huge cardboard board with sticky notes all around it. People were discussing something lively, it was on a verge of a fight, when it suddenly stopped. I heard the Scrum Master asking the question: How are we doing with the goal guys?
Everyone rushed out of their chairs, they talked energetically , flipping cards back and forth, adding new ones and removing some. In the end Scrum Master counted the number of cards to put it to a management report.
- Now, that was a great Daily Scrum! – I said being very happy.
- A what? – everyone seemed puzzled and concerned – but we stopped those stupind Daily Scrums two weeks ago!
- That’s correct. You stopped the stupid and started the proper Daily Scrum.
- But it’s not a Daily Scrum unless it answers three questions …
- Didn’t you just do that?
- Nobody asked ques … tions … waitaminute …
I could almost see little lightbulbs appearing over their heads. Their pupils dilating to that precious A-HA moment.

So what is the daily scrum for?
- Planning!
Finally I have heard the correct answer.

Of course communication is an essential part of the Daily Scrum, but it’s not the goal. The goal is to plan your next day and optimize your efforts towards the goal. And BTW, the Sprint Goal is another misused or forgotten part of Scrum.

So if someone tells you that the Daily Scrum is the report, confession or communication, you have an idea to slap them in the face just like that:

Today I’m presenting a way to easily imagine how Scrum elemenst interlock, how they react with each other, what, who and when is needed. Inspired by my friend, Paweł Feliński – [I will link to his blog if he writes something ], a Periodic table of Scrum:

Periodic Table of Scrum : at-a-glance scrum chart

The main table is a chart where you can quickly spot where an element belongs. You can print it in high resolution – the PDF is attached below.

Then apart from the main table, all elements are explained like this:

Element chart – Increment

It will be changing if there are changes to the Scrum Guide.
If you spot a typo or any other error, please comment.
Polish version coming soom!

All licensed with Creative Commons, so use, extend and Scrum On!

PDF: Periodic Table Of Scrum EN 1.1

Update: Small but important changes made to the Grooming description – thanks to Tomek Wlodarek @poddrzewem and fixed faulty links

Periodic Table of Scrum by Kate Terlecka is licensed under a Creative Commons Attribution 3.0 Unported License.

What is a User Story?

You might recall a famous conversation between Ken Schwaber and a CFO on a plane:

CFO: What do you do?

Ken: I help people build software in 30 days.

CFO: You mean I don’t have to wait 15 months to get what I don’t want?

Ken: That’s correct. I’ll give you something you don’t want in 30 days.

This simple conversation shows that we, as IT professionals should not be about what our customers want, but what our customers need. We are designing the solution, but the customers have needs. Stories are perfect for getting the WHY out of your client. Without the Why, we don’t know how important is the thing we are building or if it matters at all. Great thing to use, you’re minimizing waste and making customers happy.

http://weheartit.com/entry/8044941

But don’t ram it everywhere. Remember that for a user story to make sense you need a PERSON. It should be renamed as HUMAN STORIES, so that monsters like this wouldn’t be conceived: “As a system I need an interface to be able to test myself”. This is an overkill. Why on earth would you waste your precious time to do something so pontless. Don’t put stories everywhere, admit that you will have bugs to solve that sound ridiculous in the story form, or regression tests, or internal enhancements or large refactoring sessions… Let them be what they are.

So once we understand what a story is, and get the crucial fact that we need an actual person to construct a story, let’s look at it from a different perspective.

A Different Kind Of Story

It’s a tool that helps us understand what the other side needs. So what if we use it inside of a team? Let me show you a couple of situations.

Situations

One: A team of five fantastically intelligent, testosterone-pumped guys fighting each other on a daily basis: “Beacuse you didn’t do this”, “You know s**t”, “It’ s your fault” and stuff like this.

Two: A sunsetting product, a team of 6, a Scrum Master who is in fact a micromanager and an ever-pessimistic Product Owner. A new Scrum Master comes in and sees something like a landscape after the zombie apocalypse. No one knows what to do, barely moving group of  undead haunts the room.

One solution was applied to both cases. Both teams were gathered in a room, explained what a user story is and how to use it, given index cards and pens and told to write a card to everyone. In case number one I was tearing apart every violent card that appeared and in number two I spent almost an hour guarding the door before everyone wrote a meaningful card. In both cases we walked out with a poster of rules to be followed, all explained why and quite easy to maintain.

How to use them?

So how to use a story this way? First, you have to identify roles and names in the team. For example if we have a team of six:

• Mark, Systems Administrator
• Tom, Software Architect
• Jill and Jay, Programmers
• Sahid, Translator and Documentation Expert
• Loev, Test Automation Engineer

We construct the story as:

As a <role>/<person> I need <role>/<person> to <action> so that/because <the WHY>

We can write a user story as a role or as a person to a role or to a person. For example:

As a Test Automation Engineer, I need Programmers to include me in the process of planning, so that I can start working on my test cases right away.

or

As Mark I need Tom to inform me about major system updates so that I can make sure that the hardware is compatible.

After writing those we display them on the wall, affinity group them talk anout them and reformulate them into a set of rules.

Same rule applies if you have two fighting individuals. They have to write non-violent cards to each other. Worked really well with my dad and my teenage brother fighting over a vacation getaway

Why it works?

• Beacuse the person writing the card isn’t midlessly throwing unrealistic expectations and accusations.
• Beacuse the person writing the card needs to realize the exact position he or she is in as the requestor.
• Beacuse putting something on paper calms emotions and makes people think about what appears under their pen.

Try it and let me know how is it working for you.

Three forces are battling inside one person. People, Process and Product, each with its weapon.

PM is forced to bring profit from the product, manage people and try to handle the process of creation. This is as opposite as it can be, the logic will always keep thinking about short term, cutting quality and crunching people.

So, what if we separate those areas? Let’s do the math:

Project = Product + Process

Manager = Money + People

And the one that has the money can own, thus:

Project Manager – People – Process = Product Owner

Hm… interesting. Let’s see how does this resonate with our croocked triangle.

The Development Team takes care of their own and the Scrum Master is there to guard the process. And everyone is balanced and happy!

By this time you surely realized that I can’t draw nor write straight using a tablet. This revelation is a bonus and you’ll be seeing more of that

Credits:

A post by a fellow Scrum.org trainer, Ralph Jocham finally made me put that on (electronical) paper. Thanks Ralph!

You can find his post here: http://agiletips.blogspot.com/2012/04/separation-of-power-in-scrum.html?m=1