The Blog
Utilizing thinking styles in Scrum development
published January 24, 2011
Should all team members participate in all tasks that the team is doing? Scrum advocates cross-functionality but does that mean that everyone should partake in every task? In short, team culture should encourage for teamwork and everyone should have a possibility to influence decisions but in practice it will be good if some specialization occurs. Why? Read on.
Our ultimate goal is to enable self-organization on a team. A team should work like a start-up company (read “The new new Product Development Game”) that self-organizes around a problem and decides how to solve it. In Thinking Styles book, Robert J. Sternberg presents interesting insights about what kinds of tasks actually motivate people. It turns out that people have preferences for specific types of tasks and teams should utilize this information.
What are thinking styles?
A style is a preferred way of thinking. It is not an ability, but rather how we use the abilities we have. We do not have a style, but rather a profile of styles. People may be practically identical in their abilities and yet have very different styles.
People with different thinking styles will, according to Sternberg, prefer working with different kinds of tasks. Also, this difference gives an advantage for a person whose thinking style suits better with a situation at hand. A developer with more “legislative” style will enjoy design work while a developer with a “judical” style finds analytical work more rewarding.
Thinking style profile is constructed from five categories: Function, form, level, scope, and leaning. These categories form a profile for a person that consists, among other things, of preference for design or executive work, motivation by single or multiple goals, big picture vs. detail orientation, and playing by rules or going beyond rules. For a real description, read the book.
Back to Scrum. I think that in ideal world, everyone should be doing tasks that are best suited for their profile and that they enjoy the most. Of course it does not mean that if nobody likes a task, it will not be made. Also, a team should be cross-functional and members should learn new skills outside their comfort zone. But if entire team is playing to their strengths it will increase work motivation and increase product quality. This is actually what self-organization is all about, people volunteering for tasks.
Nice subject for a retrospective
If a team is aware of others thinking styles it can self-organize more effectively. Therefore, if you don’t know what are the thinking styles in your Scrum team find that out in a retrospective, it will make a nice subject.
Driving a Scrum team at the edge of chaos
published December 12, 2010
Recently I have tried to understand chaos theory and complex adaptive systems and how those relate to Scrum teams. Especially, I am interested in the “edge of chaos” concept and how that applies to my work. There are sources like this and this, claiming that team of people are very creative at the edge of chaos. When I tried to understand what this really means, I had to start from the Agreement and Certainty Matrix.
The Agreement and Certainty Matrix
Also known as the “Stacey matrix”, is a management tool by Ralph Stacey for leaders to get guidance on how to manage people’s work depending on a problem’s complexity and team’s agreement levels.
Close to certainty
Issues or decisions are close to certainty when cause and effect linkages can be determined. This is usually the case when a very similar issue or decision has been made in the past. One can then extrapolate from past experience to predict the outcome of an action with a good degree of certainty.
Far from certainty
At the other end of the certainty continuum are decisions that are far from certainty. These situations are often unique or at least new to the decision makers. The cause and effect linkages are not clear. Extrapolating from past experience is not a good method to predict outcomes in the far from certainty range.
Agreement
The vertical axis measures the level of agreement about an issue or decision within the group, team or organization. As you would expect, the management or leadership function varies depending on the level of agreement surrounding an issue.
In IT world, If we are building a new solution with a technology that is new to developers we are moving from left to right in the matrix. When team does not agree on how technology should be applied, movement is upwards in the matrix. So far this makes sense. If we have challenges on only one area, project tends to be complicated but when both areas are challenging, we are working with a complex problem. Scrum was especially designed to deal with complex problems, where plan-driven approach will not produce best results. In the real world there are no clear boundaries like: “Aha, we just moved into the complex zone, better get us some Scrum”. Even though plan-driven works on simple projects, I think that also they benefit from agile execution.
People are most creative at the edge of chaos
Is this really true? According to excellent book “Group genius“, author claims that a lone genius is a myth and many (if not all) great inventions are a result from collective creativity and cannot be traced back to only one individual. I bet you have seen this personally as well. One person says something, a second one adds a thought, and a third person rephrases the idea. Suddenly a new concept emerges, which is a result from teamwork thus making the team more than a sum of it’s parts. But must all this happen at the edge of chaos and what does that even mean?
At the edge of chaos
Group genius states that collective creativity is the source of great inventions and thus we will need a team to come up with most creative solutions. On the other hand, Stacey matrix states that technology must be challenging and people must disagree if we are working near chaos. This makes sense, as team that always agrees might suffer from groupthink. The scale of Stacey matrix must also be team and situation dependent, as “technologically challenging” depends on the skill level of a team.
Joseph Campbell defines edge of chaos like this:
the edge of chaos is a place where there is enough innovation to keep a living system vibrant, and enough stability to keep it from collapsing into anarchy.
Michael Crighton (In the lost world) like this:
It [the edge of chaos] is a zone of conflict and upheaval, where the old and the new are constantly at war. Finding the balance point must be a delicate matter – if a living system drifts too close, it risks falling over into incoherence and dissolution; but if the system moves too far away from the edge, it becomes rigid, frozen, totalitarian. Both conditions lead to extinction. Too much change is as destructive as too little. Only at the edge of chaos can complex systems flourish. . . And, by implication, extinction is the inevitable result of one or the other strategy – too much change, or too little
If we define a state in which we will not make any progress because “everyone is doing their own thing” as “chaos” then we might have us a setting that can describe “the edge of chaos” in practice. To find out the actual border between chaos and the edge, we must face a situation where we feel that the work is not progressing and stagnation happens. When the team begins to stall because of the disorder, we know that chaos state is reached and some order must be restored to regain momentum. Are you with me?
How to increase chaos in a team
Why would you want to do that? To increase team’s creativity and to energize it to move away from it’s comfort zone.
- Come up with a new point of view and encourage team to discuss why current solution will (or will not) work.
- Facilitate discussions so that also introverts are heard. More insights more chaos.
- Ask team how their solution will work in future and are they taking product vision from all angles into discussion.
- Ask if their solution could be more generalized.
- Focus team on quality and encourage them to avoid one-off solutions.
I do not mean that you should try to guess future requirements and build features that won’t be needed. Purpose is to gain new viewpoints and to twist the problem.
How to decrease chaos in a team
When stagnation happens and chaos is reached, disorder should be decreased so that work can continue. Some ways for a team to decrease disorder are:
- Decrease democracy and select one person to come up with a solution that will work as a starting point.
- Take a small vertical slice and implement a proof of concept.
- Stop discussing and get to work. Once you have something to work with, start discussions again.
- Concentrate on one subsystem in order to reduce complexity on technology axis.
Communication at the edge of chaos
It may take a while for a team to really understand how others perceive a problem and to come up with a potential solution. Without some way to communicate progress team will easily slip into the chaos. I like to visualize things, so I draw. I mean draw like crazy. Class diagrams, domain models, architecture diagrams, story boards, you name it. The purpose of these visualizations is to help team to understand what it has accomplished, give it a shared canvas for discussing about solutions, and to communicate social representations. Biggest value for diagrams is just after drawing and they are not final project documentation as coded solution will most likely be somewhat different from the models.
Some concept models from our current work.
Productivity, creativity, and stress levels
If I have understood the very edge of chaos correctly, it is not very productive state in terms of end user value. Creative yes, productive no. When team is working to gain understanding of a complex issue, it inevitably uses more time to communication and change than when working on straightforward tasks. I feel that actual productivity increase is reached afterwards when we have understood the problem, made a consensus, and pulled out to less complex zone to do actual work. To enter “hyper productive” state, team will have to work like a pendulum, balancing around the edge of chaos. Working near chaos can be quite stressful for a team and it is important to watch how it copes with the stress. It is not a state where I would like to keep team too long at one time, because it will start to wear members down. However, amount of stress at the edge of chaos will likely depend on people’s thinking styles and others are more susceptible to it.
I will have to give more thoughts to this. If you know any good links or have real life experiences to share, I am very interested.
Retro Scrum – coaching with metaphors
published October 24, 2010
“I am wearing multiple hats”, “hats off to the team”, “He was using black hat tactics”, metaphors – we all use them more than we realize. In addition, we have different ways of learning. My learning style is very much visual, so for me it is natural to draw things and learn by grasping big picture first before digging into details. Others learn by listening, but generally metaphors help people understanding new concepts and ideas.
According to wikipedia,
Metaphor is the concept of understanding one thing in terms of another
When coaching, pithy metaphor works like a charm. As people are naturally trying to understand new information by connecting it to previous knowledge, everyday related metaphor can be very effective. In addition, by presenting new information in multiple contexts you will make it easier for a learner to recall that data later. Below is an example of mapping Scrum into everyday cooking metaphor presented in retro theme (I also wanted to practice using Photoshop).
Scrum works like a big happy family (Scrum team) preparing to throw a dinner party (release new feature). Mom (product owner) has written down a menu (product backlog) and requests Dad and daughter (team) to prepare shopping list (sprint backlog), buy groceries and prepare platters (sprint). Family’s eldest son (Scrum master) will keep family’s small children (shields the team) out of kitchen (war room), makes sure that car works, and ensures that dad concentrates on preparing food rather than drinking beer. However, mom will want to check that correct menu is prepared, so she will check platters often (sprint review) and ensures that her party vision will happen. She will probably want to serve food shortly after it is ready, so that quests (users) won’t have to eat cold hamburgers (release often). Dad and daughter must keep kitchen clean (refactor) and try to avoid messy room (technical dept).
There :)
The image is available at Flickr and as A3 size with Attribution-NonCommercial-NoDerivs Creative Commons license.
Scrum Master as a team member
published August 3, 2010
In small teams it is common for Scrum Master to work as a team member and work with code by developing new features. Does it work? Well, it depends, but it can easily lead to problematic situations. I feel that one person can work as a Scrum Master for max. 7-9 people and these people can be divided into multiple teams or work in a same team (although 9 team members might be too much). When there is not enough work for Scrum Master and he also works with new features, there is a possibility that:
- He will concentrate too much on code and neglect real Scrum Master work
- Dual role will hinder team self-management
- Scrum Master can become a bottleneck if he is working with architecturally key components
- Dual role can cause role conflict
Unfortunately, having non-coding Scrum Master is not always possible but if you can, you should try to fully utilize Scrum Master, so that he works with multiple small teams simultaneously.
However there are clear benefits if Scrum Master is very familiar with used technology, knows codebase, and understands architecture. This way he can coach younger developers and help team to avoid pitfalls.
Only with boarding pass
published July 15, 2010
Um… what? That was my reaction to text which was displayed on Lufthansa’s check-in monitors at Helsinki-Vantaa airport. “Only with boarding pass” was clearly visible, but since I had not seen such instruction before, I could not tell what I was suppose to do. Shouldn’t I get the boarding pass from a check-in desk I was queuing to? There was pretty long line and thought of missing our flight crossed my mind… Luckily, gentleman behind us told that we were supposed to get boarding passes from self service kiosk and to use those at baggage drop. I felt like solving Leisure Suit Larry all over again.
- “use check-in kiosk”
- “give boarding pass”
The problem was that we definitely were not only ones that did not understand what to do. Most of the people just went directly to baggage drop desk without first printing boarding passes which slowed down the check-in process. Afterwards everything was pretty clear and “Only with boarding pass” made perfectly sense, why was it so hard?
First of all, most people did not have a script (internal instructions how to act) for this kind of event and therefore were clueless. Second thing that was wrong is that Lufthansa assumed that passengers knew more than they actually did. This is very common in IT also. Developers might assume that business people know “Strategy” design pattern or understand difference between Ant and Maven and communicate accordingly. Business side will use business acronyms that developers have no idea. Often people have a tendency to assume that their audience knows more about the subject than it actually does. This can lead to misunderstanding when neither side will not have courage to say “um… what, you lost me there”. This is especially a problem with younger people, that might just nod like they know what to do, but have no idea what should be done. (I remember doing this in my first job).
In Lufthansa’s case simple instruction like:
First do manual check-in at kiosk and then drop your baggage here. We do this to speed up our check-in process. There will be help available for you at the kiosk.
would have achieved what they were aiming for. To sum it up:
- Do not assume that your audience has same knowledge on a subject as you do
- Have courage to say it when you do not understand something
Reducing prejudice
published April 13, 2010
In his book, Rupert Brown talks about prejudice, its modern forms and how to reduce it. Unfortunately, we encounter different forms of prejudice everywhere, also at work. Prejudice at the workplace can mean e.g. intergroup conflicts between management and developers. In the book, Mr Brown gives multiple definitions for prejudice: “the holding of derogatory social attitudes or cognitive beliefs, the expression of negative affect, or the display of hostile or discriminatory behaviour towards members of a group on account of their membership of that group”. Contact hypothesis is a way of improving relationships between groups. It is based on four pillars that should be fulfilled in order to reduce prejudice between groups.
Social and institutional support
Those who have authority should set up a framework promoting greater contact.
Acquaintance potential
Contact between groups should have sufficient frequency, duration, and closeness in order to permit the development of meaningful relationships.
Equal status
Contact situation should be arranged so that it forms an equal status between participants.
Co-operation
Both groups should be brought together to work with common, solvable problem. It is important that each group is dependent of the skills available in other group.
Situations where prejudice exists at workplace can be really nasty. A leader should be able to notice if prejudice is emerging and react immediately once noticed. This means that the leaders will have to do “Genchi Genbutsu” (go-and-see for us who do not speak Japanese).
Social representations in IT project
published April 12, 2010
Social representations theory is a popular European social psychology concept by Serge Moscovici. Social representations can be defined as commonsense knowledge about general topics that are the focus of everyday conversations. It is something that can start as a abstract thing like “social media” and then people are gradually starting to understand it by anchoring it to old information. This is something that we encounter also in IT projects, especially at the start. Customer old timers have loads of social representations about the business in form of acronyms, services and requirements that e.g. consultants entering the project cannot be aware of. You know that you have encountered a new social representation when you get a confused feeling while the customer is talking about an important ‘thingy’, but you have no idea what that ‘thingy’ is. Don’t worry, we all get that feeling.
I feel that the start of a new IT project is like a wobbly sphere. Project team is forming, people are encountering new social representations, requirements are emerging and architecture is evolving. The key here is to implement first version of the software architecture and a working vertical slice. Team leader should focus on forming social representations about the goal, requirements and the architecture by referring to these artifacts only with one business related term, so that team can use common language about abstract, software-related concepts. If there are no architectural social representations forming, I suspect that software architecture is a mess.
You also might have have noticed how agile movement has formed it’s social representations about scrum master, product owner, pigs and chickens. Everyone shares common knowledge about these things but we all also have our own personal beliefs and experiences about the very same things. Other key element in the new project is to ensure that team members share somewhat compatible social representations about important things with each other and with the customer. If Scrum means different things to different people I would suspect team to encounter more surge during storming stage of group development.
Group norms
published March 26, 2010
Kari “Poppis” Suomela is a finnish polar explorer and today I had a privilege to participate to a seminar where he was speaking about his conquests to north and south pole. Only eleven others had skied to both poles unsupported and unassisted before him, so he is what I consider a “tough dude”.
In his speech he told one thing that was very interesting in terms of group norms. He told that before the trip, whole group undergoes same training program in order to avoid conflict later. Even though explorers all start from different levels, during training period each one is making a similar investment in terms of practicing. This way they can completely drop discussions about who cut training and who not while skiing on ice raft. According to Poppis, it is important that all unnecessary conflicts can be avoided.
So what are they actually doing in terms of social psychology? Firstly, They are increasing group cohesion by setting a bar high for members, which is one way to increase group cohesion. Group members will value membership more when their investment for a membership is high. Secondly, they are setting a group norm against whining, so that they can concentrate on important things.
Effective group norms are very important for technology teams also. For example, if group has not agreed on their values or definition of done, their process will be a mess which will cause unnecessary stress later in a project. If everyone have agreed that in order to mark task done, code has to be reviewed first, there will be much less whining because the team has established a norm for valuing high quality. This way it is much easier to succeed with code reviews and avoid situations where e.g. someone will not want to show his code. However, group must decide these norms by them selves and this will not work when norms are forced from outside.
For more information about polar exploring, go to www.thepole.fi
The roots of Alistair Cockburn’s Crystal methodologies
published February 17, 2010
I just finished reading Alistair Cockburn’s thesis People and methodologies in software development. I definitely recommend it for all people working with software and who are interested in software methodologies. Thesis raises important questions about group dynamics and I see a lot of interesting areas where social psychology could be applied. It also raises a question about the usefulness of software methodologies, as actual effect of a software process is in reality quite small compared to personnel factors in a small project (see Software Estimation by Steve McConnell) although importance of process increases as size of the software grows. As I said, highly recommended.
Implicit personality theory and Halo effect
published February 3, 2010
It is funny how we categorize people when we first meet them. We all have automatic cognitive processes which help us to process huge amount of information available to us. We associate particular behavior with our previous experiences and quite quickly decide what is this new person like when we meet her for the first time. This first impression is strengthened in our internal thinking later. So, getting the first impression right seems like an important thing.
In addition, if we find out that a person has one outstanding trait we have a tendency to associate other positive qualities for that person. This is called the Halo effect. For example in job interview you should look your best and try to really excel in some area.
Implicite personality theory on the other hand states that there are some traits when associated to a person will alter our general expectations about that person. A good example are words “cold” and “warm”. By describing a person intelligent, fast-paced and cold we will “freeze” the whole image. Suddenly “intelligent” does not sound same as it would if that person would be described as intelligent, fast-paced and warm. So it is not all the same how we describe a person, some words are more influential than others.
Older Posts »Subscribe to RSS feed
The Tag Cloud
Agile Business Coaching Coding horror Conference Customer Design of Experiments Future Group dynamics ITIL It should not be that hard Java EE Kanban Leadership Lean Liferay Methodologies Natural UI Performance tuning Process Productivity Quality Retrospective RIA Scrum Six Sigma Social psychology Software Software architecture Testing This is great TOGAF
WP Cumulus Flash tag cloud by Roy Tanck and Luke Morton requires Flash Player 9 or better.
Samuli's Links
The Blog Archive
February 2012 (1)
January 2012 (1)
November 2011 (1)
June 2011 (2)
May 2011 (1)
April 2011 (2)
March 2011 (2)
February 2011 (1)
January 2011 (1)
December 2010 (1)
November 2010 (1)
October 2010 (3)
September 2010 (3)
August 2010 (5)
July 2010 (2)
June 2010 (3)
May 2010 (4)
April 2010 (2)
March 2010 (6)
February 2010 (7)
January 2010 (3)
December 2009 (7)
November 2009 (6)
