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.
Continuous improvement is a central part of both agile and lean; it’s the way to increase the productivity and ensure that the organization delivers an ever increasing level of value to the customers and the organization. Lean is derived from Toyota and the Toyota Way, which has inspired a lot of companies in the western world in their quest to increase their productivity as well. But we often focuse on the techniques and practices and do not see the more fundamental parts of the Toyota system that enable their very high level of improvement each year.
I worked at a company that tried to implement the Toyota Way and reach the same level of continuous improvment with what I believe to be the wrong focus. My company estblished a goal to reach seven improvements per employee in average per year. A goal that was inspired from a report that stated that Toyota implemented 1,000,000 improvements per year, which of course, is very high. This is one of many aspects that show why Toyota has managed to grow they way they have done during the last 50 years.
Most companies today uses differentiated salaries for their employees. This is something that is in general considered to be the way it must be; the companies needs the system in order to attract and keep talent employees to secure future profits for the business. This was also my belief until a few years ago; I thought that companies should pay more to the ones that produce more value to the business. Even if I saw cases where I thought people got too big salary increases and others too low at the annual salary review, I believed that in the long run the salaries would reflect the true values of each employee.
But during the last few years I have started to think differently. I do not believe in differentiated salaries any more, at least not for knowledge work like product development. There is too much evidence that the system you need to have in order to enable salary reviews each year, is impeding the progress of the business and lowers its result and profit. Knowledge work is based around motivated employees that have the support and environment they need to be creative during their daily work. Appraisals system, which is needed to implement differentiated salaries, is demotivating for the employees instead, and is therefore working against the high performance of the organization. Also, differentiated salaries is created under the belief that it is external motivations that drive people to be high performers, but as Pink describes in his book, Drive, it is autonomy, mastery and purpose that motivates people, i.e. intrinsic aspects instead.
This is also like Dr. Deming says in his book Out of the Crisis:
Evaluation of performance, merit rating, or annual review… The idea of a merit rating is alluring. the sound of the words captivates the imagination: pay for what you get; get what you pay for; motivate people to do their best, for their own good. The effect is exactly the opposite of what the words promise
My own experiencealign to this as well, both as an employee and as a manager, where I personally have witnessed the negative effect the system has had on its people and the company.
Doing the same thing every day for a long time can get boring. You might even forget why you started doing it in the first place; you just keep doing the same thing, and don’t reflect on what you are getting out of it. The scrum meeting at my current client had gotten into this rut, it had devolved into a status meeting. The participants routinely answered the three questions; what I did yesterday, what I’m going to do today and what impediments I have, but they didn’t really tell each other much about what they had actually done, or what they were planning to do today. They almost never reported any impediments either.
This team has been using Scrum for almost two years. It is a very well working team from a technical perspective; they produced an even amount of user stories each sprint with a high level of quality. But they had lost the energy in the scrum implementation. They felt that they could do more; that they could perform even better if they just could just somehow improve their scrum implementation.
We started working on the daily scrum meeting. Our goal was to use the meeting to give the team a good start to the day with energy and desire to start working on the tasks discussed during the meeting. In order to do this we made a few changes, both large and small in how we perform the meeting.
The past few days at my current coaching assignment have been great. We created a new backlog for all work they need to accomplish in the months ahead. The meetings where we laid the foundation for the future were marked by a high degree of collaboration between the participants and energy. It has been really fun to work with them so far.
I have just, as a guest blogger, posted a new post at the blog owned by the development team at TV4 Digital Media; “Några övningar vi gjort under retrospektiven”. It´s a post, in swedish, describing a few retrospective exercises we have done during the last sprints.
I’m contracted by TV4 Digial Media as an Agile coach to help them improve the collaboration, both in the development team as well as between them and the business side. It is very fun that they let my write a post as a guest blogger
There’s a lot that could be said about metrics. I’m quite skeptical in general in the value metrics gives you in product development or running a department/organization. At the same time I feel that metrics could help you understand the health and status of your group/organization or project, and to know the effects the changes you implement have on the performance. During the years I have used a lot of different software metrics, both targeting the product development performance and the code and design quality. Most of them have been quite complex, and they have in reality given me little value or understanding of how things really are working.
But I have also used a few ones that I feel has helped me see things during product development, metrics that says something about the performance and also direct you to possible improvement areas. Below I briefly describe a few ones that I like.
I have just finished reading a neat little book about functional programming for Java developers by Dean Wampler. The book is only sixty pages long so it’s a really fast reading. This is a book for Java programmers and others working in the object oriented paradigm that haven’t read about or done any functional programming before. If that fits you then this book may be a good choice to read. Otherwise, I recommend that you seek more advanced and in-depth books in the subject instead. But this text will not be a review of the book. I will instead comment on the use of the functional structure and its paradigm in languages like Java that is not designed for it.
Estimation of the effort to implement and deliver a set of functionality is an important but not always the most fun part of product development. Estimations are done at different detail levels during the project, for example the high level story estimation and the low level task estimation. It is a few years since I did task estimation; many times it is a waste of time doing low level estimations, so in the following text I will describe a technique that I like when estimating the user stories.
It is important to have members with excellent technical skills in most agile projects to succeed deliver desired customer value. But even more important is that the members have great collaborative and communication skills. Without the ability to collaborate efficiently the team will have a tough time to succeed with the project. The soft part of product development includes both how the members act against each other, but also how good they all are in introspectiveness and adaptability. They need this to be able to mature as a team compared to just being a bunch of individuals acting under a common project hat.
There are many ways you can improve your ability to inspect your own behavior and adapt and change it accordingly. Working together with others and asking them to give you feedback is one great way of improving yourselves. Last year I found, a bit surprisingly, another way of improving my skills in collaboration and team work; I took on a personal sport challenge with the goal to perform a race one year ahead. This challenge has learned me a lot about myself and has also improved my collaboration skills.
When I started to work as a freshly graduated computer scientist in the mid-nineties I was immediately assigned to a project programming C++. I certainly did my best to implement the functionality with the best quality I could manage to produce, but when thinking back to it, it is no surprise that the result was not very good, the code was actually quite bad. This was pre-XP and Agile time; pair-programming was not widely used and in the first couple of projects we didn’t even code review our code before delivery. Luckily I read a lot of books and articles and studied code examples written by gurus in the field, and after a while I got a good feeling of how to organize and designing the code in order to make it maintainable. What I really would have liked to have during this time was guidance from an experienced programmer helping me to improve my coding skills.
I’m a big fan of the software craftsmanship movement; software development is a craft and you need to practice continuously in order to deliver quality software and customer value. I see myself as a journeyman who steadily is gaining new knowledge and experience in how to implement software. I read a lot to get new input and I practice my coding skills as much as possible beside my ordinary programming assignments. So in the spirit of craftsmanship I would like to give an apprentice, someone new in the profession, some guidance that I myself would have loved getting during my first year as a software developer.
The concept of retrospectives is well established in the agile community as the way to incrementally improve your processes and the way the team members collaborate during their work. The idea is that by regularly looking back at the past period you may find improvement that will increase the productivity and delivered value.
This concept can also be used in other contexts, for example during a project kick-off at the start of a new project and team. To get the team on track and up to speed quickly it is important that the forming process starts out nicely and that the team learns how to collaborate and get focus on their work. Iterative processes with short iteration lengths helps out here in that the team needs to get focused in order to have a successful delivery after the first iteration. But you can also help out by establishing a common goal and vision for the team immediately at the start of the project. This common goal could help the team establish better collaboration and communication patterns as well as good process and engineering practices from start that will kick-start the project. And to establish that goal you could run a retrospective from the future, a future-spective.