Anders Laestadius

Vad är ett Agilt mindset och hur beskriver man det?

Det är en fråga jag fick finna svar på i och med det sista tillfället i Scrum Master programmet Mia Pilebro (agil coach på arbetsförmedlingen) och jag genomförde på Arbetsförmedlingen. Denna artikel beskriver den definition jag landade i, resonemanget bakom samt varför detta är viktigt då man förändrar en organisation mot en Agil kultur och arbetssätt. De definitioner jag hittade när jag sökte svar på frågan kändes inte kompletta, enligt mitt tycke. Efter diskussion med mina kollegor på Crisp, och med Mia, landade jag i en definition som består av ett antal påståenden, hållningar och en intention.

Mia Pilebro, agil coach på Arbetsförmedlingen, och jag, genomför ett Scrum Master program med deltagare från två av enheterna på arbetsförmedlingens IT-avdelning. Programmet innehåller sex träffar med en tvådagars workshop som inledning, fyra träffar, så kallade Learning Labs, varannan vecka, och till sist en avslutande heldag för gemensam reflektion och sammanfattning av programmet. Under den andra Learning Lab-träffen som vi hade för några veckor sedan jobbade vi kring grupputveckling; hur utvecklas en grupp från det att den bildas initialt tills det att den möjligtvis blivit en högpresterande enhet? Vad är det för mönster som visas i olika faser av gruppens utveckling, dvs vad är det för beteenden vi generellt kan uppmärksamma och hur kan man beskriva vad som tar gruppens fokus och energi? Dessutom tittade vi på hur ledarens agerande behöver förändras utifrån där gruppen befinner sig i sin utvecklingsresa. 

Mia och jag organiserar träffarna med korta teorigenomgångar blandat med gruppövningar för att skapa en bra miljö för lärande och utveckling. Vid detta tillfälle skapade vi en kortlek och spelplan utifrån Susan Wheelans forskning kring grupputveckling, hennes modell ”Integration Model of Group Development” (IMGD), som beskriver fem faser en grupp kan utvecklas genom:

1. Tillhörighet och trygghet
2. Opposition och konflikt
3. Tillit och Struktur
4. Arbete och produktivitet
5. Avslut

Då vi endast fokuserade på de fyra första faserna under vår träff innehåller spelplanen inte den sista avslutande fasen. 

Workshopen blev väldigt lyckad med både hög energinivå och ett bra lärande kring ämnet. Jag vill därför beskriva hur vi organiserade delen där gruppen fick arbeta kring grupputveckling med hjälp av kortleken vi skapade, och också dela materialet att använda hos era arbetsplatser. Länk till spelkort och spelplan finns längre ner i denna artikel. 

Jag utbildade mig nyligen till handledare för försvarshögskolans koncept Utvecklande Ledarskap (UL); fem mycket inspirerande och lärorika dagar. Förutom ny kunskap har jag dock också med mig upplevelsen kring kraften i grupputveckling när den blir som bäst. Under kursen satt och jobbade vi i kvarteret där vi både hjälpte varandra förstå kursinnehållet men också förberedde och genomförde en del av den normala UL-kursen inför övriga kursdeltagare. Det är fascinerande hur starkt relationerna inom en grupp kan utvecklas, och från det att en tydlig teameffekt kan växa fram, efter så kort tid som några få dagar. 

Det fick mig att fundera på vad det var som hände under kursen som gjorde detta möjligt. Vid reflektionen kring hur utbildningen var strukturerad, den miljö vi befann oss i, handledarnas agerande och vad vi gjorde i kvartetterna, landade jag i att nedanstående fyra aspekter hjälpte oss till att formeras till kraftfullt team under veckan som gick:

• fokus på att bygga en trygg miljö, 
• Vi hade väldigt tajta målsättningar att arbeta mot
• Det fanns möjligheten till frekvent feedback på de resultat vi skapade, samt vi gav varandra löpande feedback på varandras prestationer
• och vi var en liten och komplett gruppering som skulle lösa uppdraget tillsammans självständigt.

Anti-Agile är en av mina favoritövningar att facilitera vid uppdrag hos kund. Använder man denna övningen internt inom en organisation så synliggör man ofta många dysfunktioner som finns inom organisationen; kulturellt, strukturellt och hur man arbetar. Övningen fungerar också väldigt bra som en murbräcka i att bryta tron att allt fungerar så bra som det är, och föreställningen att vi är så agila som vi möjligen kan bli. Det senare är många gånger en utmaning då en stark föreställning om sin egna förträfflighet är ett stort hinder att ta sig över som coach för att få kunder att öppna upp sig för coaching och vägledning i sin arbetssituation. 

Inledning

Ser jag tillbaka på mina år som konsult och coach på Crisp har det skett en rätt stor förändring i vilka typer av uppdrag vi får. Många organisationer möter en allt mer föränderlig omvärld med snabbfotade kunder; är de inte nöjda med det utbud som organisationen levererar går det till en konkurrent i stället. Det räcker inte längre med att enskilda team fungerar bättre; hela organisationer behöver förbättras för att nödvändiga effekter skall skapas. 

För att lyckas med förändringsarbetet behöver vi:

• Utgå från att organisationer är komplexa system vilket kräver en organisk förändring snarare än ett plandrivet och mekaniskt sådan. 
• Genomför förändringen evolutionärt drivet genom de hinder som teamen upplever, 
• Successivt forma den struktur och arbetssätt som just den specifika organisationen bäst behöver för att leverera värde. 

One of the most exciting aspects of working as an Agile Coach is applying what we know to other industries. Especially when what we do serves the greater good. We’re both always actively looking for opportunities to work with integration initiatives, and in this case we supported an initiative to improve integration of newcomers. Here’s how we facilitated the 2018 kick off meeting for Järfälla municipality’s Interfaith Council.Continue reading

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.

Continue reading

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.

Continue reading

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

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.

Continue reading

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.

Continue reading

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.

Continue reading

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.

Continue reading

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.

Continue reading

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.

Continue reading

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

Continue reading

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.

Continue reading

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

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

Continue reading

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.

Continue reading

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.

Continue reading

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.

Continue reading

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.

Continue reading

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.

Continue reading