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)