Introducing Mob Programming to teams


I have recently been introduced to Mob programming by Woody Zuill andLlewellyn Falco.

So what exactly is Mob programming? The essence of it is pretty well captured in this tweet (press play icon):


First time i heard about Mob programming was in November 2013 in Stockholm at Ericsson, Woody presented this method to the audience and later we had a small hands-on session. I was immediately in awe, but also suspicious. OK, it worked well with a trivial example, but would it work in a real working environment? I decided to give it a try once I got back home.

So, I tried it with a colleague of mine, or actually we just did pair programming with the strict driver/navigator rule (that is originally from Llewellyn,

Turned out it worked pretty well, we got a lot of stuff done and mostly first time right, but the risk of getting lost in the same direction was also quite high.

We tried it for a while but then we just stopped, I moved to another team so we did not have any common work items any more to pair with.

In the Spring of 2015 I attended XP conference in Helsinki, and again Woody was there presenting Mob programming. With a few twists from last time i saw him, I was especially taken when he had started to use cyberdojo by Jon Jagger as a teaching tool – I have had some experience in using that, and I recommended this to Woody in Twitter after my first session.

Anyway, this time my interest was re-ignited and I wanted to try again this with my current team. A team which consisted of people who worked individually rather than in a group – we usually had almost as many user stories open than there were team members. This led to multiple problems. If somebody was sick, that particular user story development stopped. It was extremely hard to jump in to help with a user story. And, as there usually are surprises, we often found ourselves using more time finishing the tasks we originally thought we would.

So, I introduced mob programming to the team, and at start we tried to apply it on some particular tasks of a user story. Couple of rounds of that led to people not wanting to stop, you could almost feel the flow, and it was really enjoyable to see people collaborating so eagerly. But still, something was not right. We started collectively to wander outside of the scope, and the big picture remained unclear. But there was something in the method, it showed us in practice that a team is more than sum of its parts.

A few months on we got a new team member. And, as he was new to the feature we were working on he suggested we could do some kind of code walkthrough when planning the next user story. This turned out to be the missing piece in our experimentation with mob programming. The idea was welcomed by the team, and a suggestion came up that why don’t we actually write some todos or pseudo-code to the files we needed to modify, and another suggestion that let’s do this mob programming way.

As pre-work we split the user story to tasks using a whiteboard sketches and post-it notes( Here by the way is a great way to do that:
We ordered the tasks in implementation order, had a few separate seemingly independent tracks and planned the verification steps. Next we took a meeting room with projector and started to transfer the sticky notes into todos in code. We soon realized it is good to number the stickies and the todos to be able to match them.
Some functions got hit by multiple tasks, but that was expected.

This exercise took about 3 hours, where one hour was spent with the whiteboard and two mobbing the skeleton. After this session we held a session focusing on tests, basically we wrote the test descriptions together based on input from this first mob.

What then happened was truly amazing, we transformed overnight from “user story per developer” to “everyone working on the same user story”. The tasks were done in multiple ways, some preferred individual work, some did pair programming, even some mob programming, so everything from individual to mob.

The story ended up to be about twice the size we expected, but because we all had focus on that particular story, and thanks to the skeleton mob clear common understanding how to implement the tasks and how should the end result look like, we were able to complete the thing in the time frame we originally estimated, just with double the people.

Of course the actual size of the user story was not the only surprise we encountered. Then we ran into first code conflicts. The tracks weren’t as individual as we thought, and it took a lot of effort solving the conflicts. We also bumped into other surprises where we simply had to change the solution from original design. And, as we continued, we realized there were some things we did not even know we didn’t know. All of this led to a bit of frustration, but the main learning was this: When unexpected things happen, call in the mob. When you find possible conflict points in the “skeleton mob”, take a note and do the implementation in those functions as a mob, or at least by pair programming.

We were lucky enough to get Woody & Llewellyn to visit our office after our first successful experimentation with Mob programming, and they hosted a one-hour retrospective for us, where we were able to get some tips how to make the mob work even better for the next time. So if you happen to bump in either one of these fellows don’t be shy to ask help and share your experiences!

So a couple of main benefits, learnings and caveats from this experience:

  •  Really good way to share competence
  • Easy to learn new things
  • Easier for people to ask for help since they share a common goal
  • No more wandering outside of the scope, keeping good focus from start to finish
  • Easy to get into “Flow”
  • This method really speeds up code reviews because everyone is already up to speed at all times!
  • On the learning side, commit early and often! This is especially important if people decide to work separately with the items
  • This is mainly because there will most probably be merge conflicts. Pay attention to possible conflicts already at planning!
  • Handle all merge conflicts and surprises as a mob, or not at least alone.
  • Have a short retrospective immediately after a mob. Note also all of the learnings, this is a good motivator. Make sure you will experiment with the ideas team members have.
  • And some caveats: Prepare for a editor battle! (vim vs. emacs vs. ?) As a facilitator you need be prepared to handle this.
  • Discussion might overheat on implementation details.. Be sure to keep all disagreements constructive, handle them with respect.

Saving the best part last; the biggest learning:

Start with something simple yet relevant. Something where the benefit of teamwork is apparent. If the first impression of mob programming is seen as positive and useful, chances are that people want to continue doing it.

Mob programming as such is not the only tool to have a successful planning session (or whatever your choice of simple but relevant teamwork example is), but it is a great tool for doing real collaboration with real problems. When the moment comes you’ll have a way to mob it out!
There is a lot of material about Mob programming in the internet, this article is one of my favorites:

And here’s a blog post about getting started with mob programming:

Woody’s blog:
Llewellyn’s blog:
Mob Programming Wikipedia article:
Twitter: #MobProgramming

Posted in Uncategorized | Tagged , , , , | Leave a comment

Reports goes green, Results goes down – Cost Savings ongoing!

Everything in the company suddenly goes slower, a growing in-effectiveness, an increasing in-efficiency, less innovation and a decreasing motivation.

In the same time all measures, internal reports and audits shows that everything goes better, improves and promises a bright future.


What is happening? How can saving costs have this effect?

The effect comes if the cost saving is perceived by the employees as something that can lead to a personal suffering beyond their control, i.e. lay-offs or replacements. That causes a growing fear and a lurking feeling that the company may exclude me or my friends from “the family”. The safety for the employees is threaten. Simoon Sinek expresses this so well at TED in

With the uncertainty about the future, fear will grow and trust will disappear; – Is the company planning to exclude me?

It will trigger our own “defense” system and we can start to see the symptoms in the company:

Fear over Trust Symptoms

  • Projects will report more “green” – as being a project with issues is not good  under those circumstances.
  • Teams will lower their ambitions to make sure they look successful
  • Less experiments as failures may have implications.
  • Blame – more important to find someone guilty than fixing the problem
  • Overestimated business case to save a product from being discontinued
  • Underestimate technical challenges as it might lead to a discontinued product
  • Departments will report “on-track”, “actions done” and “green” to avoid being the department with head count cuts.

All this represents hidden costs that most likely will exceed the potential save in cost!

When the company is in it’s biggest need for accurate knowledge (to save costs) the data can’t be trusted.

More expensive actions follows…

 As this isn’t enough. As all “green” reports compared with actual outcome is a bit suspicious, it’s time for audits where those symptoms are questioned. Not just that the audit costs money but now the focus from teams, managers, project- and product managers is to come out as  “winner” in the  audits. Showing off as the best team, most efficient organization, most reliable project and vital and promising product. Just when the focus should be on good ways to save costs we are competing internally. The behavior can’t be blamed, if you fear to be cut out you will defend your situation. When fear goes in, transparency goes out.


Not being honest and tell the truth becomes the norm in the Company, between employees, managers, organizations, sites, teams and projects (actually in any interaction).

Only option for a company in fear is for top management to decide what to cut in a top-to-bottom, command and control manner. Decisions now based on false information.

Those decisions can easily be quite expensive.

Long Lasting

It can be argued that a cost saving decisions is a short pain we have to live with, like a twitch of a patch. It hurts and then the rest of us can go on as normal. Problem is that people don’t forget that you once have abandon a family member. The loyalty and trust will not return in many years. Internal competition and “green painting” reports will continue. I have experience from the collapse in year 2000 and it took 10 years to restore (if it is really restored) openness in the company again.

It’s a huge invisible cost!


There are other ways to save costs. There so much gain by keeping trust between people and between the company and the people. If my job is not at stake. If we are in this together, I might even suggest that my position, my project or my products is probably the best one to cut, something you never get in the first scenario.

The loyalty people starts to feel can boost motivation and efforts with a magnitude. This company will not sell me out – I will do beyond my best to contribute.

Posted in assessment, Leadership, Lean, Organizaition, Performance Measurement, Processes, Transformation, Uncategorized | Tagged , , , | Leave a comment

Competing Against Top Testers

This was the first ever global software testing competition and the European qualification round was held online on June 13, 2014.

The Software Testing World Cup (STWC) is an event for testing practitioners to show off their skills and compete with other testing professionals. It brings the testing craft into the spotlight and gives the profession a competitive event on a global scale.

Last year a proof of concept of STWC was run with 16 teams. This year is the first full scale competition running on all six continents with a maximum of 250 teams per continent. In the European qualification 250 teams participated. From Ericsson Finland Kjell Lauren and Tomi Juslin participated together with Ismo Aro and Toni Kortepohja from Omenia Oy as Team Bug Circus. 


We joined the competition in order to challenge ourselves by doing something completely different than what we are doing on daily basis, to find out how good testers we are, curiosity, fun, and of course fame & glory.


A few minutes before the actual competition started the participants got the link to the software to be tested. It was a product that creates demo accounts and reports for small businesses. Our mission was to investigate and report on the current stability of the system. The latest addition to the product was a function that emails out invites to the demo account and to a customer center to view the demo accounts. The customers’ primary concern beyond the email function was to have the system tested on as many devices and screen sizes as possible, but having the Apple devices as primary focus. Additionally, a login account should not be able to see locations created by other login accounts. Load and performance testing were out of scope during the session. Also security testing had a low priority although this was one evaluation criteria in previous qualifications.


The competition time was in total three hours which did not leave too much room outside the test execution, bug reporting and writing the test report. It started with the judges and customer representative presenting the System Under Test (SUT) on the live YouTube channel. After the SUT presentation the judges were available for answering questions of the teams and keeping the teams informed with important information.

In the beginning we struggled to understand what the SUT was supposed to be used for and how it really should work. It took us quite some time to figure it out. The SUT was quite unusable and a specialized application, in our opinion not very adequate for a three hour testing competition. We were struggling with the basic features quite a long time and not focusing on the main features we were supposed to test. Even creating and managing accounts to test the mailing functionality was quite a challenge for some of us. Not to mention the user settings functionality which turned out to be quite buggy too.


Division of found issues per area.

During the competition the found bugs had to be filed in HP Agile Manager, in which some of the teams found a bug making it possible to copy reported bugs from other teams. Each team had to prepare a test report, including the status and how that was achieved as well as how the testing was performed. In total, our team filed 28 bug reports. During the competition a total of 3169 bugs from 250 teams was filed.




We also had an active supporting group of colleagues cheering for us throughout the whole competition; mostly from the sauna and palju (a hot tub). The results are not yet available; they will be announced by end of July 2014.


Preparing for a short three hour competition is not that easy when you have no clue about the SUT or what is required to be tested. From the previous qualifications we noticed the SUT can be a web application or a downloadable application doing just about anything. Also thinking about load, performance and security testing it requires special tools to be able to execute those tests. One thing is for sure, the SUT used in this kind of competition should be at least on some stable level so that the teams could concentrate on testing the features customer requires, not struggling with the basic functionalities.

We had agreed beforehand that one of us will follow the live YouTube channel and one is responsible for the test report leaving two guys to concentrate fully on testing for the whole time. This split of work worked quite well. In the future it would be good to add a couple of short debriefing slots to be able to better focus and change strategy during the competition.

For testing technique we chose exploratory testing to cover the different areas of the application. It was the right choice as there was no time to create any automated tests. We used also a variety of platforms and browsers to gain coverage of the application and see how it worked on different devices with different screen resolutions.

It turned out that writing the test report took more than the 30 minutes we had reserved for it. One hour would have been needed to write a good report. One major input for the test report was the bug reports, which we categorized when writing them. This made writing the test report easier as the info was already available. At the end we didn’t have the time to review the written reports, what would have been needed to make them even better. So at least this is something we need to improve for the next time.

Based on the feedback and comments from the previous qualifications we decided to be co-located in the same room. This turned out to be a perfect choice and helped a lot as we were able to discuss and show each other’s screens all the time.

The overall feeling from the event was really positive. Three hours of full concentration is very exhausting but at the same time the excitement keeps you trying even harder. And YES, we will participate next time, too. In the end, it was about challenging us, sharing knowledge, learning new things, working and having fun with great people.


The Software Testing World Cup is split into two parts: the online continental preliminary/qualifying rounds and the world cup finals during Europe’s greatest Agile event of the year, the Agile Testing Days 2014. The winning team from each continent will be invited to the finals. Up to 8 teams, watched by an international crowd of testers, will fight for the global crown of software testing.

The continental rounds are done locally and online. The final round is done on the spot and will be supported with online and offline media presence (live streaming, audience, stage, etc.). It will be the social highlight at the Agile Testing Days on November 10, 2014, followed by an award ceremony during the popular MIATPP Award Night.

Further Information on Software Testing World Cup (STWC)

  • The official STWC site. Here you can find the rules, Frequently Asked Questions, prizes, winners etc.
  • Twitter stream
Posted in AgileTesting, stwc | Leave a comment

Product Ownership Evolution, part 3

This is the final (?) post in the series of Product Ownership learnings and conclusions as I have them learned so far. It has been a while since part 2, but there is an obvious reason for the long silence period. I have been thinking and trying to understand 2 fundamentals in product and service development at scale:

  1. How do you scale up?
  2. What is the real purpose of Product Owner when connected to previous?

Scaling up is scaling down

It is more clear than ever that large corporations who try to introduce new hope in means of Agile, Lean or systems thinking into their operations will fail. There are several reasons for this, the most obvious ones are connected to business at scale. 21st century knowledge related work (and business) does not require “economies of scale” or “cost optimization”. Neither does it need resource optimization towards existing business but rather building on great people. When you put people doing the value work in the center, directly confronting the customer, you`ll soon understand that two teams will be able satisfy the customer better than two divisions. Of course these teams are special teams: they are consisting of people who have “special powers”. They eat and bite the work at hand easily, they understand the business as they are natives in it, they love their work and they want to share success. In short: their values are different from what traditional corporations possess. The biggest obstacle for achieving this is power. Static organizational structures try to keep existing power structure untouched. Scaling down requires power distribution, not power decentralization. This is the main reason scaling agile is mission impossible for most of the big players. I will write more about power distribution and knowledge work in coming posts.

Product Owner is always a proxy role, that is not needed at all when business at scale is understood, designed and applied correctly

When people are in the center we are moving into new era: people business. Why on earth someone would like to introduce any delay between needs and their fulfillment? When power in the organization is dynamically and evolutionary distributed, most of the proxy roles disappear. I believe this will (and shall) happen to Product Ownership and it will happen to many other coordinating and decision-making roles as well. The final stage of the evolution in the Product Ownership is to realise extinction: the work is distributed between people and therefore this dysfunctional role is not existing any more.


Posted in Agile Thinking, agileHR, Behavior, Change, Leadership, Product Owner, Transformation | Tagged , , , , , , , , , , | Leave a comment

Radical Movement

We are in people business. In the heart of knowledge work are people, their intellectual, social and emotional capabilities. This “assett” cannot be led by traditional methods. New skills and abilities are needed. World needs more soft aspects; it is more important to discuss about safety than new process or way of working. This change is more fundamental than any what we have seen previously in modern business environment. Actually this is the true survival of the fittest. The ones who understand and are able to do this will have definite competive advantage. Big amount of people on their side.

I have been asked what and how we do this in different communities? How do you make sure that people are going into right direction? You don`t! When group of people move towards something new there are many different paths. What is important is that we share enough common understanding about where are we aiming. Moving towards something better as a group is something we call Radical Movement. It is not very radical as such, but for conventional thinkers it might feel like it. Here are some characteristics how we think:

  • We move as a group, not as individuals
  • Individuals are respected and listened to by everyone
  • We need together decide if we want to set new vision
  • A common good is more important than individual needs
  • Thinking big means thinking others first
  • Moving from “what is in it for me” towards “what is in for us” and “what is in it for the world”. Keywords here are empathy and compassion.
  • Life is great!

When collectively improving on thinking and in our behaviour, the quality of life for everyone moves to new level. Isn`t that one of the main purposes of our existence?


Posted in Behavior, Change, Fun, Leadership, Myths, Radical Coaching | Tagged , , , , , , | Leave a comment

Self-Evaluation and Performance Review

What if combine two things with different purpose into one and the same activity?

combine_formPurpose of Self Evaluation

If I want to improve, grow capabilities, expanding knowledge, challenge behavior, utilize my greatness and in short become a better person it helps to know about myself. Create an awareness of my strength and what I have a desire to improve. In order to succeed being a better person motivation is equally important. Awareness and Motivation is key. As I am more likely to find motivation to change something I identify, it’s more important that it’s my own finding, rather than it’s the absolute most critical one. That is the idea with Self Evaluation.

self-assessment_Homer The purpose is to support you to develop yourself by building self-awareness while maintain motivation to improve.

Purpose of Performance Evaluation

In its best form it’s to find out if all my efforts paid off. Did I get the result I wanted? Any corrections to do to perform better? BUT that is not how it is used most of the time. The most common purpose of performance evaluation is for the employer to set salaries.

Combining the two

So, what is happening if we combine those two in the same activity and dialog with your salary setting manager? I am asked to do a self-evaluation which is the base for performance evaluation which is base for my salary setting. Knowing this self-evaluation is affecting my money – of course I end up in the sell-mode. Time to make a good impression! Not only for the money, it’s also to get my manager to trust me, let me work on interesting assignments. Good for me if my manager knows I’m great.


NOW, let me add another observation: In order to base the salaries on the performance evaluation the company sometimes come up with the idea that the result must be according to a certain distribution, i.e. there can only be a certain percentage of top-performers, great-performers and average performers. This have an interesting effect on the self-evaluation and performance reviews.

This is what’s happening

  1. I evaluate myself on the very positive side because I know this affects my salary and my possibilities to work with interesting things. (The purpose is no longer self-development and improvement)
  2. The manager can comment and reflect but as it is an self-evaluation I have the last word and I will hold on to my view.
  3. Now the manager have to bring this self-evaluation and compare it against all others self-evaluations and check it against the company’s distribution of performance reviews.
  4. It may (understatement) turn out that there are too many top and great performers so the manager have to go back to the employee (me) and tell that: “- You thought you were good in this but actually you are NOT.


  •  No benefit from the self-awareness (as you are in selling mode)
  •  No fair performance evaluation as it is relative to your colleagues
  •  Motivation is probably gone when your manager is telling you are not performing as you think

What will the company gain with a process where you have to tell people they are not so good as they think!? How is it good for the company to let the self-evaluation be useless? Wouldn’t the company perform better if we all thought we were top-notch-great?

TEAM_toppick_cropTo win the World Championship, is it a good strategy by the coach to tell the players that they are not so good as they think they are? Is that how to create a winning team?

Mixing self-evaluation and performance review into the same activity will most likely have a negative effect on performance.

(There are probably no companies that have this setup, but if they do, I hope they re-think before all talent people are gone.)


Posted in agileHR, assessment, awareness, Change, communication, Evaluation, Leadership, Organizaition, Performance Measurement, self-awerness | Tagged , | 2 Comments

Some thoughts about self-assessment

I googled for some ready made question sets about the subject, but could not find any “full set” that would suit my needs. So, here is a collection of questions that You might find suitable for You.

The questions are divided to two parts; first part of the questions are only for You to answer. The second part is a basis for feedback.

I personally tested this set in a “safe environment” with one colleague i trust (we actually answered all of the questions together). Now i have a clear vision for what i should continue on and what i should stop or change.

Here goes:

1. Questions for you to answer about you:

1.a Identify what you like most about your current job

1.b What accomplishment and achievements are you the most proud of this year/period/etc? (It really does not have to be done 100% by you)

1.c Identify the components of your job you would like to change or eliminate. Why?

1.d Can any of those things you want to eliminate or change be translated into a goal for you? List.

2. Questions for yourself AND others

2.a Participation and contribution to the team/community?

2.b Impact on others?

2.c Key development areas?

It took me & my peer 2 hours to answer the questions, and i think it was time well spent.

Posted in Uncategorized | Leave a comment

Are YOU lean? – The Lean Driving Test

Lean Awareness in Driving


Transforming to Agile and Lean is far beyond changes in methods and processes. It’s equally, if not more, about changes in behavior and culture. A  organizational change or process change is not enough, changes in our self as individuals needs to happen sooner or later. The culture is built on behavior by individuals.


Well, have you transformed in to a Lean behaving person?

Consider yourself as driver in one of the four cars A-D:

Driver in A:
You are driving exactly as the speed-limit prescribes. No matter if it would be possible and safe to go much faster – you stick to the plan (speed limit). You are still in command and control, a sense and adapt lean person will try to run faster as long it’s not jeopardize safety(or risking a too expensive fine).

Driver in B:
You try to use your engine’s power and the car’s brake capabilities as much as possible. Your go as fast as possible in every second, you try to stick as close as possible to the bumper of the car in front of you. You will have the highest top speed (very occasionally) of all cars at the road. This feels very active and requires you to be on your toes and take active operative decisions every second. You are optimizing on resource usage. You believe pushing the most out of the engine and your brakes is equal to get to your destination as fast as possible. You are one of those that creates congestion and queues out of nothing. The risk to make the system collapse for hours due to car crashes is substantial increased . 

Driver in C:
You avoid to use the breaks. You try to push the engine just enough to leave room between you and the car in front of you so you don’t need to hit the break on the complete journey. Your car is going roughly at the same speed all the way. If the car in front of you keeps the limit, that will be your speed as well. If the car in front of you goes faster – you will. You will keep a distance just to even out the changes in speed the car in front of you might have. You know that the fastest way to get to the destination is not about speed it’s about not to break and keep all cars around you in a steady flow. You got it!

Driver in D:
You just have to rush and overtake C so you can get to the queue a bit earlier and by that gain exactly one position in the queue. You feel the urge to constantly change lanes in queues because the other one seems to go just a bit faster. Too bad all cars going to arrive later to their destinations due to traffic jams and accidents.You are sub-optimizing your own speed at expense of others. The overtake will force others to break, it builds queues, jams and accidents. All cars, including yours, will go slower (but you will arrive ahead of that lazy D-driver). Changing lanes (like moving work from one queue to another) will only increase the queuing time.   

– Are you a Lean behaving driver?
Posted in Agile Thinking, assessment, awareness, Fun, Leadership, Lean, Organizaition, Processes, Risk Management, Transformation, Way if Working | Tagged , , , , , , , , , , , , | 7 Comments

Another Workshop in introducing Lean&Agile…

PaperArtist_2013-04-25_18-13-15_resizedToo many workshops are held these days with the aim to introduce Lean and Agile ways of working. There are two issues with that, first L&A is not only about ways of working, secondly the aim must be a real gain or a real problem to solve. Lean & Agile as no value on it’s own.  A customer will never pay any extra for a product developed in a certain manner based on certain values, they will pay for the value the product and supplier is giving them.

The problem often arise in the end of such a workshop when there shall be a number of actions created. (Typical for this types of workshops is that it’s success is measured as number of powerful actions) The actions is then often aimed at transforming  into Lean operations or get teams working agile. This without reflecting on the real purpose. What is the expected result from team using scrum? What is the result an organization want to see by adapting a Lean mindset?

Not all Lean & Agile workshop is problematic, it can be very good for education, inspiration and adapt principles and values. When it come to seek actions I recommend to focus on the actual problem or wanted results. Here are some examples on workshops where finding applicable actions is more likely both to find and to be successful:


  • WS on setting goals and targets in-line with lean values and principles
    The lean aspect on this is how we set goals on values and results over performing actions. How we set targets based on throughput and value creation instead of resource utilization. How to avoid that KPI’s drives unwanted behaviors. How we as a leadership team can set the principles and parameters for KPI’s but letting the organization set the values.
  • WS on boosting teams performance using agile
    From Agile and Management 3.0 we can add a lot around motivators for team, self-organizing, what does a high performing Team Environment look like. How should management treat a team to get the most out of it. Team charters and soft characteristics that makes team to hyper perform.
  • WS to increase quality
    From Lean we can learn the stop-the-line mentality, shorten every feedback loop. Look into the journey to Continuous Deployment via Continuous Integration and Continuous Deliveries. In XP we can learn test driven development and a bunch of other tools. 
  • WS on improving a leadership team’s ability to build a good organization
    Applying the high performing team methods and values we derive from agile teams into the leadership team. Lean concepts as pulse meetings and gemba tours, how can they be used? 
  • WS on to get the most out of project managers in an agile development organization
    What is it the teams and development organization needs to get support
    ith from a project manager in an agile environment? Why is it important and what needs to change to get from  “Command, Control and Planning” to “Sense, Adapt and Scenarios”?

…. And on and on, the list can be long.

The recommendation in two statements:

A Workshop in Lean & Agile is for inspiration, education and adapting principles and values

 A Workshop to improve organizations, operations and ways of working should target the wanted result or issue to improve.


Posted in Agile Thinking, Change, Coaching, communication, Framework, Leadership, Lean, Organizaition, Processes, Transformation | Tagged , , , , , , , , , , , , , , | 1 Comment

Radical Coaching -The Ultimate Gemba

Agile and Lean touches values and principles. However, this is not enough. There is more than meets the eye: people, their emotions and feelings. Radical Coaching is targeted exactly towards this; we need to address our inner self and be able to encounter each other as humans and unique individuals. This approach will provide to us an safe environment where we can start to investigate and understand each other in a new way, and where we can continue to work together with much deeper understanding about us. This will result to a situation and environment where we mutually build and work towards something positive and good. It is the essence of continuous improvement, effective workplace and other aspects that will make the great difference.

“A growing and long-living community which is targeted towards the activists of the organization. The goal is to support and empower individuals, teams and organization with change by new means. One sentence to describe it: The Ultimate Gemba!”

We have been busy. Not “busy, busy” but enthusiastic and involved. The reason is simple, we have started to understand how to move into next level. Learning from past, looking into future but living in the moment. When we look at the world around us it is becoming clear: It is happening now, the new paradigm movement. Movement around leadership and coaching that is based on discussing and listening. Person meeting person, out from the roles and structures. To be honest, this is something way bigger and more fundamental than anything I have witnessed before.

In practice we always start with new (small) group with an intensive session. They usually last 48 hours and require intimacy and devotion. We use some simple models and few basic building blocks, like:

Safety. Without safety there is no trust. Trust means mutual approval: both entities allow each other to enter closer. Build safety in. 

Love. Without caring there will not be world-class products and services. If craftsmen do not love their work there is a small probability that it will be a success. Love is all you need.

Enthusiasm. One needs to be active. Emotions spread around so make sure you have plenty of good emotions around you. Try to keep the spirit of child in you.

Miracles. They are the good deeds we sometimes do. More generally miracle is a positive change towards something better. Miracles only happen in dogma-free zone.

How these intensive sessions are then constructed? For individual: in order to embrace change you have to be ready and willing to take new insight into you. This can be helped through intensive training and deep discussions. This happens always in safe context and positive environment. For group: it is good to have a good mixture of people from different areas, ages and demographics. Group dynamics are shaped in 48hour intensive sessions that are led by trainers. After first session the journey actually starts. We support our growth with Spotify playlist (the same songs that we use in the trainings), Google+ community and of course with refill sessions and intensives. No one is left alone and we help each other out.

This is how “managers” meet with “developers”. This is how “testers” understand “coaches”. It is all very natural, logical and it all fits nicely together. Radical Coaching is about You and Me.


Posted in All, Change, Coaching, Leadership, Organizaition, Radical Coaching, Transformation | Tagged , , , , , , , | Leave a comment