The Blog
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
Women
published March 8, 2010
As today is the international women’s day, it seems like a proper time to say few words about women in IT projects. Unfortunately, it is not commonplace to have women participating software implementation in Finland. In most cases that I have worked with women, they have been working as project managers, testers or UI designers and only few have worked as software developers. What ever their role have been, their presence has brought positive effects to team dynamics. Do not get me wrong, I do not mind working with real sweaty Neanderthal-type men, but it feels like a fresh breeze to work through problems with opposite gender. That is why I wish to see more software-ladies with multi-tasking brains working with IT. Happy women’s day!
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.
Analysis of a successful project
published February 13, 2010
In a previous post I listed things that I consider important for a project to succeed. While writing the list, I constantly wondered how individual items are more of best practice, methodology and group dynamics related than expensive things you should buy.
A successful project must succeed in multiple areas. As seen on a picture below, there is no one magic bullet nor there is a one person making a successful project. It is a team effort and it will have to be started and managed accordingly.
In the picture above, there is an imaginary radar chart representing a project success on different categories. I think the items can be generalized into three categories: Execution, business and socials.
Execution contains actual implementation details, from methodology selection to coding, documentation and testing. Business contains business analysis, requirements, calculations for return of investment, end users and other constraints. Sosials contains hiring a team, assigning roles for it and managing group dynamics.
So how do I come into this picture?
I usually work with roles such as “Scrum master”, “Technical Project manager”, and “Technical lead” and find myself working in all three sectors.
For people working in similar roles, it important to manage your own time and not to concentrate too much on one category. By concentrating too much on one area, you will cause damage for others. In the end, the success of the project is completely dependent on the skills of the people doing the job.
Emotional contagion
published January 4, 2010
Did you know that emotions are contagious? Well, they are. How does this affect your job as a leader? Well, a lot. Generally, people transmit their feelings to one another, especially group leaders with high nonverbal expressiveness are likely to bring out emotions in others. Since it is also plausible that a pessimistic or a negatively toned group will dissolve over time, you as a leader, should pay close attention to your own feelings.
Personally I see pessimism and negativity always as a bad choice. It is not a sign of a solid leadership nor it is wanted personality on a working team. Since positive feelings are also contagious, why not to improve the mood of your work group by keeping up positive emotion?
The co-worker effect
published December 8, 2009
How many of you study on your free time? I do, but you only have so many hours in a day. This is where your active work environment and skilled co-workers come into play. If you are working for an employer that does not employ the best of the best you are not pushed to your limits. Adding the fact that equally skilled people tend to cluster, you are not growing as fast as you could if your co-workers are below average.
This brings us to an inner circle. Especially when leading, you need an excellent inner circle. Purpose of the inner circle is to bring the best out of you and to compensate on your weaknesses. In a return you help your inner circle members to fully reach their potential. Since an working inner circle is not built by accident and all good things are done together, you need to focus on building it.
That is why you should always aim to work with the best.
No early risers in your team?
published November 30, 2009
A Classic way of getting people in time for mornings scrums is to agree on penalty for being late. Sing a song or bring doughnuts, it can work. I just finished watching of a documentary about biological clocks. Program was about chronobiology that is a study of cyclic phenomenas in living organisms. According to documentary it is possible to shift your internal clock by decreasing light intake in the evenings and increasing it in the mornings. This way your biological clock will make it easier for you to get up early. No more spending money on Berliners, save it for Diesel shades and Philips wake-up light.
From norming to performing
published November 26, 2009
Bruce Tuckman’s small group theory “Forming, storming, norming and performing” is a group development model created in the 1960s. It tries to model group behavior and small group development while group is doing something e.g. solving a problem.
I have seen group development in action many times and while there are other theories, I think Tuckman’s model is close to what I have experienced. Somehow I just feel when a team enters the norming stage and especially when it enters the performing stage. In the early stages, it just feels that things could be done much, much better. In order to reach high performance state, it is critical to keep building the team day by day. Usually it will pay off and finally the team will knit together and function very well. Sometimes, unfortunately, the team will not reach performing stage.
It is a shame that performing stage is often reached close to the end of a project. This is why I feel it is effective to try to move whole team to a next project as a unit. They will automatically produce more value from the start of the next project as they have bypassed the forming and the storming stages earlier. Of course, it is not that simple that once a group has reached the performing stage, it will maintain it forever. A highly productive team may revert to storming in some cases.
Anyways, it is a very pleasant feeling to be a part of a high performance team.
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)
