Anders Laestadius

Anders Laestadius

Software craftsmanship

Ett upplägg för en heldags affärsplanering

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.

read more »

Team LiftOff with Market of Skills and Competence Matrix

Introduction

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.

read more »

Interview with Christopher Avery

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.

From therapy to continuous improvements

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.

read more »

Value driven meetings

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.

read more »

Turning the accountability upside down

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.

read more »

Congruent leadership

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.

read more »

Establishing the continuous improvement culture the incorrect way

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.

read more »

Stop using differentiated salaries

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.

read more »

Improving the Daily Scrum

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 structure of the scrum board
  • The process of how we perform the scrum meeting
  • The location of the scrum board and the meeting
  • The metric that we uses to monitor how we are improving the meeting

read more »

Establishing the first common product backlog

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.

read more »

Guest blogging at TV4 Digital Media

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 :-)

The Happiness metric and a few others

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.

  • The happiness and stress indexes tells you about the health of the team
  • The code duplication and test coverage tells you about the health of the code base
  • The release burn down and lead time tells you about the health of the project goal

read more »

Functional Java

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.

read more »

Steve Bockmans team estimation

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.

read more »

Improve your soft skills through physical challenges

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.

 

read more »

Journeyman seeking apprentice for coaching

 

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.

read more »

Future-spectives

 

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.

read more »

My first blog at Crisp

I’m new at Crisp and this is my first blog post (actually, my first blog post ever!). I thought that this could be a good time to give a short presentation of myself. I have 15 years of experience as a software developer in various roles. I worked the first nine years as a consultant at various companies and the last six years at St Jude Medical as an employee. During the years I have had different roles and responsibilities: programmer, architect, team leader/Scrum Master, manager etc. I love programming and to coach my co-workers to grow as both individuals and as professionals. I have a passion for agile development and I always try to use it’s value system wherever I work.
When I’m not working I spend my time with my family (wife and two kids), friends and training (swimming, cycling and running)
I think that you can get a good idea about people’s character by looking at what kind of books that they have in their bookshelves and their bedside tables. I thought that a good presentation of me could be to list the books that have influenced me the most during my career. So here they come, the books that I think has changed me as a professional since I started to work fifteen years ago.
1996: Advanced C++ Programming Styles and Idioms by Coplien
This was the book that opened my eyes for object orientation and C++. I was new in the profession and I didn’t really understand much about software development, but the book gave me some key insights into how to design object oriented software, and how to tame the C++ beast. It is like Scott Meyers writes in the foreword of his Effective C++, the book expands your mind!
1996: Design Patterns: Elements of Reusable Object-Oriented Software by Gamma et al
Like most people in the software industry I was really influenced by the first design pattern book. By reading the book and practicing the different patterns I have learned the value of structuring the code in small loosely coupled objects, and also the value of separating implementations with interfaces.
1997: Object-Oriented Software Construction by Meyer
This is the book that taught me Design by Contract, an extremely valuable methodology in software construction. The method helps you think through your design and implementation by stating contracts at both method and class levels, and it catches any deviations from the contracts during run time. Design by Contract is a good complement to test driven development, especially preconditions which makes the code more understandable and more maintainable.
1999: Extreme Programming explained: Embrace change by Beck
Kent Becks book about XP was a big turning point regarding how I thought software should be developed. Up to that point I had a keen interest in different processes and methodologies but all has been really heavy and complex. The simplicity of XP attracted me, and I saw the positive effect the engineering practices could have on software development. I have been a believer of the agile principles and its value system ever since.
2003: Agile Software Development, Principles, Patterns and Practices by Martin
Uncle Bob’s book taught me the SOLID principles which I have tried to follow thereafter. I had read the principles before I read the book but since I think these principles are a must in object oriented design I list the book here anyway.
2005: Toyota Way by Liker
This book about the Toyota Way was also a big turning point in my professional career. I understood the importance of creating a culture and environment that boost people’s creativity and lust for continuous improvements. Respecting people and to show belief in them is one of the best ways of achieving that. Most lean and agile implementations fails due to lack of understanding that the fundament is respect for people and a belief in that all employees are competent and willing to make decisions on complicated and complex matters.
2006: Domain Driven Design: Tackling Complexity in the Heart of Software by Evans
The ideas in Eric Evans book was in large not new to me, I had used domain oriented design for some years before. But domain driven design together with behavior driven development gave me a new set of collaboration patterns of how to organize and work in cross-functional teams. The teams that I have worked in that have implemented the two practices have shown it to be very effective and productive way of working. You avoid a lot of mistakes and rework if you make sure all stakeholders have equal understanding of what to do early, and that everybody has a shared view what to try to accomplish when implementing the feature.
2006: The Fifth Discipline: The Art & Practice of the Learning Organization by Senge
The Fifth Discipline was the first book I read about system thinking. Up to that point I could be quite detailed focused. By reading the book I learned the importance of having a systematic view of problems and to search for root problems instead of quick fixes. System thinking is also central in both Lean and Agile systems so the perspective attracted me a lot and has done so ever since. 
2006: Quality Software Management, Vol 3: Congruent Action by Weinberg
Weinberg has written a lot of really good books about software development and other topics. His third volume in the Quality Software Management series, congruent action, is about interpersonal collaboration and communication, and the complexity this brings you in any software development project with more than one participant. The book gave me tools in how to inspect and improve myself and also a realization that my point of view is not always shared by everybody else!
2006: Fearless change: Patterns for introducing New Ideas by Manns et al
I like the pattern format; it is structured in a very pedagogic way. Fearless change is a very nice book with a lot of useful patterns that is valuable when you coach people and tries to introduce changes. One really simple but powerful pattern described in the book is “Just Do It”, which is a pattern that I try to follow in my profession. It is better to try to do something and observe its outcome than trying to understand everything before you go ahead and implement it. 
2008: Managing the Design Factory by Reinertsen
Reinertsen has written a few really good books about project management and Managing the Design Factory is one of the best books I have read. The book describes product development using queuing, information and system theories. The book gave me a better understanding in these theories which also are fundamental in both Lean and Agile systems.
2009: Abolishing Performance Appraisals by Coens at al
I have had thoughts about the value of performance appraisals for a long time and I have grown an understanding of its negative impact on the organizational performance. This book by Coens and Jenkins gave me both theoretical ground and examples in that you if possible should avoid using appraisals. You gain far more in performance if you focus on creating an organization where people are safe to both succeed and fail without being afraid of low grades at the yearly appraisals, and to foster a culture of real peer-to-peer feedback instead of going through the managers.
2010: Coaching Agile teams by Adkins
Even though that this book didn’t change my current point of view as many of the other books listed here have done, I anyway need to include this book. Adkins book about Agile coaching is absolutely wonderful and a must for anyone trying to work as a team leader or manager in product development. I would even recommend this book for anyone working in Agile teams since we all are coaches to each other from time to time.
This was my background described from the list of books that have influenced my development at most. As can be seen I focused a lot on technical studying in the beginning of my career while the last years I have focused more on softer subjects. I still read a lot about programming and design, especially about all the latest interesting languages like Scala and Clojure, but I guess that it’s in the soft area that I have had the greatest gaps and therefore also greatest development during the last years.