Nyligen så hjälpte jag till med att planera och facilitera en affärsplanering hos en kund. Då jag tycker både utfallet och genomförandet var väldigt bra så kommer här en beskrivning av vad vi gjorde och de olika övningar vi hade. Det var en relativt stor grupp som samlats föra att genomföra den årliga affärsplaneringen, vilket syftade till att utifrån företagets övergripande mål finna vad denna avdelning skall göra under året som kommer. Alla som varit med på dessa tillställningar vet att de kan vara rätt tunga och inte alltid kopplade till medarbetarnas vardag. Jag känner dock att detta tillfälle bröt traditionen, mycket på grund av att de aktuella cheferna fokuserade på att jobba kring det positiva och möjligheter i stället för problem och hinder.
Det var en grupp på 30 personer fördelade i två olika linjegrupper, och huvudmålet var att finna förändringsåtgärder för året som kommer. På vägen mot det målet, en väg som var lika viktig som slutmålet i sig, jobbade gruppen kring sin historia, arbetade fram en mission och sedan en framtidsbild om var de vill vara fem år framåt i tiden.
I got into agile development during the late 90s when I read Kent Beck’s book about extreme programming (XP). It was mostly the technical aspects of XP that attracted me; I liked test driven development and continuous integration and I understood the benefit of continuously reviewing the code by doing pair programming. It took some time for me to turn my attention to what I mainly focus on today, and what I see is a cornerstone of agile, teamwork. Product development is in most cases a complex endeavor where you need a high level of collaboration and teamwork to reach required outcome. To succeed you have to make sure the participants build on each others strength and knowledge, and where they see differences as something valuable and important. But it is not certain that all working groups ends up as a true team. As a team coach you need to pay attention to building the team at the beginning. This post will describe a few tools that I have used in order to form teams.
In April this year we had Christopher Avery at Crisp giving his two days workshop Creating Result Based Teams. I read Christopher’s book about creating effective teams a few years ago which I found very inspiring and it was loaded with a lot of wisdom about working with teams. I was therefore very excited to have him here in Sweden to give his workshop and help us improve the collaboration level in our teams. In his book and during this workshop, Christopher describes what he believes are the foundation of high performance teams; things like personal responsibility and trust just right. He also describes the outcome from a research he participated in during the 90th where they studied how personal responsibility is handled by the mind, the responsibility process. This and other things Christopher talks about in this interview I did with him during his stay here in April.
The workshop was very appreciated by the participants so we have Christopher back in Sweden now in November. You can find more here.
I had recently a conversation with a business partner of mine, Erik Andrén at Macmann Berg. We were working on the material for the next workshop in a leadership program we have at a client. This time the workshop was about coaching, both in general terms but also from an agile perspective. Erik has a background as a therapist but is nowadays working as an organization and management consultant. At our meeting he described his view about coaching based on a therapy model he had used as a therapist, and we then had a very interesting discussion about the model and the connection to continuous improvement of teams and organizations. This post discuss this connection since I believe we have a lot to learn from how therapists approaches patients when trying to help them create a better life for themselves.
Today at Crisp, we had a short discussion about effective meetings where I described what I think are needed in order to have successful meetings. Meetings, like work meetings, are used to produce some kind of result, achieve a agreed on decision or solve a problem. The discussion got me thinking about how often we are overloaded with meetings where many of them give little value back to the project and organization.
Paul Graham describes two different schedules, the manager and the makers schedule, where the former is run by managers working through the day participating in a lot of different meetings, and the latter is run by the workers, the developers and project participants, working through the day developing new versions of the product they are accountable for producing. These two schedules have their place in an organization, but we may get in trouble when the two schedules meet each other, which they do now and then during a normal working day.
Meetings cost quite a lot, and it is often not obvious for the managers working under the manager schedule how big that cost really is. I believe we need some kind of structure, an agreement between the meeting participants and the organizer of what they need to prepare and do before the meeting, in order to guarantee that it will be as efficient as possible. This to ensure that the organization get some kind of ROI from having the meeting.
I just finished working on a short presentation that I will give this week about agile and lean development. In the presentation I display a few quotes by Deming regarding management and the system perspective managers should have in their work. One of the quotes is the famous one stating that 94% of all improvement possibilities are in the system and only 6% by special cause (in other words, only 6% are caused by the individuals).
“I should estimate that in my experience most troubles and most possibilities for improvement add up to the proportions something like this: 94% belongs to the system (responsibility of management), 6% special”
This got me thinking about the 1-on-1 and performance review meetings that I have used at previous job positions, and of which I have written about before in this blog.
Every organization has its culture that you can see when you observe people at their daily work. This observed culture should be aligned with, or congruent to, the official organizational culture. In reality there is often a gap between the intended culture and the real observed one. For example, management might say that quality is above everything else, while pushing to release new versions of low quality product riddled with defects. Or an organization touts its focus on learning and removing impediments, while the reality is the complete opposite. This post discusses the impact and importance of cultural alignment.