Not Even Wrong – Wheelan, Integral Theory and the evolution of organizations

October 2014
Stockholm – Papas Deli

Perhaps you have, quite like me, felt the frustration of observing group behavior through the lens of the IMGD model of Susan Wheelan. How does one go about establishing which phase a group is in, when the group does not have a voice, but consist rather of a multitude of voices, which can with varying degree of sophistication express their own understanding of where the group is at in terms of “stages” of group development. Sure, you can asses this from the outside, looking at actual behavior and listen in to how the group interact and solve problems, but the challenge remains.

So then perhaps you have, as I have, come to terms with the fact that the answer to the question “which stage is the group at when the separate individuals behave in ways that are congruent with different stages” is that the group can be at several levels simultaneously and that individuals and the whole group can move between the stages depending on time, situation and context.

This is fine, the model is still very useful. It is actually the tension between individuals at different stages that create the conflicts that need to be resolved in a amicable manner in order for the whole group to evolve.

The tricky part here is that people in different stages have different way of dealing with conflict and tension. This then, is the challenge of group development. And this is what makes it so hard, yet so rewarding when it finally falls into place.

With this background established, we move on to Integral Theory, which – as Frederic Laloux demonstrated rather convincingly in his wonderful achievement “Reinventing Organizations” – is a rather useful model to explain the evolution of organizations.

When we talk about evolutionary stages of organizations, we can make a similar observation to the one we did when discussing IMGD. Different individuals, or even whole departments, can be in different evolutionary stages at the same time, within the same organization. This too creates tension and conflict, and this too needs to be resolved in an intelligent way. Anyone who has ever tried to promote Agile/Lean values and thinking beyond the “software department” understands how challenging this can be.

Even though this is a rather banal realization, as any model that proposes defined stages of evolution or development will have these issues hard coded within the very structure of the model, I have found it a valuable thinking tool.

If we turn now to John Hagels “Passionate Explorers”, the wonderful “Rebels at Work”, or any other description of progressive change agents, we know that the frustrations that these pioneers experience are very real. Many of us have felt or feel that we bang our head hopelessly against the unmoving concrete walls of “the old ways”. The fact that the departments or people in the organization that belong to a “lower” evolutionary stage still pay lip service to the ways and values of the “higher” evolutionary level (because it’s fashionable, you see) well that just makes it even more difficult.

The only way I know how to make people aware of when they’re not living their own espoused theory is to expose them to this reality, and this might not be pleasant conversations to have. Or even more troublesome, these conversation are often hindered by they way organizations are structured. This is precisely why successful change initiatives are almost always initiated at “the bottom”, but most certainly need the involvement of “the top” in order to succeed. We must not underestimate the cultural influence of an executive whose ideas and values belong to a “lower” evolutionary stage of organizational development.

In my experience, getting people used to the idea that there can be no action without theory, is a good start. You DO behave certain ways because you DO have theories about the nature of things, be it people (theory X / theory Y) or Organizations, leadership, management, purpose of organizations and business. These theories might not be known to even yourself – which is why reflection,  introspection and self-leadership must be promoted.

As always,the journey starts with someone taking the leap, and kickstarts the spiral of openness and trust.

Earlier post on Not even Wrong

Not Even Wrong – Thoughts on levels of abstraction

October 2014
London – The Hoxton

I have at times been accused of “being too logical” in my thinking, not allowing for other world views than the logical one. I can understand why such accusations exist, yet I am not entirely sure that those who claim that my disposition lean too much towards logic quite understand logic. I suspect at times that when they say “logic”, they mean “think”, with the opposite being “feel”.

I suspect that this is said by people who in their minds feel that they place higher faith in “intuition” than they believe that I do. With your permission, I will float my intuitive idea that several of these appeals towards the intuitive that I’ve come across have been nothing less than under-the-surface accusations leveled towards me to mask sloppy thinking.

I have on occasion found myself in situations where ideas have slipped through bouts of prioritization and ended up existing in my world as “a thing we’re doing”, and on examination the people behind these ideas cannot really explain what the idea means. And it follows then, that these people lack a shared understanding of what it actually is that they’ve prioritized. And yet, they still managed to prioritize this idea above all other ideas. And when I say that they cannot explain their own idea, I’m not talking about granular details of how the proposed idea might work. I’m talking about a lack of really high level understanding, as in: IF we do X THEN we believe Y will happen AND that outcome is desirable to us because Z.

If you cannot clarify at least this much inside your own head, then you cannot really make an informed decision about it. Perhaps, one might argue, it is the problem that the proposed idea is assumed to solve that is really being prioritized? If that was so, I would be happy as a clam. But I fear we’re not so lucky.

Could it be that a proposed solution to a problem is necessary in some quarters in order to explain and understand the problem itself? In some weird sense, that would be like a wonderful new version of backcasting, which could probably be a fun way to generate ideas. But alas, I’m pretty sure that’s not what’s going on.

This forces the question: which level of abstraction are you comfortable dealing with? What would make sense to me would be to make a full stop with the prioritization of ideas at the highest level of abstraction and start prioritizing problems we want to solve. Or, if you’d rather work from another angle, prioritize the outcomes we want to reach.

The levels of abstraction could be ordered in an hierarchy like this:

  • Highest level: What do we as an organization assume is our most important problem to solve?
  • Mid Level: Which outcomes do we assume solves this (these) problem(s)?
  • Low Level: Which actions do we assume takes us towards this outcome?

At a team level, you might have come so far as to have the team and the sponsors prioritize wanted outcomes – described in terms of effect. This works well, but we can do better. Usually, the team is at the lowest level of abstraction, and inevitably, the highly intelligent people in the team will wonder about the reasoning that took place at the higher levels of abstraction. Especially in a capacity constrained system (as all systems are) where the notion of alternative cost has been established as a way of thinking. So I think that techniques and methods like impact mapping and the like can be rather disruptive, once the thinking takes hold. It puts pressure higher up in the organization, because in traditional organizations, the highest level of abstraction is the domain of “top management”.

So, desperately searching for a red thread here. What I’m saying is this:

If you still work in a top managed organization and feel how the people “below” you in your hierarchy is starting to ask rather intelligent questions, please don’t tell them to think less and be more intuitive (like you). Intuitive is not the same as sloppy thinking. Believing that you can cover up your lack of clear thinking in the guise of intuition is #notevenwrong.

As I see it, you have two options:

1. Read up. Shape up.
2. Involve the teams in “all levels of abstraction”-problems.

In my mind, both options will eventually take the organization to a better place, but I do most certainly favor option number two.

Forward: Defining a desired future state and then closing the gap is what I would call a core Systems Thinking practice. Another way – and some would say a better way – to tackle things would be by way of Complexity Thinking – which we will have to return to in another post.

Earlier post on Not even Wrong

Not Even Wrong – Initial thoughts on strategy

July 2014
Stockholm @ the office

It’s been an interesting summer of reading. I was on holiday after all, so I gave myself a long leash and permitted my mind to wander. I ended up investigating my hunch that the way organizations think about strategy can have a profound impact on how they think about all the other aspects outlined in my model-in-progress. This is most certainly not a revolutionary thought, yet I felt I needed a bit more background on the very concept of business strategy to better understand the mechanisms that I sense are in play. I have a feeling that the underlying world view that constitute the basis of strategy is a bit of a blind spot for many organizations, to speak in terms of johari windows and all. I’m basically suggesting that many organizations unknowingly embraces strategic thinking that is based on world views that are not congruent with the world view of the organization.

This research led me down a path where I explored the history of business strategy, rather than the practice of business strategy itself. Mintzbergs Strategy Safari and Walter Kiechels Lords of Strategy were great companions on the journey.

On this journey, to my great and admittedly smug satisfaction, I found ample evidence supporting my long held belief that business strategy as a concept rests on rather shaky foundations. As you may know, there are several schools of strategy and they cannot seem to agree with each other on even the fundamentals. They are, as one author remarked,  “remarkably inconclusive”.

For anyone interested in Systems Thinking and Holism, the conception of business strategy becomes the starting point of it all, as every initiative or plan designed by the organization flows from the strategy – and more importantly – and this is my point – the strategy therefore carries with it the underlying beliefs that is allowed to guide the strategic process further into the fabric of the organization. It follows then, that identifying how the organization thinks about “strategy as concept” is a way towards understanding the fundamental world view that will, via the strategy, permeate the entire organization. I would venture a guess that this is not something that all too many organizations sit down and have a chat about, which further suggest that these underlying mental models and world views are left unexamined and most likely unknown to the organizations themselves.

Researching how the idea of business strategy itself –  and the later different flavors of strategy – emerged is immensely entertaining. For you who are happily unaware, suffice it to say that had you been there in the 1960’s when the idea of business strategy was conceived (in a joint effort of the management consulting firms and Harvard Business School) I would have excused you for remarking rather irreverently “Wow guys, you’re just making this shit up as you go, don’t you”. Because they were.

Fast forward a few years, and I would not have admonished you for saying “Wow guys, these things that you propose, they don’t really work do they?” Because quite often, they just didn’t.

One major take away from these studies is how severely  a classic prescriptive strategy mindset conflicts with the strategy-as-learning perspective. Implicit in the prescriptive schools of thought is the idea of strict hierarchies, top down, command-and-control and other – from my perspective – unwanted elements. The question I’m exploring is to what extent – if at all – the organizations’ take on strategy can be a constraining factor in our drive towards change and the future of work.

Further more, if the idea of generic prescriptive strategies is firmly in place in the minds of managers, there’s every reason to suspect that the dangerous idea of generic best practice also lands in fertile soil. The idea of organizations as complex adaptive systems finding themselves well within a complex context must seem awfully alien to such a mind.

To sum up: There’s a potential mismatch between the world view that created some of the strategy ideas now in use, and the actual world view of organizations. This might create dissonance. And as the novel practice of business strategy was exported to all corners of our globe, that movement seem also to have exported a set of beliefs and values that I deem to be detrimental to the idea of the modern workplace.

One might even say that they’re #notevenwrong

Earlier post on Not even Wrong

Not Even Wrong – Reality Check V: Guest Post: The biggest lessons from a successful software project

July 2014
Stockholm @ the office

Yet another great post from the Team that brought you the new Hemnet Map Search. This time by Stefan Lindbohm. You can find the original here

The biggest lessons from a successful software project

In my years of working with software projects the one thing I have learned is that doing software projects is really hard. Probably zero projects I have been part of or heard of has delivered their value, kept the quality to a standard everyone is proud of, launched on time and had a team of happy people through all of it. Recently, though, I was part of project that did just that. An actual real life professional software project that was deemed successful by both the team and the stakeholders.

I work at Swedish real estate site Hemnet. We are a company of about 50 people with about 15 people working in product development — mostly developers plus a few designers. Being a small company means we are close to management and all fill a bit wider roles than in larger companies. The biggest challenges in our organization has been making priorities and following them through. This heavily influences where we have put most of our effort and where we have made the biggest lessons making, though I think most of it can be pretty broadly generalized.

The team consisted of one UX designer, one graphics designer, one business analyst, one dedicated developer and me as team lead and part time developer. With the team of 5, we switched map providers, created a solution to render 100 000 hits on a map simultaneously and designed and implemented an all-new view for searching on maps. We did this in just 6 months and, from the release date set in the beginning of the project, slipped only one week with being fully rolled out.

Before we get in to what did matter, let me point out that you can Scrum, Kanban or Scrummerfall all you want without getting much of results. It’s easy to try to change the internal methodologies of a team because that’s something you’ve got complete control over. The biggest challenges though, are in getting the right conditions for the team and within the organization. Only after that is settled does methodologies begin to provide real value.

Here are the biggest things that made the project succeed.

A team with power to do its job

This is where everything begins. Way too often, projects are spread out over departments and even split in sub-projects over different departments. The business side is done in one project, handed over to a design project and then handed over to a development project. And even if that is not the case, people are still spread out without good means to focus and communicate on the project. This completely kills the common understanding and collaboration within a project.

Our team was created with exactly one premise: the goal of the project. We were to create the new map search experience on Hemnet. How would it look? Find out. How would it work? Find out. What would it even do exactly? Find out. This was absolutely crucial in enabling us to do our work — we are product developers and excel in solving problems. Based on the goal, the team formed the plan to do it, the concrete requirements and features and did all the design. Except for getting the rest of the company to buy in on our plan, we were never in need of someone else’s decision.

This of course requires the team to have all the competencies needed to get the job done. Having a team with a common understanding from start to end has incredible value in ensuring everyone works on the same thing and towards the same goal to create a cohesive product. In our team, having our business analyst from start to end allowed us to not stray away from business goals, and having everyone with from the beginning ensured we all really understood why the heck we were in this to begin with.

One of the factors we all appreciated the most was being all together in a room dedicated for the team and the project. If you are in an office, the change from being just one room apart is a huge boost to the social aspects of the team and the collaboration made possible by putting sketches up on the wall and just leaning over to talk about something is invaluable.

Making sure of a stable team with the right conditions is where everything begins.

Awareness of what could go wrong and preparation for it

Things always go wrong. The problem is that we more often than not ignore this and just plan for the best. This results in everything going to pieces when an assumption turned out to be wrong or an unforeseen problem arises. As a result, projects usually hit a point where everyone gets uncomfortable over something that went wrong and starts arguing over how to proceed — a situation where exactly nobody has their best ideas.

We spent a lot of time in the beginning of the project trying to figure out where things could go wrong. Being aware of the risks is key to being able to react in an intelligent way when something eventually goes wrong. In our case, we identified where users were most likely to have a hard time with the change and what business related key measurements we were most likely to impact. We completely shaped the project around the risks and made sure everyone understood and were prepared for the things that could go wrong. This helped us adapt continuously and completely avoid disasters, both in the product itself and among people in the company.

The plan we made focused on the key features that would be realized in the project on a higher level. This allowed us to cut the right corners in times when time started getting sparse while still delivering the value promised. We also spent time discovering where scope creep would most likely pop up and discussed these points beforehand. The things we agreed on not doing were then part of the plan. Designing the plan in terms of general features and including the things we would not do was a key tool for us in delivering the project on time.

Plan as much for the risks and the things you won’t do as the things you will do.

Collaboration outside of the team

All developers have been in projects where requirements and conditions change over their heads. A manager changes his or her mind on something too late in the project or another project gets important and starts snatching people. This is one of the most effective ways to demoralize a team trying to make something great and is probably also the most common way I have seen projects go out of control. The problem here is that managers often have no ability to make sense of cryptic scrum points, refactorings and vague descriptions of what is done and what isn’t, which forces them to make decisions with effectively no information on what they are deciding on.

First off, we put a lot of effort in communicating the plans for the project. We made sure everyone with the power to change our faith were fully aware of the plan, including what we would do, what we would not do and what we needed to complete the project. We did this early enough that we still could change everything and made sure that all stakeholders had their say before nailing it.

During the project, we continuously discussed any change that would affect stakeholders with them and held recurring demos open to anyone in the company. This allowed us to work without dropping anyone’s perspective. We had a number of small changes come out of this that would have gotten into big problems if they wouldn’t have been revealed until the end of the project.

Keeping managers and stakeholders in the loop is key to having the project stay it’s course.

There isn’t ever a silver bullet with these things. These were the biggest contributors to this specific project being a success. Even though I have reason to believe they would help significantly in many situations, a project always have to start with the people and environment where it will live.

We have the brilliant Thomas Lindqvist as our full time coach working on process and people since two years. This project is the result of those two years of experimentation and much of the reasons why it succeeded are the brainchildren of Thomas’ continued thinking on the matter. This may seem too obvious, but the best way to get better at process is to spend time thinking about it and improving it.

If you are interested in more on this particular project, Thomas has written on the “post-mortem” retro we held with the team, our graphics designer Daniel Feldt has written on his perspective of the project and our UX designer Magnus Burell had atalk on the UX side of things. And for the more technical side, our map-oriented developer Igor Tihonov will talk on this year’s FOSS4G in September.

Earlier post on Not even Wrong

Not Even Wrong – Reality Check IV: Guest Post: Creating a new map search experience

July 2014
Stockholm @ the office

My friend and colleague Daniel Feldt wrote a few words on one of our latest endeavors, and he was kind enough to let me post his text on these pages. You can read the original here.  

From my perspective, this quote is particularly heart warming:

“I’ve worked on web projects since 1999 with everything from web hosting to light backend programming to interaction design and visual design. That’s 15 years of experience – quite a lot in Internet years. …The new full screen map search is, by far, the most fun and successful web project I’ve been a part of. “

Creating a new map search experience

In May of this year a small team at Hemnet launched a new full screen map search experience for 1.8 million weekly visitors at From start to finish we researched, designed, built and launched the new search in six months. The new full screen map search is, by far, the most fun and successful web project I’ve been a part of. This is a short summary of how we did it, from a user experience designer’s point of view.

I’ve worked on web projects since 1999 with everything from web hosting to light backend programming to interaction design and visual design. That’s 15 years of experience – quite a lot in Internet years. During these years I’ve worked in everything from huge corporations to the smallest of teams, and one sure thing is that the product development process has almost never looked the same.

Some of these projects were successful. Some weren’t. Some projects were never-ending, with a backlog managed by Mr Creosote and thus exploding to a gooey mess when the last piece of thin mint gets added to the backlog.

I would certainly categorize the Hemnet Map Project as a success. Successful launch and satisfied stakeholders – but here is something that’s even more important to me: a happy, inspired and creative team from start to finish. A team that leaves the project hungry for the next one.

Setting up the team

To wildy paraphrase, we were told:

“Bring home the full screen map search*, create a beloved fullscreen map search experience with new possibilities for added functionality for the user and future ad revenues. And do it as fast as you possibly can.”

* previous one was hosted and developed by an external partner

We got the trust to set up a small and self organizing cross functional team – running fairly autonomous with regular demos and and go aheads with management. The team consisted of:

• Two designers – With a range consisting of user experience, interaction design and visual design
• One researcher – A freelancer helping out with interviews, personas
• One business developer – Concepts, ads
• Two developers – Ruby, map tiles, front end

One of the developers were also team-lead – keeping the whole thing together and on track. Note that this were our titles and main focus areas. But all team members were involved from the get-go in everything in the project.

Everyone had a say during decision making discussions and because we had the trust from management and had all the necessary knowledge in the cross functional team – we could take decisions right then and there ourselves. Eliminating the time it would have taken to report, present and get go ahead from management.

We felt a true ownership of the project.

Decisions were made with a shared understanding for the value we would bring Hemnet and with regard for the overall goal for Hemnet. The trust of setting up this team and managing this project came with a couple of conditions.

We had to:

• Have regular demos that the whole company could attend where we presented what findings we’d done (early in the process) or what we were done building in the project.
• Break down deliverables to smallest possible chunks and deliver them to the live site to reduce future surprises
• Have regular retrospectives where we talked about the projects progress, if we were happy, what would make us happier, et cetera.

The discovery phase or “to boldly go where no man has gone before”

With all this we moved into a discovery phase. Again, all team members were involved in every aspect of this. During a eight week period we defined goals and metrics for the projects. The success criterias were defined by the team, not the management.

We researched, found and verified insights thru surveys targeting our existing map search users to track their needs and behaviour, sifting thru behavioural data from site usage and phone interviews with users.

We co-wrote user scenarios and project specific personas. We visualized concepts together, gathered feedback and built simple prototypes.

In the end we had lots of findings, prototypes and good stuff to work with.

Implementation phase

At the end of the discovery phase we had a pretty good idea about what we needed to build and how to build it. The implementation phase started with a lot of planning. Splitting scenarios into buildable chunks that we could deliver to the live site whenever they were done. That reduced the number of late surprises compared to pushing a huge chunk of code to the live site.

Again we did a lot of things together. Sketching concepts and drawing responsive patterns on whiteboards and paper – quickly presenting our ideas, throwing them away, presenting new ones and honing the good ones. Everyone sat together in a room covered with whiteboards, and everyone drew. This is by far the quickest way to iterate design solutions instead of a single poor designer detailing a wireframe and risk spending too much time on a solution between design critiques.

I’ve seen, been a part of and also been the culprit in projects where the time between design critiques grew longer and longer. And if a single designer spends too much alone time on a solution you can almost hear the Deliverance-banjo playing in the background. That’s never a good thing.

We met the challenges of continuous feedback in several ways. We had bi-weekly demos that the whole company could attend, where we demonstrate what we were building.

Once every week, always the same day and time, we also invited whoever wanted to come to a “designfika”. If you are a Swede, or ever been involved with a Swede, you are aware of what a “fika” is. It’s generally an excuse to have a cup of coffee and eat buns. At the “designfika” we gathered in a room with coffee and pastries and the design team presented whatever they were working on at the moment. The purpose was to gather feedback.

In a way we are all designers. Designers solve problems and that’s something everyone can be a part of. The people with the title “designers” have the task of presenting what the problem is, how the design solves that problem and gather feedback on the design. But, I guess my view of the role of a designer and the importance of design critique is another blog post to be written…

The last part of the continuous feedback is one the most crucial. User testing. We employed several ways of user testing and as always: the more user testing you can do the better. We invited users to our office and did 10+ interviews and let them try out the project. Quite straight forward. Now we don’t always have the time and resources to do something like this, and you probably don’t either.

Quick tip: The easiest way to quickly get input is to test on people from other departments within the company – which we did. My colleague Magnus also put together a homework assignment for everyone at the company with a single page crash course in user testing with ready made questions so that everyone could test the product on a friend or a family member.

All this gave us valuable insight regarding how the product worked, and this is something you could easily do whenever you are designing something. Not only will you get valuable feedback on the product, but you will also spread the knowledge of user testing to other parts of the company. And I can assure you that the majority of your colleagues will have fun doing it and they will also (hopefully) feel involved and invested in the project.

The importance of A/B testing or “Scotty, what do you think, forward thrust?”

After nine two weeks iterations with continuous design iterations and lots of backend development we finally had a product to start A/B-testing. This was important for us because we wanted to make sure that the tech behind the new map search would hold up for traffic and how the flow of traffic would change and/or disrupt existing ad revenues.

With a product ready for A/B-testing we started to deliver the new map search experience to 5% of our traffic. We had launched the project. Now we started the process of analyzing the stats and gather feedback from the 5% of users using the new map search. We got our hands on a handful of browser bugs and some map tiles performance issues and spent the last couple of weeks polishing the product.

Throttle up or “Scotty, we are going to need everything she’s got!”

Now, there are something quite fulfilling with having a big bang release. Push that button and release this new product to a surprised group of users. Shiny, new and scary (if you ask the user).

But starting out with the A/B-test meant that release day practically meant throttling up from 5% to 100%. Maybe not as exciting as a big bang release, but way better for your nerves and it makes it possible for the team to enjoy a beer at the launch party.

Post release phase or “The final frontier”

Just because we launched the new maps didn’t mean we were done. There were still stuff left on our wish list that needed to be done. The live site were running our most viable product with some additions. But still a lot of stuff to do – UX goodies, performance enhancements and such. The backend team needed to spread the knowledge of map tiles and all the work they had done to the rest of the developers and the design team had style guides to update and communicate.

Our keys to success or “how to keep the redshirts casualties to a minimum”

To quickly summarize our keys to success and how we avoided “redshirt casualties”. We had easy access to everyone we needed to talk to, we got insights from users from our user panels and behavioral data from Google Analytics. We had all the necessary competencies in the team to solve the task, and we were the decision makers.

We were “hands off” from management and were able to focus on our task. We had time to plan, learn, fail and then learn some more. Designers programmed and developers were involved in research and design.

And we communicated. A lot. Everything in this post is about communication. Daily stand up meetings, spontaneous and planned design critiques and regularly retrospectives that gave us concrete actions to improve the project and keep us as happy as possible.

Built by five people in six months. We are extremely proud of the result. You can try out the new map search here or see a little bit more of what I did here.

My colleague Magnus Burell held a presentation called “UX at Hemnet” at the UX All Stars (Yes, he really is an all star) meetup – check out his slides on Slideshare.

Our resident guru Thomas Lindqvist recently wrote about the final “super-retrospect” we had with the map search project revealing the questions and answers the team came up with. I wrote that communication were the key for our success – Thomas is the reason we communicated well and continued to do so during the project.

If you are remotely intrerested in product development process you reallty should check out his series of blog posts on that subject.

And I am sorry for the poor Star Trek references.

Earlier posts on “Not Even Wrong”

Not Even Wrong – Reality Check III

July 2014
Stockholm, @ the office

I’ve learned that people will forget what you said, people will forget what you did, but people will never forget how you made them feel. – Maya Angelou

I thought I’d talk for a while about how our product development process relates to learning and continuous improvement. Before we move on though, I will take this opportunity to hint of the larger master plan that is lurking between the lines of all these scribblings:

“The third fundamental element of the model is that learning, quite like change, happens all the time at all levels. I posit that it’s impossible to create change without creating the opportunity for learning. This learning is the force that takes us towards our desired state, as we cannot get to where we want to be without internalizing and applying this potential for knowledge that we create.
If this is valid, understanding how we learn becomes imperative.”

Indeed. How we learn. It matters. If you agree with my proposal that learning is imperative, it follows that we might do well to investigate how we learn and do our very best to learn like pro’s. I would also like to stress that this is but one of several aspects of learning in an organisation.

Now, the theoretical foundations that I lean on here can be found in the work of people like David A Kolb and Kurt Lewin and the concepts of “Experience Based Learning” or “Experiential Learning”. We will return to them further down the road. What follows here in this post is a more practical example of what this can mean.

To accomplish this I thought I’d let you in on a “post mortem” retrospective that we had just a few days ago. While the team had retrospectives continuously during their time together (one of the few non-negotiable practices as the team chooses their own process), I also see great value in looking back at the whole time period that the team spent together and taking a more “big picture” approach to our work than can be squeezed in during the discover/deliver-phase retrospectives.

During this one-day “super-retro” we went through these steps:

1. Timeline of the time spent together
2. Timeline – Happiness Curve
3. Timeline – Productivity Curve
4. Exercises:

•What does a team need to deliver with quality?
•What does a team need to deliver with speed?
•What does a team need in order to be happy?
•What are the characteristics of a good Team Lead?
•What are the characteristics of a good sponsor?

5. Personal feedback (formalized, written down and delivered orally)
6. Evaluation of the day
7. Beer

We drew a timeline of the whole project, and noted significant events. This helps the team remember their time together and shapes a mutual understanding of what happened. As you know, with memory, every read is a write, so what actually happened is lost forever in the sands of time, but that’s a conversation for another day. Yet, creating a shared mental image of the situation is crucial – even though it can never be “accurate”. This creates a fundament for the conversations that are about to follow. Setting the stage is imperative.

It’s also very important to have a climate in the group where people feel that they can say what is actually on their mind, and not revert to politeness. I mention this because I see general tendencies in several areas to disregard certain set of circumstances that are key factors for success. You can for instance have the greatest set of KPI’s in the world, but that becomes wasteful if decisions are really made by way of power grabs or office politics. And you can have the greatest retrospectives in the world, but if an open culture where people feel that they can speak their mind is not established, you will not get the results you seek. It’s all connected.

Now, we moved on by tracing the general feeling of happiness that the team experienced during the time frame, and drew a curve that clearly demonstrated the emotional “up’s and down’s” of the work. We then did the same exercise with “productivity”. This allowed us to have meaningful conversations about the teams experience.

Then, the Team was asked a set of questions:

  • What does a team need in order to be happy?
  • What does a team need to deliver with quality?
  • What does a team need to deliver with speed?
  • What are the characteristics of a good Team Lead?
  • What are the characteristics of a good sponsor?

The various “aspects” were then listed by the team, and a few rounds of discussion ensued. The next step was to rank their experience during the whole theme work, using the scaling approach inspired by Solution Focus. The Team Lead exercise was designed so that we could have a look at the Team Lead’s idea of himself (Ideal Self) versus the Team’s perception (Real Self). This provided some clues and was valuable feedback for the Team Lead.

Another dimension of this was that even though we were looking for team averages as they graded their experience, we noted when there were significant diversity in the group experience, which led to interesting discussions and insights.

Below you’ll find the question and the answers that the team came up with.

What does a team need in order to be happy?

  • No hidden agendas.
  • Being co-located, preferably in the same room.
  • Agreement regarding how the group makes decisions.
  • Good talk.
  • Defined Roles.
  • Laugh together.
  • Celebrate often.
  • A sense of purpose and progress towards the goal.
  • Understanding and acceptance of diversity in the group.
  • Shared spaces for communication, ideas, progress and checklists.
  • Shared understanding of what it is that group wants to achieve.
  • Shared understanding for the the decisions made by the group and the sponsor.
  • Care about each other as people.

What does a team need to deliver with quality?

  • The necessary time, resources and skill to be able to try different alternatives with and without users, and the time to react to the feedback.
  • Freedom to chose our own methods and tools that work for us in our context.
  • A clear goal.
  • Good people.
  • All the skills necessary in the team, or adjacent to the team
  • Free reigns and focus.
  • Reasonable time frame, time frame set by the team.
  • The sponsor cares about the result – measurements and quality
  • Design towards measurable goal.
  • Stability in the team – not moving people around.
  • Frequent delivery and short feedback-loops.
  • Stability in the environment.

What does a team need to deliver with speed?

  • The right skills for the job.
  • A good environment.
  • No breaks or disruptions during the work.
  • Frequent delivery of value and short feedback loops
  • A team up for the job (team size).
  • No unexpected disruptions during the work.
  • A Team that can collaborate and work together well
  • Trust from the organisation.
  • Focus – one thing at the time.
  • Slack.
  • Deadlines or rather commitments towards a time frame.
  • Small batches of value.
  • Clear goals.
  • Ability to find problems early.
  • A backlog that is properly prioritized.
  • The ability to constantly re-prioritize.

What are the characteristics of a good Team Lead?

  • Facilitates the group.
  • Makes sure that the needs of all group members are met and provides a natural place for each individual.
  • Takes care of the planning.
  • Protects the team from exterior disruptions.
  • Focus on clear goals.
  • Is responsible for the group dynamic, and the development of the group.
  • Makes the team visible in the organisation.
  • Clear take on the user goals – business goals – tech goals triangle.
  • Clear take on the time – quality – resources triangle.
  • Keep the moral of the team high.
  • Makes sure that necessary decisions are made when necessary.
  • Communicates needs, obstacles and progress to the organisation.
  • Passionate about product quality.
  • Motivates.
  • Has a sense of responsibility.
  • Is passionate and committed.

What are the characteristics of a good sponsor?

  • Trust that the Team can deal with the task at hand – no micro management.
  • Sponsor must be able to set clear goals.
  • Sponsor must feel a sense of responsibility for the job, and the goals that they have commissioned.
  • Care about the User Experience.
  • Understand the difference between wanted outcome, measurements, user goals and business goals.
  • Show interest and commitment.
  • Understand the consequences of the prioritization’s that they are asked to make.
  • Be able to make quick decisions and change course if necessary.
  • Be loyal towards their own decisions and prioritization’s.
  • Follow up on progress and achievement of goals.
  • Be clear on what they are commissioning and why, and communicate this to other parts of the organization.
  • Be prepared to re-prioritize and shift focus and allocation of capacity.

Now, what happens if you take these insights, place them on the happiness and productivity curve and create an overlay with the personal feedback?

Interesting stuff, for sure.

Earlier posts on “Not Even Wrong”