„Creating an agile learning experience for managers“ – presentation and workshop at #XP2017 conference in Cologne

The agile transition of DATEV‘s product development organization has started.

DATEV was founded in 1966 by a visionary tax consultant as a common IT backbone for himself and his colleagues. The then recently emerged mainframe computers promised to solve their common need for correct calculation in a world of increasingly complicated and ever-growing legislation. – This bold idea transformed the initial startup into a constantly growing company in form of a cooperative – the main customers are also the owners of DATEV, therefore it is called “DATEV eG” in German.  Today,  40 000 tax consultants in Germany are DATEV members. 12 million employees get their monthly pay slip via DATEV software. The members use DATEV’s financial accounting software on behalf of 2.5 million small and medium sized companies. DATEV’s own financial numbers have been in the black every single year since its foundation.

The customer feedback has been positive over many years, with software solutions which are not always easy to use but contain the correct implementation of complex legislation. Now we need to evolve towards new web based products which will support the digitalization and automation of the members’ daily workflows, as well as providing faster customer and market feedback cycles. So the purpose of the agile transition should be clear, yet it is not at all easy to create a sense of urgency among the middle management considering the success story that is still true today.


In 2016, we created a learning event for the approximately 200 middle managers. We designed a two day event with two main goals:

  1. The managers should understand the challenge of DATEV’s digitalization strategy
  2. They should learn that an agile transformation is needed in order to support this strategy and that they would play an active role in it

The methods we used for this event were a combination of:

  • Very short speeches by the top management supporting these goals
  • An information market where the first projects in which prototypes of new digital products had been created were presented in a self-organized way by team members of these projects
  • The managers selected the most important obstacles these projects were facing, to be solved by themselves, and started working 
  • A retrospective-like setting in which the managers analyzed and started to develop solutions to these problems
  • The whole event was facilitated by team members who were recruited from the company’s in-house agile community

The outcomes of this first event were three working groups working on the most important obstacles according to the voting of the managers, and a quite positive feedback.

The overall concept of the two-day event was rated between very helpful and not helpful at all – in 6 steps. More than 80% of the participants chose the two best ratings. They were especially pleased with how well the event was facilitated by the team members.

One feedback given during the event to the top management was that direct communication with the team members must take place more rapidly.  The top management promptly put this into practice on the second day of the event by  finding and announcing a date for an information event for all 1800 team members.
All three work groups working on the top three problems developed results in the following weeks, which were presented and discussed in a second event. The third group working on “goals, metrics and a master plan for a complete agile transition” initiated a thorough analysis of the situation, resulted in the top management forming an agile transition team and calling everybody to action during the second event. There all sub-organizations started their own agile transition teams and plans.

Still the development organization as a whole is overburdened with work due to a big upfront planning process in which all of the work for one calendar year has been defined and estimated and committed by the management until July of the previous year. This was the fourth problem addressed by top management itself. A team worked on this process during the next couple of months, with the goal to rely on rough roadmaps instead and to introduce three-monthly portfolio planning cycles. Now in a third event end of April 2017, we have worked with the managers on this topic in order to get everybody into re-defining their current product development goals so that they can be measured and sliced down into smaller sub-goals which result in deliverable slices of products. 

Interested? You can here more about it on Thursday May 25th  in my „Creating an agile learning experience for 200 managers“ presentation and workshop with Christina Busch at XP2017 conference in Cologne.

Scaling Agile with Frameworks – a SAFe path to LeSS work?

Ok, I admit right away that am just fooling around with the names of the two known large scale agile frameworks in the title – SAFe is the Scaled Agile Framework by Dean Leffingwell and company, and LeSS is Large Scale Scrum by Bas Vodde and Craig Larman.

The first book I read about scaling agile was from Dean Leffingwell, in 2007. I met Bas Vodde at my first Scrum Gathering in Stockholm 2008, and after I heard him talk about feature teams, I bought the book about scaling agile by him and Craig Larman as well, and of course we tried to apply much of that during our agile transition at Siemens Healthcare SYNGO. The book came very helpful since it clarified many of the questions behind the simple mechanics of agile, e.g. which effects queues have on you development organization, or how should the organization structure adapt to agile, and which other topics or areas beyond R&D are concerned.

In the last couple of months various people kept asking me about “Should we apply a large-scale framework to our agile transition?” – and asking back I get the underlying questions, of course, will we be faster, safer, cheaper, avoid start-up problems, will we have to read less stuff and discuss less if there are solutions available online and even people rolling out the one or the other framework licensed by the respective framework’s prophet(s)?

OK, let’s see if they themselves come with a warning message, like the drugs do in Germany, a little paper full of text that is in each box.

 

LeSS

„LeSS is not “new and improved Scrum.” Rather, it is regular Scrum, an empirical process framework in which you can inspect and adapt to any method and work in a group of any size. Large-scale Scrum is a set of additional rules and the set of tips that we have seen work in large multi-team, multisite, and offshore agile development initiatives. These tips are experiments to try in the context of the classic Scrum framework.“ (http://less.works/less/principles/large_scale_scrum_is_scrum.html)

 

SAFe

The Scaled Agile Framework (SAFe) is a proven knowledge base for implementing agile practices at enterprise scale.” “We, the contributors, offer this web version to the market in the hope that it will help all software development practitioners and team – as well as their employers – enjoz the satisfaction that comes from delivering ever-higher quality software at ever-faster speed” (http://www.scaledagileframework.com/about/)

OK, sounds good, but how can people start using it?

Now I switch to the “Implementation” page of SAFe: (http://www.scaledagileframework.com/implementing/)

Implementation is done in three steps, which come with lots of training and certification with trained and certified SAFe trainers: step 1 Change Agents, step 2 Management & Executives, step 3 teams and agile release trains – challenging, in 5 days per train, 8-12 Scrum teams per release train. Maybe it is intended for different kinds of enterprises than those I know, which have a lot of legacy to reflect about: structures, processes, products, codebases… and include properly into their new setup, so that they can go on delivering something to their customers.

 

So what do the LeSS guys say about implementation?

“These principles are crucial to an organizational LeSS adoption:

  • deep and narrow over broad and shallow
  • top-down and bottom-up
  • use volunteering”

“Prefer applying LeSS in one product really well over applying LeSS in many groups poorly.

Focus LeSS adoption effort on one product group, give them all the support they need, and ensure they work really well. This minimizes risk and if you fail it triggers a focused learning opportunity. And when you succeed it creates a positive “word on the floor” that’s vital nourishment for further adoption.”

And so on. I could not have phrased it better.

It reminds me of what a manager from another big company reported last year: lean and agile transitions worked great in their organizations which had self-chosen to transition with a mixed bottom-up/top-down approach, and where there were convinced local coaches. It did not work at all in organizations that were made “lean” through a big top-down rollout.

Frankly, I cannot imagine that any internal coaches who have neither seen nor done any agile work themselves, in product development teams on the ground, can be of much use in a large-scale rollout. So you need to start small, experiment, learn your own lessons.

By the way: yes, the LeSS guys are also offering trainings and even certifications. I would recommend to send people there who are already such local agile practitioners and have either worked in an agile team themselves for at least one year, or have been active participants in a transition team at smaller scale for at least the same time, and take the course in order to know more and improve, or roll out to a larger part of their organizations.

Don’t get me wrong: I think the SAFe framework can also a great source of inspiration and hints for solutions for organizations going agile in small or large-scale. I remember that we had a problem with making the product owner team feel responsible for prioritizing technical debt and technical improvements high enough, and we found a good example in SAFe how this can be solved: by agreeing on a percentage of the organization’s velocity dedicated to technical improvements by mutual agreement between architects and product owners, and then prioritization of actual technical backlog items by the architects.

Then only thing that I am very convinced about is that you cannot buy a large-scale agile transition, you do have to do it yourselves.

The hardest job in a lean/agile transition is with the managers

When you are doing a lean/agile transition in a traditional organization, definitely the hardest job is related to the management.
I already highlighted the role and responsibility of executives in a lean/agile transition in another post two years ago. The people on the working level get into their new roles and practices. They are constantly doing retrospectives and improving their work, and even driving improvement through the organization. They experiment, get feedback and learn from it.

Now what will the middle managers do when they are not frequently needed for fire fighting in the projects? How are they going to practice new skills and habits that they need in the new agile world? And how much of the newly created trust and self-organization can a manager destroy with some harsh enquiry to a team?

At the beginning, many of the managers are obviously more or less engaged in the transition itself. Managers will also sit together and find out how they can coach teams, how they can help people to grow, and how they should do now hiring, performance evaluation, and distribute salary increases and bonuses under agile circumstances.

However, also during the transition it is easy to stay in a command-and-control mode or at least frequently fall back into it. After that, it is getting worse. Managers are moving around in organizations, some leave the place, others join. These others may be joining the company or department for totally different reasons than wanting to be a servant leader, a coach for growing people. Maybe they just want to work in this area. Period.

Now we need practices by which the managers stay constantly engaged with lean and agile ideas.

Act-Your-Way_into_new-Thinking-640

One of these topics is Continuous Improvement. It is one of the two pillars of Lean. Hakan Forss explains this is his Toyota Kata presentation – see slides or video.It starts with a common vision for the process of the organization that can probably never reached, and realistic but challenging goals on their way there. Then a team or several teams are improving by experimenting with small changes towards a next target condition, in turn with measuring the results. A lot of learning is involved in this, for the participants as well as for the organization.

Managers can be part of a team for changing things, especially above the level of a single agile team, for solving organizational problems, problems with processes and tools – always following a common vision with the teams, of course. Or they can also train to be a coach for doing this change. Of course, they have to take care like any other coach, that they have practiced the improvement kata themselves often enough, probably with an external coach, before they try to coach someone else.

Managers need to study and practice lean values and practices that they apply to their work with the teams. This can happen in self-study groups with the other managers, and everybody applies it individually. The challenge is always how they are getting feedback to their behaviour.  A good starting point may be the book Management 3.0. by Jurgen Appelo, that give some backgrounds on how a team behaves as an adaptive complex system, and how to grow a team, how to stop demotivating it, and how the boundaries influence the behaviour. His new Management 3.0. Workout book has a lot of tools that managers can apply, from the kudo box to the delegation board, ready to use or to adapt to their organization. By using these tools they slightly change the way how they are treating teams and individuals, expression more respect for people, which happens to be the other pillar of Lean.

Apart from using lean and agile practices in their own work, managers should also do the famous „Gemba walks„. This means going to the people who are actually working, and listening to them, e.g. during their daily standup meetings. The main challenge here is to do it without disrupting or frustrating the teams, e.g. by listening to two sentences and then throwing in an „easy solution“ to a problem without having enough knowledge for really helping them. Instead, only when the team seems to be clueless they can ask a couple of good questions for enabling them to find a solution themselves.

I am curious to learn in which other ways companies get their managers into „lean mode“ and keep them actively thinking lean and practicing lean.

Agile India 2014 Conference – large scale distributed agile development

AgileIndia2014_LogoBig
For 10 years, the Agile Software Community of India has been holding this conference now, with ever growing numbers and great names from everywhere. With more than 1200 participants, more than 250 of these from other countries than India, extending from Norway to New Zealand, from Indonesia to Ukraine, and more than 300 women, Agile India 2014 was a huge and really diverse agile conference.
 In the previous years, I had already received positive impressions from the colleagues in Bangalore. This year I had the pleasure of participating for the first time myself, presenting the story of our Distributed Product Owner Team for an Agile Medical Development. The process of selection of topics and feedback was very well prepared and community based. While everybody could see the proposals, ask questions and comment on them, the members of the program committee took care that this would happen consistently, and did a lot of it themselves as well. For the topics selected by them, also an extended paper was necessary with a case study, which also underwent a feedback and approval process, in my case by Ravi Kumar and Pramod Sadalage .
During my presentation

During my presentation

Fortunately, I had work to do in India as well – start up trainings for a few new Scrum teams at our company – so I already had the justification for going. On the other hand, I had enough work to do so that I could not consider going to the other conference days, apart from the one I was speaking at. So I can only talk about the Offshore Distributed Agile track.

Todd Little presenting

Todd Little presenting

I enjoyed Todd Little’s keynote in the morning very much. One of the key messages that resonated most in me was „We need to treat remote teams not as coding monkeys but empowered Ewok.“ I hope as software specialist, you are familiar with the Star Wars universe and do not need to look them up in Jedipedia.Todd said exactly what we are trying to do in our big, distributed product development, and my mission to Bangalore was part of it: make the remote teams self-organizing, trusted members of our diverse product development universe. Only that in Todd’s presentation, it turned out that he only needed to add a few software developers with a domain specialist in Romania and a small test automation specialists’ team in Vietnam to his original group in the US – and they were already very successful. So: adding the right people for a good reason, valuing the individuals over corporate strategic outsourcing strategies.

The other talk I remember well was from Rajkumar Anantharaman from Intel, who stated „If you want to go lean and agile, first you need to get rid of Excel and PowerPoint“. This was of course not aimed at a nice PowerPoint by the Product Owner showing some functionality the users ask for, but at getting rid of the additional reporting needs that keep teams busy with overhead.
The venue was a bit resisting the actual number of people participating, it is certainly difficult to predict, but maybe another year they will be better off in a congress center. A difference with the European agile conferences I have been attending like ALE or XP was certainly that there were much more business-people than agile coaches hugging each others. Maybe even most agile coaches look like business people in Asia. In all cases it is very important going to India and seeing what is going on there, noticing how people discuss, what they hold as granted in agile, and what they have still doubts about.
At the panel discussion with Doc Norton (groupon) and Chad Wathington, ThoughtWorks Studios

Participation in the panel discussion with Doc Norton (groupon) and Chad Wathington, ThoughtWorks Studios

More or less, the other speakers confirmed what I have learned from our own experience: there is not the question whether or not agile is going to work with distributed organizations and teams in India, but how to make it work. You can do a pretty lot of things right or wrong, and even terribly wrong, but you can just as well be successful if you are doing many things right.  At the end of the track, there was a quite interesting panel discussion facilitated by Naresh Jain: Offshore Agile…An Oxymoron? There were a lot of interesting topics discussed. Where I could definitely contribute was when someone asked the panel whether they could just take a framework like SAFE and apply it to a big distributed product development organization to make it agile. According to my experience, though such frameworks can help, every organization has their own challenges, their constraints, and their organizational culture. Whatever lean-agile framework they will build, they need to build it on their own – but of course, taking as input the experiences of others, and agile frameworks as well as wonderful books like Bas Vodde’s and Craig Larman’s „Scaling lean and agile development“.
Photos used by courtesy of  Agile India (c)