Role and responsibility of executives in a lean/agile transition

1) Choose internal change agents carefully

Positive mind and change oriented
Sense of urgency
Capacity for reflection
Working level experience in software development
Transition team covers different project roles and organizational units
Involve line management
Involve product management / business people
Involve process / Quality Management early

2) Be sponsor to the transition team

Give your vision, or agree explicitly to vision and mission of the transition team.
Tell them what the constraints are.
Be interested in plans and results.
Read at least one good book on agile yourself that does not look like a Scrum Bible, but something explaining what may work and why.
Do not expect to have NO impact on project time lines, this is just wishful thinking.
Give a reasonable budget based on estimates of the transition team.
Do not tell them how to make the transition. Rather be able to discuss organizational changes on their request.
Let the team choose external consultants, but ask these people a couple of tough questions before you contract them.

3) Take care about trust in your organization

Do you, and do your middle managers trust your teams to get their job done? This is an essential part of any lean/agile transition.
If you are still not there, expect transparency to grow at the project team level, but you have to inspire trust from the management level. You need to start! You need to express trust to your teams and act accordingly yourself.

Be a role model in applying transpararency – it is needed top-down as urgently as bottom-up.

4) Do not combine a lean/agile transition with negative measures

Especially, do not try to reduce headcount. This is directly counterproductive to encouraging people to share their knowledge.

5) Foster a learning organization

Expect your organization to be on a learning journey for more than the transition lasts. The agile principles expect you to hire the best people, and give them the environment so they can be productive. In traditional hierarchical companies, often people need to learn to learn again. And often the environment consists of crappy old tools that make them slow. You may have tons of legacy code without automated tests. They will not magically disappear at the agile transition. The teams have to learn and improve a lot until they will really feel agile.
You will see improvements very soon, but this is not the end of your journey.

6) Look for opportunities to benchmark your transition with others

As executive you should use your connections with your colleagues from other companies for exchanging with them and creating opportunities for the transition teams and different project roles for comparing and exchanging experience so that you all learn more quickly.

Great places to work: learning from SEMCO

A couple of weeks ago in Karmakonsum, a German blog for eco fair life style and economy, I came across Ricardo Semler and SEMCO – the incredibly successful Brazilian company that is directed mostly by its workers and employees since the 1980es. How did I not discover it earlier? Now that I have read Semler´s book „Maverick“ from 1993, I have found a lot of good things to learn for companies who want to get really agile and lean beyond software development departments.

At SEMCO they have proven it is possible to get rid of basically all kind of bureaucracy, if you start treating your employees as adults.
Written down process manuals are replaced by common sense, expanded knowledge, plus motivation to do your work in the best possible way to make your company succeed. Control and the needed to ask for permission for all kind of small things can be reduced to a minimum, from travel expenses to lunch invitations – if you just ask everybody to employ common sense, and have transparency on the numbers. Transparency is an important part of the SEMCO miracle. All employees and workers have full knowledge of revenue and expenses. This allows them to take meaningful decisions in factory committees, about what to change to get more efficient and make the customers happier. They are also fixing their own wages and hiring their managers. Hey, managers, getting scared now?

Of course such a company also needs leaders. But being leader there is not a question of status and privileges. They do not expect big personal offices and secretaries, but are just full of new ideas and ask nasty questions.

One important human organization principle that the company leaders adopted is keeping the units small: one plant or sub-company should not be bigger than 150 people. Pretty interesting, that Dave Snowdon gave the same number in his ALE2011 keynote asan evolution-built-in human constant for the size of a group a human will be able to identify with.

Democracy and open communication define the SEMCO identity rather than saying they agree in this or that business. There is a lot we can learn from them, if we are brave and fearless. Starting at a huge company may not be as easy, as there are politics around on many levels, and dragons.
What seems more promising to me is starting at a small or mid sized company, where the existing amount of process is not so overwhelming. First I would inspire lean and Agile principles. Software developers are often open to democratic principles, and shop floor workers often already know and apply a few lean methods nowadays. If we then start to engage teams of software and hardware developers, scientists, workers and sales people in how to build better products for the customers, our how to make design or production more efficient, they will sparkle with new ideas.
As people are learning together and get a broader view on the company’s goals and the boundary conditions, they can make good improvement proposals. Then step by step some of them will learn to see the whole, at least to have a bigger interest in the company’s business, and feel responsible for making their work more efficient.

Another book I have read recently is „Delivering Happiness“ from Tony Hsieh, which will get its own blog post: learning how to really, really have company values and use them in daily life.

Our big agile transition at the OOP 2012 Munich

As Agile Transition Lead of our business unit, I have introduced agile project management into a regulated development environment at Siemens Healthcare. The challenge is there to reduce process overhead and improve team member motivation without hampering the necessary quality. Since 2008, I have been starting and coaching Scrum teams, as well as working with the management on transformation of the structure and on communication.

At the OOP 2012 conference in Munich, I presented together with a colleague from the higher management about our agile transition. Here you can find our slideset at Slideshare.

We have gone a long way from piloting to the real big transition, and now after the first big agile project has been successfully finished, there is still much to do in the sense of getting more efficient and having more fun…

Die ALE2012 Unconference ist vom 29.-31.8.2012 in Barcelona

Das europäische Agile und Lean-Netzwerk trifft sich in diesem Jahr in Barcelona – der Termin steht jetzt fest.

Diese „Unkonferenz“, die 2011 zum ersten Mal mit 225 Teilnehmer/innen aus 28 Ländern in Berlin stattfand hat eine besodere Bedeutung für die europäische Gemeinschaft derjeniger, die mit agilen Methoden Softwareprojekte durchführen und die diese Methoden verbreiten. Das Ale-Network hat sich im Februar 2011 auf Anstoß von Jurgen Appelo in LinkedIn gegründet und war sehr schnell auf mehr als Tausend Mitglieder angewachsen. Es steht für ein wachssendes europäisches Selbstbewußtsein in der Softwarecommunity, aber auch für eine unglaubliche Vielfalt von Nationalitäten und Kulturen. Es eint uns alle, dass wir in selbstorganisierenden Teams qualitativ hochwertige Software für die Nutzer herstellen wollen. Dabei reicht das Spektrum der Teilnehmer/innen von Betreibern kleinen Startups bis hin zu Angestellten aus großen traditionellen Firmen, die im Entwicklungsbereich von der Beweglichkeit eines Öltankers zu der von vielen kleinen Speedbooten gelangen möchten. Studierende und Dozenten von Universitäten sind ebenso vertreten, wie unabhängige Beraterinnen und Buchautoren. – Das Spektrum der Veranstaltungen reicht vom Vortrag über Workshops bis hin zu großen Anteilen von „Open Space“, wo Teilnehmerinnen spontan Diskussionsgruppen zu Themen anbieten.
Wir freuen uns auch in diesem Jahr auf viele interessante Beiträge. In den nächsten Tagen wird sich die Programmgruppe das erste mal treffen, und bald können dann die ersten Beiträge eingereicht werden.

Rückblick auf’s vergangene Event:

Agile is about the people!

Sometimes I see blog posts or LinkedIn discussions where some agile specialist or special agilist reasons about the exact amount of minutes to spend on each Scrum meeting according to sprint length, or he asks how he can measure and compare the productivity of teams.
Often I have the impression if I asked him now “How is the motivation of your teams? How do they feel, are they happy or frustrated? Do they have all the tools to get their job done? When did you last time clear some organizational obstacles out of the way for them? Have you hired the right people, and given them lots of opportunities to learn?” or anything alike, this kind of specialist would stare at me without getting the issue.
Actually, this is the centre of the universe – is the people, not the final twisting and tuning of an ideal Scrum process. Scrum is about the people!
Even the managers I know, some managers who have done so incredibly many things right, – even they, at rare times, of course, come up with something like “but now if I would like to compare the productivity of two teams, how would I do it?” and they think very hard about it. 
Then I ask them: Have you invested already enough time into how they can learn something new about the product domain, stay up to date with their architecture and programming knowledge, know how to use the latest tools you have bought them? Have you spent a similar amount of time on how to sharpen the product vision with the Product Owner, so that he can really make developers happy working on this marvellous project? If I wake up a Scrum team member in the middle of the night, would he or she be able to tell me the product vision? Have you thought about organizing a FedEx day so they can try out new features of their favourite programming language just for fun, and get fresh motivation for a couple of sprints?

This is what I ask my managers in such cases. Metrics and measurements are fine, but you always need to seed before you harvest.
Hey, it’s about the people!

An incredibly intensive 1st ALE2011 Unconference – Agile and Lean Europe in Berlin

 (Olaf Lewitz, one of the central organizers, on a photo by Marcin Floryan)
In February, 2011, the Agile and Lean Europe network was founded in LinkedIn by Jurgen Appelo, Author of Management 3.0. He asked the European lean and agile practitioners and communicators to join. We were about 1000 members within a month, and there were lots of active interesting discussions, “bathtub conferences” and many ideas how to collaborate more closely. The first real-life meeting happened at XP2011 in May in Madrid. Since then, 47 people with a vision created the best and most intense (un)conference I have ever attended. My own role was to be part of the “industry sofa” – we had “sofas” instead of “chairs.” I spent some of my free time reviewing abstracts and finding out whether these people were good speakers, if I had not heard them speak before. The final result we composed is amazing – .

    The audience was amazing

All further work was organized via real-time collaboration tools: Skype, Basecamp, GoogleDocs, Mindmeister, Twitter, and Conftool. Real-time mostly meant evenings, sometimes even weekends. The final event structure included one keynote every day – with Rachel Davies, Bjarte Bogsnes and David Snowden, we had three highly interesting speakers, two of which are not from the software world, but are teachers of lean concepts for management.  Each day started with a funny coding dojo warm up, followed by 30-minute talks in the morning, lightning talks after lunch, and Open Space all afternoon. Virtually everybody participated actively in something: more than 220 people from at least 27 European countries. Talk topics ranged from “Software Craftmanship” and “Metrics in a complex world” to “How to change the world.”

Bjarte Bogsnes from Statoil, Norway
For me, Bjarte Bogsnes with his “Beyond Budgeting” talk was most inspiring ( ), but… yes, but… the 7 levels of hierarchy between me and the CEO of our company make me think that this is not the easiest thing to put into practice by myself. Fortunately, many other talks also had inspiring contents!
From Henri Kivioja from Ericsson, Finland, I learned how we can guide managers to practice go and see with the Scrum teams: they just got rid of all kind of upward reporting from project to line managers. They also reduced their full test cycle dramatically, from about 1 year for the whole system (100%) to about 1 week for 90%.
dojo2Eva Kisonova and Sabine Canditt presented a funny game of cultural differences they have practiced with our Scrum teams in Slovakia. It showed the stereotypes that may exist on both sides, which can make collaboration difficult if the teams have not reflected on them. Putting it into practice in a small example among the participants was really fun.
Rob van Lanen explained why and how they had realized FedExDays with his company’s developers in the Netherlands. This is a 24-hour slot, in which the developers can develop whatever they want – the only condition is that they must present it after that time. The department provides food and drinks, and the CEO is present at the demo at the end. The participants created 4 products, a traffic light tool for the software build, and a gaming application. They self-organized to do Scrum in one-hour slots and even pair programming. It was a great motivational boost for the teams.
Claudio Perrone gave an excellent introduction to A3 and Kaizen, which can actually be understood when you look at this outstanding presentation: In this way, continuous improvement can be introduced on all levels: in the project team and on organizational level with the managers. This is something we should put more emphasis on soon.
Torsten Kalnin explained how the Wikispeed team builds modular speed cars using very little fuel with lean and agile virtual collaboration of volunteers around the world – an amazing example for agile hardware development – see also at
I visited a few more talks related to big agile transitions, offshore and distributed experiences, which we later followed up with discussions in the Open Space.
Open Space facilitated by Mike Sutton
The most intense part of the unconference was surely the Open Space sessions: everybody posted his/her topics at a common marketplace, and there were a lot of different spaces in the venue where we could start discussing around a flipchart. On the first day, I proposed a talk about organizational impediments, to get stories of what happened and how people actually resolved them.  Later, I was in another big agile transition discussion, and there I met a couple of people who also used communities of practice in their companies. So I had my topic for the next day: how to get CoPs going, and how to keep them alive in their original sense, as a means for knowledge acquisition, best practice exchange, and as a catalyst for improvements.
You can find almost all references from the conference in two places: and with #ALE2011 on Twitter. A lot of lean and agile conferences in the next future will be powered by the spirit of the ALE-Network, I am sure! 
DSC_6380 ivanKostial JurgenAppelo respect4people
Andrea Heck

Wie viele Engel passen auf eine agile Nadelspitze?

Manchmal lese ich Einträge in agilen Diskussionsgruppen, die mir gelinde gesagt etwas ab vom Thema erscheinen. Da rechnet jemand vor, wie man die exakte Länge jeder agilen Sitzung abhängig von der Sprintlänge berechnen kann. Oder jemand fragt, wie man nun die Produktivität von zwei seiner Scrum-Teams vergleichen kann, welches denn besser ist. – Ob es irgendein Tool oder eine Metrik dafür gibt? Hat jemand Erfahrung damit?

Bei solchen Einträgen frage ich mich schon, wie es um die Motivation des Fragenden bestellt ist, und wie weit er eigentlich die Prinzipien von agiler Softwareentwicklung verstanden hat?

Ich würde ihn rückfragen: ob er denn weiss, wie motiviert seine Entwickler/innen sind? Ob sie in ihren Retrospektiven in letzter Zeit spannende Dinge zum Verbessern gefunden haben, die sie produktiver gemacht haben? Ob er irgendwelche organisatorischen Hindernisse in seiner Firma oder Abteilung kennt, die er vielleicht selbst für die Teams wegräumen könnte, damit sie noch motivierter und noch produktiver arbeiten? Ob die Teams mit der Vision, die sie von ihrem Product-Owner bekommen, zufrieden sind, ob sie so anschaulich ist, dass sie sie auch um drei Uhr nachts noch sagen könnten, wenn sie jemand aufweckt? Ob die Entwicklungsumgebung, mit der sie arbeiten (müssen) so geartet ist, dass sie ständig im Fluß bleiben können, oder ob sie doch öfter Kaffee holen müssen, als sie eigentlich möchten?

Wenn so ein Manager oder Consultant insofern seine Hausaufgaben gemacht hat, dass er all das weiß, weil er so oft wie möglich in der Nähe der Teams ist, direkt von ihnen hört, was die Probleme sind, und alles, was man grundsätzlich in der Organisation lösen muss, zumindest angeht, Fortschritte erzielt hat, und den Leuten die Mittel zur Verfügung gestellt hat, um die richtig heftigen Probleme zu lösen – dann, ja dann, dürfte er solche Fragen stellen, aber dann, bin ich überzeugt, will er es gar nicht mehr. Braucht er nicht mehr – dann ist es einfach eine Freude, den Teams bei der Arbeit zuzuschauen, denn dann stecken sie voller intrinsischer Motivation.

Organizing ALE2011 unconference with 47 agile and lean colleagues

How I happened to sit on the Industry Sofa

Nearly at the end of the XP2011 Conference in Madrid, I stood in the garden together with a few colleagues from different countries and different companies to say goodbye. We talke a bit about the new ALE network we were all in some way participating in it, and at some moment, Olaf Lewitz said something like: „let me summarize the results of this session shortly…“ and someone else said, „oh, we are actually in a session?“ – and it turned out that this had started as a follow up on the session about planning the brand new ALE 2011 conference, which would take place this time in Berlin but it was supposed to tour through the European (= European Song Contest member) countries.

He listed the current state of „sofas“ that were planned, instead of the usual „chairs“, putting the emphasis on the collaborative way it was going to be planned. – I said I was missing an Industry Sofa, for getting enough really interesting industry speakers into this new conference. Oh yes, – why don’t you actually take it yourself, you have a lot of industry contacts?
So this is how I happened to occupy the Industry Sofa, and before I finally left the venue, I convinced Ken Power from Cisco/Ireland to share this sofa with me, and I still thought a third member covering perhaps Eastern Europe or Scandinavia would be great.

When I arrived back home, I already found Olaf’s blog entry „
I am organizing a conference“ and saw our „Industry Partner Sofa“ listed with all the others – oha! Some work to be done!
Very quickly, also the basecamp accounts were set up by
Sergey Dmitriev in Norway, and a group of people started to fill the conference website with all the infos we have already agreed on.

Decisions with 47 distributed organizers

I have to admit that it is sometimes very difficult to find out whether something that has to be done is actually done by someone already, or if a decision has been taken finally, or who are all the people that have to be asked to get to a final decision about something. Every day I am going through quite a couple of mails in different threads, mainly on my mobile, when I am sitting in the train coming back from work.

But as all the organizers are agile and lean people, it is quite less stress than I had thought a few days after start. We managed to post the Industry call for papers as quickly as needed. I sent the call to many people I know personally, and so did the other sofa members, Will Gill (Australian at Nokia in Berlin) who joint us the next day, and Pierre E. Neis in Luxemburg.

We found way to distribute information quickly and also have people quickly decide something. For example, the deadline shift this week was decided through a Doodle sent around to everybody, ending 24 h later. To get and share info directly, there are Organizers Skype calls every few days.

It is very interesting and challenging. Of course, a week before the deadline for submitting talks, there were only about 3 contributions. But on the second last day, we had 36, and on the last day, after we had decided to extend by one week, there were already about 50. WOW!

Now we are all reviewing and commenting. – Still, there is nearly a week left for submission of new talks.

XP 2011 Open Space session: Teaching TDD to a Team so that it sticks

On XP 2011 conference in Madrid, I invited to an Open Space session named „Teaching TDD to a Team so that it sticks“. I stated the problem below, and a couple of interesting people showed up and gave very helpful hints, among them Charlie Poole, the inventor of NUnit, as well as Patrick Kua and Alexandru Bolboaca. I have integrated some hints from an earlier discussion of the topic with Emily Bache and Johannes Brodwall at the ACCN in Oslo.
The problem description:
Let’s take a couple of Scrum teams who have already been doing Scrum for a while, but are still lacking some technical practices. Agile coaches are convinced that Test Driven development (TDD) would help them create better and more solid code.
Some have had the opportunity to attend a TDD or XP in general training session, but only very few have taken back something to their work.
What could be the reasons for that?
·         TDD is not intuitive, but you have to practice a time to overcome the first problems
·         If they are the only ones in their teams, it is difficult to stick to it, not having whom to ask
·         There is also pressure to take on constantly work from the product backlog, and work will be first slower than without TDD – they need the consent of their Product Owner
·         Maybe it has not been communicated enough that management and Product Owners would tolerate some initial productivity loss, and at which time
·         The examples from training were easy, but the own project is really hardcore programming J
·         In some project setups, it may not be the same developers who profit from good code, as bugs are corrected by someone else => no closed feedback loop

How can we now bring a good training/coaching solution in?

·         All participants should be voluntarily doing the training
·         The training should be done focusing on one team at a time
·         The training can be 2 or 3 days off site – not in the normal work environment
·         To explain TDD well, code examples that are not from the own project are used at least the first 2 days
·         it is helpful if code examples are from the main programming language that the participants are using
·         The proper UT frameworks need to be installed on the developers‘ machines when they are starting
·         A code retreat could be used for the first phase – this is a couple of developers sitting together and working on the same problems several times, deleting the code in between – outcome is that it is reasonable to create good maintainable code
·         A coding dojo is also a good technique – a group of developers solving a problem, doing TDD, but only one pair at a time will actually work on the code, while the others can look on the projector, and one dojo participant will change from time to time
·         After the participants have some good idea about TDD and first practice, it will be good for credibility and transfer to their own work to look at some own code examples from the team’s real life project
·         The trainer needs to prepare for that, so he/she can work with that code
·         The workshop needs to bring the mindset change to “it is fun working with TDD”
·         After the initial training,  there must be an agreement with the Product Owners how much time can teams spend per week/per iteration on practicing TDD
·         Follow-ups take place in the normal work environment: coach pairs with people in a team on real programming problems
·         From time to time a code retreat or coding dojo to learn more interesting things (refactoring, cleaner code) and practice TDD in volunteer group will lead to strengthen the practice and amplify the learning

XP 2011 conference in Madrid: report of a newbie

Well, I have to admit that while I have been attending and even presenting on a couple of software conferences in the last few years, it was the first time I visited an XP conference. It was kind of that the idea struck me early in April 2011: there is an XP 2011 conference going on inMadrid, soon, they will talk about globalizing agile – this is just what I am doing in my daily work and what I am interested in, and on the other hand, XP means technical agile practices, and this is what our teams still need to develop more.

The intutive decision turned out to be quite good. I met many interesting people – some of the already known from ocasions like the AgileEastern Europe conference in Kiev, the Scrum Gatherings in Stockholm or Munich, or small events like the Agile Coach Camp Norway, or even from Siemens-internal agile conferences some years ago. And I met quite new persons, at least for me, who enriched my view of the agile world.


The XP conference seems to build a unique link between industry practicioners and university investigators. It is great to see how the Master or PhD students profit from the direct discussions with people who have global agile experience in the industry. On the other hand, it gives the industry people quick access to new research results.

There are several topics where I found particularly interesting information:
  • Agile and Leadership – here to mention the keynote from Esther Derby and the presentation from Jurgen Appelo
  • Industry reports – Even the ESA converted from waterfall to agile, as reported by Rui Santos and Marc-Elian Begin. In companies, I have now seen several times seen the agile release train by Dean Leffingwell applied – also in the report by Gabor Gunyho from F-Secure.
  • Agile coaching – a very practical workshop with Patrick Kua I had the pleasure to particpate in.
  • The initiative for creating a vision and rules for the recently born Agile and Lean Europe network (ALE) – and a lot of activites following up, including a new conference rotating through European countries, starting September 7.-9., 2011 in Berlin.
  • And last not least the results of my open space inquiry about Teaching TDD to a Team so that it sticks.

I will follow up to these topics with separate blog entries in the next couple of days, starting with the TDD open space.

(photos by Hubert Baumeister)
%d Bloggern gefällt das: