Thursday, April 25, 2019

Results-Only Work Environment (ROWE)

Recently I have been doing quite some reading on remote work. In one of the books I was reading, the author suggested adopting ROWE to make remote work easier. I had heard about ROWE 10 years ago but then almost forgotten about it. It sparked some thoughts and after brief conversations with Henning and Stefan, I feel these thoughts are worth sharing.

What is ROWE?

ROWE is, of course, an acronym. It's short for "Results-only Work Environment". I am not going into details or the history of the concept - this blog post by Steve Nguyen gives a good overview.
The basic idea of ROWE is pretty simple: Results are all that counts. It does not matter when people work; it does not matter where people work; it does not matter how people work - as long as they deliver the desired results.
It‘s easy to understand why this concept is appealing to Agile folks: It gives a lot of autonomy (back) to the employees and frees them from micor-management and stupid policies. To my understanding ROWE was developed as an alternative approach to being paid and evaluated simply by how much time someone spends in the office. That surely makes a lot of sense. And it explains why ROWE got quite some traction in government agencies and big, old-school corporations.

Problems with ROWE

We all want great results. So what‘s not to like? Reading through some articles, the main areas of criticism seem to be that a) It‘s very hard to create a shared understanding of the desired results and how to measure them; and b) contrary to proponents‘ claims, ROWE does not always reduce working long hours. Some studies indicate it can have the opposite effect and actually harm work-life balance even more than traditional work environments (see "the Risks and Obstacles of ROWE" in Nguyen‘s post for sources).
These concerns sound legit to me, but in this blog post I want to stress a different concern, that is probably as serious as the ones already mentioned. I use ROWE as an example, but the critique holds true for any kind of hands-off management that focuses entirely on results/targets. My main concern is:

ROWE totally ignores methods and therefore makes organizational learning very hard (if not impossible).
 
Imagine you are running ROWE in a small company. You as a CEO are quite happy with the results. Your clients are also happy, and you earn a lot of money. Now you want to grow the business and hire a bunch of new people. How do you onboard them? Sure, you can agree on desired results with them and hope for the best. But chances are that at a certain point you will not be happy with the results anymore. What do you do now (other than fire people, because they are "under-performers"? How do you train people, if you have no understanding which methods work in which situations and which don‘t? How do you make sure co-workers will learn from each other, if there is no structured conversation about methods? Learning and scaling the business becomes incredibly hard in this situation. And for employees who struggle with their work (for whatever reason) it becomes very frustrating, because there will likely be no structured mentoring.
And it gets worse. Deming advised managers always to ask "By what method?" whenever someone bragged about their achievements. He stressed the importance of a solid method you can learn, teach and iterate on. If you don‘t do this and purely look at results, you are rewarding luck and unethical behavior.

Conclusion

Yes, we want to keep methods as lightweight as possible. But let‘s not throw out the baby with the bath water and abandon them all together. Without solid and explicit methods there will be no organisational learning, and personal development of the employees will be sub-optimal. ROWE might sound appealing at first glance, because it emphasizes individual autonomy, but it does exactly that: neglecting the methods that can (repeatedly) lead to great results.


P.S. If you liked this blog post, you should check out my post on company structures.


Tuesday, March 5, 2019

Lean-Agile Roast: SAFe

I know Erik and Håkan for almost ten years now, and they both have an impressive track record of Lean and Agile. Not only do they deeply understanding the concepts, but they also are true practitioners and have driven substantial change in various big organizations. Since I have moved to Stockholm in 2017, we get to meet and talk more regularly. In several of these conversations we touched the pros and cons of the SAFe Framework. We agreed that we would need a longer discussion to properly discuss the topic, so I invited them, and we recorded our conversation, which went on for over an hour. When we had drinks later that evening, Håkan said that he felt like he was been roasted (of course in a very friendly, a very Swedish way). Although this was not our intention, we all agreed that it would be a great concept:-) So I give you the first part of our Lean-Agile Roast on SAFe. You can check out part two of this Lean-Agile Roast on Erik's blog and part three on Håkan‘s blog.
If you prefer to listen to the whole conversation, you can download the audio file here.

SAFe: A big bowl of candy? (Image credit: Wikipedia)
Arne: Welcome, Håkan and Erik to our little conversation about SAFe. I'm happy to have you here. I would like to start with a question for Håkan. A lot of people from the Lean/Agile community are kind of suspicious about SAFe and you have just become a certified SAFe trainer. How come?
Håkan: Yeah that's right. I was moving to a big Swedish insurance company and they had taken some initial steps in that direction. And from a personal point of view a lot of the principles and the values that are stated in SAFe are something that I totally agree with. So therefore I didn't have any problem to actually explore being a trainer and help train people around us, because I think if you train them with a focus on principles and values then the method would follow as you learn more and more.
Arne: I believe this has been about six months. What have been your experiences so far?
Håkan: I'm really impressed by the depth of the material. I might not agree with all the details but there's a lot of intellectual property that is really useful to get started. And also there is what is called the implementation roadmap. In there it's described how to actually do the implementation, which has been very helpful to hold people back and not just throw themselves into the implementation without learning first.
Arne: Erik you have been more on the other side of the spectrum, when it comes to SAFe. What are your concerns?

Erik: Well, I think way back SAFe and I got off to a bad start. It wasn't even called SAFe at the time. This was in 2010/2011 and I was a big fan of Don Reinertsen, the author of Principles Of Product Development Flow. He recommended us at the start of our Lean/Agile transformation journey to read Leffingwell's book Agile Software Requirements. So I started reading it, but I couldn't finish it! And that very seldomly happens for me that I can't finish a book. It was not to my liking, not to my taste. So we got off to a bad start and we took a different path to scaling. Our ways of working with large scale Scrum systems was inspired by the Lean community and by Kanban -- we were always trying to learn and to get inspiration from several sources. I found the book a bit dogmatic and it felt like a bag of goodies: a lot of good stuff but no consistency, no real depth. And it was hard to get to the essence, that was my initial impression. But bear in mind: I see a lot of skilled people who know the principles, and they work with the SAFe framework and they get it to work really well. So if you know what you're doing, if you're a practitioner and you know the principles I guess you can make any framework work. Because then you start from the needs and you start from from your context, and then you tune and tweak the framework to suit those needs.
Arne: When I prepared this conversation I remembered that Schiller once reviewed a book and wrote: “This book contains many new things and many good things. Unfortunately the new things are not good and the good things are not new.” And I was thinking you could say the same thing about SAFe: It contains many new things and many good things. But the new things are not good. And the good things are not new. Does that make any sense to you both?
Erik: I think that's a very interesting summary. I have to admit that I haven't dived into all the details or taken any training. So I've looked at it from the outside. Still, I've seen a number of companies, that were on their journey and talked to people, who were part of that journey. Your description seems fairly, consistent with what I hear. Håkan, I would like to hear your view on that since you're in this now.
Håkan Yes I think there's not a lot of new stuff in there.
Arne: Is there valuable stuff in there?
Håkan: You could say it's a framework that embraces everything that has seemed to work at some point. Which could be a problem. But it also actually puts it together in a way that it should work together, if you actually are using the principles and the values. From my point of view there is nothing that is really, really new and SAFe is just a way to communicate the ideas to an audience that is not necessarily knowledgeable about this area. If I go to the CEO of my company, they might not even know the concepts of Lean and Agile, but you can talk to them around this material in a way that they understand what it could potentially look like in the future.
Arne: Why do you think SAFe is so successful.
Erik: I would say it's very neatly packaged. It comes in a box and it's very easy to explain to upper management. And it solves a real need. It fulfills a real need to deliver faster and that's a legitimate need. I really think it is. In that sense it helps a lot of companies that would otherwise struggle quite a bit.
Håkan: And I think one of the biggest values that it brings is that it is great in communicating the ideas. So there's lot of good stuff and it's well presented, so you can just use it and you don't have to reinvent the wheel. You can take the ideas and build on it. And that's been a great support in many situations, where you might not yourself have developed the training material around a certain area. There's a lot of help from that framework itself.
Arne: We had a conversation this morning at the Stockholm Lean Coffee, where we discussed the idea that maybe the main purpose of SAFe is just to help organizations deliver big projects or programs. And this it does really well. So if you look at it this way it's a really good tool. But a lot of people are assuming that what it should be doing is also enabling an organization to develop their own ways of working. And this is probably not what SAFe is intended to do. Would you agree with that?
Håkan: You could say something similar about Scrum, right? So from my point of view Scrum has one rule that rules them all, which is inspect and adapt. So I'm someone, who would say I'm a very proud Scrum-But. And I think that's the same idea about SAFe. There are built-in mechanisms to actually adjust and make changes. You can change the core values and principles as well, as long as you are actually doing what is in that rule which rules them all. You should always inspect and adapt. I don't see a problem in that sense.
Erik: But isn't there a risk, since the SAFe is such a big framework, that this fundamental rule gets lost, because you see all the other good stuff? And then you might miss out on the fundamental thing, which is to inspect and adapt, the improvements, the continuous learning. All those things. Because you're so busy just understanding and grasping the framework that is so big.
Håkan: Sure. But then there's a lot of material that prescribes the kind of meetings and so on in a similar way as the Scrum framework would do. One important part of that is that you should measure things - that you should evaluate at the end of the Program Increment (PI). And you should look at the bigger picture and optimize the bigger picture and not the individual parts. So if you actually are following a lot of the material that is described, you are at least on a path of that learning. But of course you can get lost just like you can get lost in just doing Scrum by the book and not applying inspect and adapt.
Arne: Would you say that the one rule that rules them all is the same in SAFe: inspect and adapt?
Håkan: Yes I would.
Erik: Would the C-suite also formulate it that way? If you would ask that question to upper management, what would they answer? Why would they use SAFe? Is it because of inspect and adapt, or is it for some other reason?
Håkan: No, no, no. They want business results. And I guess that's the same thing if you would implement Kanban or XP or whatever. They are not particularly interested in the method itself. But they want the actual business results and I think that's a very similar thing with SAFe. You need to deemphasize the idea of the SAFe framework itself, it's the business results that we are after. And it's clearly stated what they expect the business results would be by implementing SAFe.
Arne: Another aspect we discussed this morning was that a typical manager, who is not the owner or the founder of a company is usually not incentivized to think ten years ahead or even five years ahead. So the incentive is to deliver stuff. And this is where SAFe could be helpful. But the incentive is in most cases not: in five years from now or in ten years from now I want this to be a real learning organization. And this is maybe a little bit tricky, because on the one hand we would like organizations to be more like learning organizations, on the other hand it seems very hard, because why would it be in the interest of a manager to invest in the future and then everyone else would say: "Oh this is a weird person. What is (s)he doing?" I think you have maybe similar thoughts, Erik?
Erik: Yeah. That's a really really tricky. I mean being a middle manager myself and having been in that situation: How do you progress without being seen as a UFO or sort of alien? And if you're too alien you might get shut down. So of course you want the sustainability to be there for the company for the long term. And you also want to deliver results, and that is a very tricky trade-off. You want to do both, and I think ultimately it will come down to learning some new patterns and un-learning some old patterns and re-learning. And different frameworks and different philosophies can emphasize that more or LeSS - pun intended. So I think that's my take.
Arne: There is a lot of stuff in SAFe. And if you look at the poster it can be a little bit overwhelming. My friend Henning likes to make this joke: He shows the SAFe poster to people and then asks them: " Where's Waldo? Where's the customer?" Because there's a tiny spot, I think on the bottom left or something, where you can find the customer. At least it's not very prominent. And so I guess there's also a risk that you lose the customer out of sight, because there's so much process and so many roles and artifacts. Is that something you've seen?
Håkan: If you follow the implementation roadmap of SAfe (which has some great tools in it by the way), one of the things that you do before you get started is to do a value stream analysis. You then identify how you set up your organization and your Agile Release Trains. What we have found with the work that I've done so far is that this type of work has not been done that much before. So by going through that and actually looking from that lens we actually put more emphasis on the customer and ask what customer value is, before you get into defining the Release Train and the delivery organization. So I actually found it to be a little bit opposite. That this helps upfront with thinking about these things in an organization. So from my point of view it really has helped to take that perspective even more. And then on the portfolio level the suggestion is to use prioritization and scheduling based on Don Reinertsen‘s principles around cost of delay, which also put the customer in the focus. So there's a lot of mechanisms in there which are leaning towards a very high customer focus. So I actually found it to be helping to put those things in the front seat, instead of something that you can potentially introduce to the organization later on.
Arne: I can can totally understand why it's tempting for a manager to implement SAFe. If I try to put myself in this person's shoes, where I'm managing an old school company and I see that we have to change, that we need to become more agile. Now I see that there's this framework called SAFe, and it has a lot of interesting stuff and has this implementation handbook and everything. So that sounds great, and I would probably want to buy it. Erik, what would you do in this situation if you would be this manager, but you didn't want to implement SAFe? How would you start such a journey?
Erik: I'm thinking about acting your way into a new way of thinking, acting your way into a new mindset. We were struggling quite a bit with this in the beginning of the journey in the part in Ericsson where I worked. We had two thousand people at ten different locations in our product development unit. And we were thinking about the whole transformation approach and asking ourselves: Should we do that like an implementation project with a plan and a roadmap and all the steps predefined? We were going back and forth and ultimately we thought that if we want to change our way of working, then we should change our way of changing first. So we didn't come up with a big project plan. We had a one pager showing the rough direction where we were going. We had a few principles and we started moving. So I think that the whole approach to change is pretty important: As a manager in the organization, do you start with yourself and then do the whole transformation approach differently? Or do you do it the traditional way, where you have the risk that you will continue to do things the way you've always done them? Then you don't get into the inspect and adapt and improvements loop. That's my fear. My respect goes to all skilled people, who know the practices, who are practitioners and who know the principles. They are of course aware of this and will tune and tweak things. My fear would be that it's too easy to start with the classic way of driving change: to have all the big plans upfront and then start executing to implement the new new framework. Many organizations, if not most of them, have done that several times and they get bored or fed up with it. And then this becomes the new fad and there will be no real change, because the managers will not change their way of acting. And then they will not change their way of thinking and then you're back to square one after some time -- that will be my fear. So what would I do? I would do something similar to what we did, in addition to everything I said. Having a group of people, who are formal or informal leaders and let them work together as a cross-functional team, meeting regularly to inspect and adapt. Visualize what they do, lead by example and then act. Act your way into new thinking and have full transparency for all the other teams and all the people in the organization to see what you're doing. Also have working sprints or whatever iterations you have, to walk the talk.

Arne: And with with all your skepticism about SAFe do you see any good parts?
Erik: As we... [to be continued]

(Part 2, Part 3)

Curious to hear more about Håkan‘s experiences with SAFe? How it relates to estimates and Kanban? Why Erik thinks it‘s like a black hole and what Marie Kondo has to do with it all? Then check out part two of this Lean-Agile Roast on Erik's blog and part three on Håkan‘s blog
Thanks, Henning Wolf for the idea that led to this conversation!