Thursday, December 10, 2009

Last week and Situational Leadership II

What I've been doing, almost exclusively, for the past 2 years is to help various IT teams here in Iceland make the leap to becoming agile IT teams, and their departments to become agile departments. The way in which I have been doing that is to work with each team for at least 5 weeks, in a program we've developed at Sprettur Marimo called Agile Jumpstart.

Anyway, just last week we hosted the biggest series of events in our company's short history where we sandwiched our AGILIS 2009 conference with, first a CSM class with Alistair Cockburn and then a CPO class with Jeff Patton. The whole week was as a smashing success, as my partner Petur Orri likes to say, and we are all very thankful and proud that so many people came to get excited about Agile and Lean.

Finally, the preamble is over and I can get to my point. I was talking to Jeff Patton about the way we structure our Agile Jumpstart package and that we use Ken Blanchard's Situational Leadership II (SL II from here on) model to vary our coaching style through these 5 weeks. He found it interesting and told me he'd 'steal' that idea (I hope you do, Jeff!), so I thought I'd share it with you as well.

The SL II model is really quite simple. It aims to guide leaders (teachers, coaches, ...) to pick the right style to lead with based on the learning needs of the people being lead, so to speak. To read more details about it check my link above or Google. The way I employ SL II in our Agile Jumpstarts is to start by informing the team I'm working with, that this is a way I've found to be effective when working with teams, and if they have no strong objections I'll do that with them as well. This is very important - I have forgotten to do this and it's not good.

Consequently, using this model I start out with a Directing style. This is at the beginning when I'm helping the team get started with Scrum. It means I train them, and direct them through a series of facilitated sessions to bootstrap their process as well as directing them through much of their first sprint.

Next, I go to a Coaching style, and work closely with the Scrum Master and Product Owner while they get used to leading and facilitating the process. Here I'll be less directive and the Scrum Master takes on most of the facilitation that I did to begin with. I give the Whole team high support and provide them with the safety they need to do the process work themselves, but I try to facilitate a lot less.

Third, is the Supporting style where I don't facilitate at all, I'm just observing and supporting the team. I answer questions of course (and ask some of my own), but at this point I'm getting ready to leave the team to itself, so the less I do (or need to do) the better I feel about leaving.

Fourth, is the Delegating style, and many cases this just means I move on to another engagement at another company. In other instances, where I'm coaching many teams at one company I can be reached and consulted with, but effectively I'm off the case!

The past year or so we have been using this model we've been really happy with it and it seems to make a lot of sense to people that we coach. Obviously, it's not always as cut and dried as this linear description of mine seems to suggest, but having the model is very helpful and I'd recommend people take a look at it if they are in any sort of leadership position in their lives.

10.12.2009 | Comments [0]
Flokkur: Coaching
Höfundur: Daði Ingólfsson

Monday, November 09, 2009

Introduction to the Core - Core Series Part 1

We have been implementing the idea of a working agreement within teams when we do Scrum consulting. The team develops a list of principles which the team members agree not to break. Popular principles include things like "Respect each other", "Don't be late" and "Say what you think". The working agreement defines a social contract that help people work together. When I was introduced to the idea of a working agreement I immediately liked it since I saw it as a good way for team members to connect better with each other. But that was about it.

More than 6 months ago my Sprettur partner Daði introduced us to the Core by sending a video featuring Jim McCarthy from Agile 2008. I found out that the Core is a system to support a shared vision within a team. It is a working agreement that has been in development for over 10 years and is in version 3.02. Listening to Jim talk about the Core made me realize that the working agreement is the most important aspect of teamwork because it supports a shared vision (even more important than the right development method :) ). I already knew that a shared vision is crucial if a team is to succeed but always had vague ideas about how to get there.

We, the Sprettur guys, have now been using the Core for 6 months now and its power is amazing. Always when we run into trouble in our teamwork it's because we are not using the Core enough or we find out we didn't fully understand how to use it. The Core is so powerful that I have started using it at home with my family :)

The Core defines 11 commitments and 11 protocols. The commitments are similar to the working agreement discussed before but the protocols are procedures to support the keeping of the commitments (more on the protocols later). Following are the 11 commitments which should be read "I promise, X ":

I commit to engage when present.
I will seek to perceive more than I seek to be perceived.
I will use teams, especially when undertaking difficult tasks.
I will speak always and only when I believe it will improve the general results/effort ratio.
I will offer and accept only rational, results-oriented behavior and communication.
I will disengage from less productive situations
I will do now what must be done eventually and can effectively be done now.
I will seek to move forward toward a particular goal, by biasing my behavior toward action.
I will use the Core Protocols (or better) when applicable.
I will neither harm—nor tolerate the harming of—anyone for his or her fidelity to these commitments.
I will never do anything dumb on purpose.

In this series I will go through all the commitments and the protocols and describe how we, the Sprettur guys, have been using them and failing with them.

09.11.2009 | Comments [0]
Flokkur: Agile | The Core
Höfundur: Pétur Orri Sæmundsen

Tuesday, October 20, 2009

Managing energy, audiobooks and fractured ribs

One of the best things that resulted from my founding of Sprettur a couple of years ago, was that I learned a thing or two about the importance of continuing learning and acquiring new knowledge. A part of that is that we listen to audiobooks quite a bit. As a result, I've listened to 18 audiobooks, most of them with a management or business related focus. A couple of those books have influenced me deeply, the last one to do so is "The Power of Full Engagement" by Jim Loehr and Tony Schwartz.
The subtitle of the book says a lot about its content, which is "Managing Energy, Not Time, Is the Key to High Performance and Personal Renewal". For me, this is turning out to be a very fundamental paradigm shift, as I have been focused on time and project management practices, both on the personal level, such as Getting Things Done, and of course all the Agile processes, such as Scrum. The revelation for me, is that as good as those processes and practices are, the chances are that managing your time better is not what you really need.

It so happened that just over a month ago, I had a little accident and fractured a rib. A friend of mine which had a similar injury not so long ago, told me that week number three would be the worst, apart from the first few days of course. This turned out to be pretty accurate, I was able to attend work until about three weeks after my accident, that I simply had to go home around noon, as I was completely drained of energy. It just so happened that I had downloaded this book the day before, and decided to start listening to it.

One of the statements made in this book, which is common sense when you hear it, but obviously something whose importance is easily forgotten, is that we get our energy from two sources. The food we eat AND the air we breathe. It is this latter half that we apparently take too much for granted, and rarely think about. Now, even with a fractured rib which affects your breathing significantly, I did not think much about breathing (other than how painful it was to take a deep breath) until reading this sentence. And it hit me, that I was obviously taking unnaturally shallow breaths due to the fractured rib, and that was a probable cause of my fatigue. So I decided to experiment with this on myself, and perform a simple breathing exercise described in the book for the rest of the day and the next day. The results were pretty dramatic for me. Not only did I last easily at work until 7pm the next day, but the fatigue I had experienced the last days before was completely gone.

The issue I had was apparently that the pain associated with breathing with a fractured rib leads to shallower breathing than is normal, leading to drained energy and fatigue. As soon as I realized the problem, and performed a simple breathing exercise a few times a day (take a deep breath and exhale slowly, repeat a few times over a minute), the problem vanished. This result is quite dramatic, which could become my fortune, because this is a lesson I will never forget. I fully believe that the benefit for healthy people is substantial as well, simply from conscious breathing.

Apart from the breathing, there are a lot of good advice regarding proper diet habits, physical and mental exercise, rest and recovery which I am starting to implement. Although a bit early, I am going to say that my energy levels are now (after only 2 weeks of doing this) at the highest level they've been in years, leading to more willingness to do things and higher productivity. I trace this mostly to this book, and I would like to encourage everyone to read it. And, although not much time has passed, and other factors are influencing me, I feel that the results from this paradigm shift are so great, that I will continue to consider this book the most influential I've read, so far.

- Guðlaugur Egilsson

Here is my top 10 list of audiobooks, ranked by the place the have in my mind at the moment.

The Power of Full Engagement Jim Loehr and Tony Schwartz
How We Decide (Unabridged) Part 1 Jonah Lehrer
The 7 Habits of Highly Effective People (Unabridged), Part 1 Stephen R. Covey
The Future of Management (Unabridged) Gary Hamel, Bill Breen
Outliers (Unabridged) Malcolm Gladwell
Beyond the Goal (Unabridged) Eliyahu M. Goldratt
Getting Things Done (Unabridged) David Allen
How to Win Friends & Influence People (Unabridged) Dale Carnegie
Tuned In (Unabridged) Craig Stull, Phil Myers, David Meerman Scott
The 8th Habit (Unabridged), Part 1 Stephen R. Covey

And the other 8:

Rethink (Unabridged) Ric Merrifield
What Got You Here Won't Get You There (Unabridged), Part 1 Marshall Goldsmith and Mark Reiter
Dumb Money (Unabridged) Daniel Gross
The Audacity of Hope Barack Obama
Crucial Conversations Kerry Patterson, Joseph Grenny, Ron McMillan, and Al Switzler
Lean Solutions James P. Womack and Daniel T. Jones
Made to Stick (Unabridged) Chip Heath and Dan Heath
The E-Myth Revisited (Unabridged) Michael E. Gerber

20.10.2009 | Comments [0]
Flokkur:
Höfundur: Guðlaugur Stefán Egilsson

Saturday, October 17, 2009

Orkustjórnun, hljóðbækur og brákuð rif

Eitt af því besta sem gerðist fyrir mig þegar ég stofnaði Sprett með félögum mínum, var að ég lærði ýmislegt af félögum mínum um mikilvægi þess að halda áfram að læra og tileinka sér nýja þekkingu. Hluti af því er að við hlustum mikið á hljóðbækur, og hef ég núna hlustað á 18 slíkar, lang flestar með stjórnunarlega eða viðskiptatengda vinkla. Nokkrar af þessum bókum hafa haft mikil áhrif á mig, núna síðast "The Power of Full Engagement" eftir Jim Loehr og Tony Schwartz. Útgangspunktur þessarar bókar er að lykillinn að velgengni og hamingju í lífinu, sé meðvituð og góð stjórnun á nýtingu og endurnýjun á persónulegri orku, frekar heldur en tímastjórnun, sem er þessi hefðbundna sýn, og sú sem ég var alltaf að reyna að vinna eftir.

Það vildi svo til að ég lenti í því fyrir rúmum mánuði að bráka í mér rifbein. Félagi minn sem lenti í því sama ekki fyrir löngu síðan, hafði sagt mér að vika þrjú væri verst, fyrir utan fyrstu dagana, svona þegar þetta væri að skríða saman. Þetta gekk nokkuð vel eftir. Það gekk alveg þokkalega að sinna vinnu fram að því að rétt tæpum þrem vikum eftir brotið var ég farinn að vera verulega þreyttur, og kom að því að ég entist ekki nema hálfan daginn, og varð að fara heim, alveg búinn á því. Það vildi svo til að þennan dag byrjaði ég á því að hlusta á þessa bók.

Eitt af því sem þeir segja í þessari bók, sem er augljós sannleikur þegar maður heyrir hann, en greinilega eitthvað sem menn eiga auðvelt með að gleyma, er að við fáum orku okkar úr tveimur áttum. Matur og drykkur sem við borðum, og súrefni sem við öndum að okkur. Það er þetta síðara sem við tökum sem of sjálfsögðum hlut, og hugsum nánast aldrei út í. Þetta fékk mig til að hugleiða stöðuna sem ég var í, örþreyttur að fara heim um miðjan dag, þó lógískt séð ætti ég í raun að vera í betra standi heldur en vikuna á undan. Ég ákvað því að gera tilraun á mér, og gera öndunaræfingar eins og lýst er í þessari bók, það sem eftir var dags og næsta dag. Og árangurinn var mjög dramatískur. Ekki eingöngu entist ég til 7 daginn eftir á löngum og ströngum degi, heldur bar ekkert á þreytueinkennum eftir þetta.

Málið þarna er nokkuð augljóslega það að sársauki vegna rifbeinsbrots verður til þess að maður andar grynnra heldur en eðlilegt er, sem veldur síðan orkuleysi og þreytu. Um leið og maður gerir sér grein fyrir vandamálinu, og gerir einfaldar öndunaræfingar nokkrum sinnum á dag (anda djúpt að sér og hægt frá, endurtaka 2-3 sinnum á einni mínútu), þá hverfur vandamálið. Árangurinn við ofangreindar aðstæður er mjög dramatískur, og það gæti orðið mín heppni því ég mun aldrei gleyma þessu. Árangurinn fyrir fullfrískt fólk er umtalsverður líka, bara af því að anda meðvitað.

Fyrir utan þetta hef ég reynt að fara eftir öðrum ráðleggingum í þessari bók varðandi mataræði, öndun, líkamlega og andlega þjálfun og hvíld, og ég held að ég leyfi mér að segja að orkustigið hjá mér og vilji og löngun til allra verka sé nú þegar (2 vikum síðar) orðinn hærri heldur hann hefur verið í mörg ár. Ég rek það að mestu leyti til lestur þessarar bókar, og hvet ég því alla sem ég hitti núna til að lesa þessa bók. Það er að vísu stutt síðan ég las hana, en árangurinn hingað til lofar það góðu, að ég býst fastlega við að þessa bók muni ég í framtíðinni álíta sem þá af þessum bókum hér að neðan, sem mest hafði áhrif á mig.

- Guðlaugur Egilsson

Til gamans er hérna topp 10 listinn minn af hljóðbókum sem ég hef hlustað á:

The Power of Full Engagement Jim Loehr and Tony Schwartz
How We Decide (Unabridged) Part 1 Jonah Lehrer
The 7 Habits of Highly Effective People (Unabridged), Part 1 Stephen R. Covey
The Future of Management (Unabridged) Gary Hamel, Bill Breen
Outliers (Unabridged) Malcolm Gladwell
Beyond the Goal (Unabridged) Eliyahu M. Goldratt
Getting Things Done (Unabridged) David Allen
How to Win Friends & Influence People (Unabridged) Dale Carnegie
Tuned In (Unabridged) Craig Stull, Phil Myers, David Meerman Scott
The 8th Habit (Unabridged), Part 1 Stephen R. Covey

Aðrar hljóðbækur sem ég hef hlustað á (óraðað):

Rethink (Unabridged) Ric Merrifield
What Got You Here Won't Get You There (Unabridged), Part 1 Marshall Goldsmith and Mark Reiter
Dumb Money (Unabridged) Daniel Gross
The Audacity of Hope Barack Obama
Crucial Conversations Kerry Patterson, Joseph Grenny, Ron McMillan, and Al Switzler
Lean Solutions James P. Womack and Daniel T. Jones
Made to Stick (Unabridged) Chip Heath and Dan Heath
The E-Myth Revisited (Unabridged) Michael E. Gerber

17.10.2009 | Comments [0]
Flokkur:
Höfundur: Guðlaugur Stefán Egilsson

Friday, October 02, 2009

Lessons learnt the hard way

I just got off a large project that one of our customers is running. I will not go into details but it should suffice to say that it is a rather large multi-phase project that is supposed to create the future IT backbone for that customer. Before I move on I though I should stop and analyze what we did right, what went wrong and what can I learn from this experience. And I thought I would share it with you dear reader ;)

1. Deploy by the end of the first month to a user
In large companies there are usually many reasons why a project cannot be deployed: dependency on another project which in turn depends on another project and so on, or someone has to get legal approval for something to be released. Yes, there are many excuses not to deploy, but in the end that's all they are - excuses. The business needs to see value, your team needs to get feedback from real users about the system otherwise you are risking building something no one is interested in and/or the business people loosing their business patience. My future rule of thumb would be - if you have not deployed to actual users by the end of the first month of the project, you need to do get angry and demand this to happen right away.

2. Do not accumulate technical debt, push back on Product Owner who does not understand technical debt
Technical debt(from here on referred to as tech-debt) is hard to explain to product owners that have not programmed. This is understandable and there is no easy way around it. We tried all kinds of metaphors but I don't think we succeeded in communicating what tech-debt is and why it is important. The best approach that I can see working is to negotiate a slice of each sprint to go into paying off tech-debt and demand extra on top of that at the first sign of trouble. Letting it pile and telling yourself that it is ok, that you are going to fix it "later" does not work. Never has, not for me. "Later" the debt is usually so big and the bad stuff has usually spread all over the place and fixing it becomes an all-or-nothing mini-rewrites that are very hard to do and are rather unpleasant and unsatisfying experiences.

3. Do not allow architectural astronauts to tell you what tools to use
It is a strange phenomenon but seems quite persistent: a company becomes mid-sized and someone decides that now they need to unify "how we do things around here". And then an Architect (may be even Chief Architect) is appointed who starts googling and creating a list of tools and technologies allowed to be used. And this is the moment when you start to be told what tools to use to do your job by the guy who has never done your job or it has been a while since he has last done your job. Do not let this happen, say "no" to company politics and demand that you decide what tools to use. The list of tools should be coming from you and the rest of the guys that are working in your organization. Architects can be valuable, but this is not the way. Do not buy into tool vendors based on power point presentations and one day carefully orchestrated demos from the salesman. You and your peers should be making the standard in your company. 'nough said.

4. Manage expectations so that they are achievable
I have come to appreciate marketing as a *very* important aspect of product development. The same product may be perceived as two complete opposites depending on how its being marketed. One thing that I've found out is not wise, is to proclaim that your product will be a universal panacea that will fix all there is to fix. This might sound obvious and plain common sense, but I am mentioning it for a reason: the larger the promise you make, the more difficult is to keep it. So I would advise to do small achievable projects and build software products incrementally and iteratively. And the product owners have always to be on the lookout how to generate value with minimum effort.

Well, I am off to the new project ... ;)

02.10.2009 | Comments [0]
Flokkur: Agile | Forritun | Scrum | XP
Höfundur: Petar Shomov

Wednesday, March 04, 2009

Soft as in "Software" - Part III (Dependency Injection for the CEO)

In part I of this series I set the stage by introducing angry management/businessy types that feel like being ripped off with this IT stuff but out of peer pressure or what not they keep pouring money into software. In part II I looked at what I believed to be the top reason for the customer dissatisfaction: the fear of change. In this last part of the series I will look at a few of the techniques we at Sprettur believe to be the cure. For the sake of the complete picture I am going to say that we truly believe that the SOLID principles and the XP practices are the way to go, but trying to discuss all of them would make this line of posting very, very long.

So, let's say you are this guy with the solid base to lean on, what do you do next to stop your software from corroding? A few ideas: Dependency Injection, Separation Of Concerns, Domain-Driven Design. I will very quickly go over these and how they can help you, if you are interested just google for any of these and you will get a lot more info.

Dependency Injection allows your code to stick less. Non-sticking code has two benefits: 1) allows the good pieces of your code not to stick to the rotting ones; 2) when you try to take one piece of code and reuse it, it will not make you drag in a whole bunch of other pieces for it to work.

Wow, I guess I can call this explanation "Dependency Injection for the CEO" ;)

Next is Separation of Concerns. What that refers to is when you chop your software up in small pieces based on the granularity of the tasks they accomplish, and then combine the small pieces into bigger clusters to achieve new or bigger tasks. This way the rotting pieces will be separate from the good ones and it will be easy to replace them with "fresh" ones as needed.

There you have it - "Separation of Concerns for the CEO".

Now for the underdog, Domain-Driven Design. Domain-Driven Design (DDD) is not as hot as "agile" but it is gaining a lot in popularity lately. DDD has numerous benefits, but I am only going to look at how it can help your software deteriorate less. The core idea of this school of thought is that you should separate the core logic that makes your business run, from the infrastructure and APIs. I guess you can call it the ultimate anti-corroding technique, but that is the punch line of DDD - recognizing that the business logic far outlives IT infrastructure and therefore we should take extra special care of it, so it will keep delivering value long after cool and hip fades away.

I will try to summarize in a sentence or two. It seems to me that IT has not really proven to be delivering high value and I put blame for that on the Waterfall model and inadequate software quality. We have the knowledge and the tools to solve both problems so we should try to get them to the developers and managers out there. In practice that's what we do at Sprettur.

04.03.2009 | Comments [0]
Flokkur:
Höfundur: Petar Shomov

Aðalvalmynd

Forsíða

sprettur.is

Agile hópurinn

Agile smagile!

Er blogg um Agile, stjórnun, tækni, forritun, gæðamál, fyrirtækjarekstur og fleira sem okkur langar til að skrifa um.

Leit á vefsvæðinu

Eldri færslur

January 2010

Sun

Mon

Tue

Wed

Thu

Fri

Sat