In Conversation: Rebecca Parsons

When it comes to getting things done, the business world has always been willing to embrace ideas and inspirations from a variety of sources. Military role models have proved perennially popular – from von Clausewitz on strategy to inspirations from US Navy SEALs. There is also a tradition of large organizations seeking out best practice from smaller businesses, and the entrepreneurial and creative worlds. Design Thinking, as exemplified by Ideo and others, has been studied over recent years. Similarly, the lean movement is now embraced by large corporations keen to import the combination of thrift, energy and creativity it extols.

Organizations are now looking for inspiration to those who are in the engine room of the digital revolution: the software developers and others who originate the technology which forms an increasingly important part of all of our lives.

Leading the way in this endeavour is the Agile Alliance. It has a simple and compelling manifesto:

“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value individuals and interactions over processes and tools; working software over comprehensive documentation; customer collaboration over contract negotiation; and responding to change over following a plan.”

As it has championed the working methods of developers, the Agile Alliance and the movement around it has spawned a new vocabulary – from Acceptance Test Driven Development (team members with different perspectives collaborating to write acceptance tests) to scrum (a process framework used to manage product development and other knowledge work) by way of pair programming (two programmers sharing a single workstation).

Among the most compelling and longest serving champions of agile thinking and practice is Rebecca Parsons, chief technology officer of ThoughtWorks. She has decades-long applications development experience across a range of industries and systems. Her technical track record includes leading the creation of large scale distributed object applications and the integration of disparate systems. She was previously a professor of computer science at the University of Central Florida and also worked at the Los Alamos National Laboratory. She talked with Thinkers50 cofounder Stuart Crainer.

The Agile Alliance champions the way software is developed and holds it up as an example of how organizations can and perhaps should be organized. Is that a fair interpretation?

Yes, that’s the next evolution. If you look at the whole evolution of how software was developed we started by dealing with problems which were relatively well understood – a payroll system, general ledger, and so on. Accounting systems haven’t changed a great deal. Importantly the only people who worked with those systems were internal to companies. There weren’t the same questions about usability. People learnt what they had to learn. You didn’t have complex user interfaces and you could afford to decide upfront what exactly you were going to do because the rules and the models weren’t changing. As those systems grew in size and complexity, we just kept building them in the same way. Everything we needed to do was settled in advance, then we designed something to do it, then built it and deployed it.

But those cycles were taking years and what started to happen, particularly as you got into the mid to late 1990s, was that things began changing rapidly. We started getting personal computers, client servers and more interactive interfaces, as well as more complex problems.

So, it became harder and harder to cast things in concrete. People began seeking out alternatives, even for large systems, and that is when the Agile Manifesto came along. And the basic premise was rather than seeing change as the enemy, we needed to look at change as inevitable and design processes that can respond more quickly to change. To do so, you need to get people collaborating more, you need rapid feedback.

Particularly as systems become more complex, it is actually more difficult for people to tell you exactly what they want. There were many instances where people would say, ‘That is exactly what I asked for but it’s not what I want’. Very often until you see something you can’t know that it is not exactly what you wanted.

Feedback, collaboration and transparency are the basic underlying principles of the Agile Manifesto. It started out initially with software developers and then business analysts and testers. Increasingly, there was tight collaboration between the primary roles of software development and then we began spreading further out – you can see that recently in the DevOps movement.

Increasingly, it is about looking at bringing some of these agile principles and related practices to the operation of systems more broadly. How do you bring designers into this? How do you want to manage your entire portfolio of projects? And this is where you start to bump into strategy.

More and more companies are becoming technology companies that just happen to do business in insurance, manufacturing or retail banking. Almost every strategic change initiative will involve a change in an organization’s technology.

So the question becomes how to apply those fine grain agile principles, honed over a couple of decades, around how to do software development, to the entire portfolio of an organization. It is about mapping between the strategic vision and what that implies to the business processes and the relationship between the organization, its customers and their partners. How do you translate that back into the changes you need to make in your technology and how can you most effectively implement that programme?

Transparency, feedback, openness, and the need for communication is something we’ve heard on many occasions, but it doesn’t seem to penetrate the corporate core.

Yes, to some extent that is the legacy of organizational structures that were put in place in a different time.

And it is worth noting that there are challenges in an organization with complete transparency. You might have an executive committee weighing up different options about the future of the organization which might involve the closure of a plant or outsourcing work to another organization. If you are completely transparent during such deliberations you run the risk of demoralizing the different groups involved. You potentially pit them against each other.

You can look at the history of organizational dynamics and understand why you end up with cultures built around only disclosing the minimum necessary information. But that has become unfeasible in many ways because of how rapidly information moves around. With so much information publicly available it becomes increasingly difficult to be non-transparent. A lot of what organizations are struggling with now is how they operate when the default assumption is that some of these things will get out. It used to be security through obfuscation and ignorance. That doesn’t work any more. Even if ignorance is widespread only one person has to figure it out and then everyone knows. If you are trying to hide something on the Internet behind some URL eventually someone will find it and as soon as they find it they will publicise it.

Organizations are having to go through this movement from how they used to be able to operate to how they need to operate now.

The historical and conventional view is that the agile concepts are all very well but difficult to scale: does that still hold true?

I think we’re still experimenting about what it takes to scale agile to 50,000 or 100,000 developers. There are some frameworks out there but I don’t consider it settled. There is still a lot about agile at the small scale which is still evolving.

One of the things about the Agile Alliance is that part of our mission is that we are not specific to any particular methodology. We refer to it as the big tent. Different organizations and certifying bodies look at a narrow slice. The role of the Agile Alliance is to be the big tent to allow practitioners of all of the different approaches to utilize agile across all the different roles and disciplines; to interact, to learn and teach each other, and to continue to evolve the use of these practices.

Are there cultural barriers within organizations to the understanding and practice of the Agile Manifesto?

When you start with the principles – feedback, transparency, collaboration – it is hard to argue against them. In practice sometimes it is culturally difficult. For example, pair programming might be difficult for people used to working by themselves who then find themself talking to someone else all day. But if you look at it another way it is simply rapid code review feedback. Someone is writing code, someone is looking at the code, they’re then talking about what it should do, and questioning whether they have considered all the cases. So once you ground practice in the principle of rapid feedback then that starts to get over some of the cultural barriers.

One of the harder concepts is the notion of the self empowered team. In very hierarchical organizations and societies if you say that this motley crew of developers, analysts, testers, designers and so on can get together and organize themselves – as opposed to the project manager being in charge of all of the decision making – that is a difficult shift culturally. It is effectively giving up control. And people who have power and control generally don’t like to give it up.

So there are some things that are culturally sensitive but in general I think the practices travel well. What we have also found is that as agile software development has become more accepted, the parts of the organization touched by software development begin to adapt these practices. So you have marketing campaigns being run in a lean style. I have seen people plan their wedding with a kanban board [a visual workflow tool consisting of multiple columns. Each column represents a different stage in the workflow process]! I know families that basically use the same sort of board to manage the chores that their children do.

These agile practices are in fact going out far from software development to many different kinds of activities

If you think about them from the context of the principles, it isn’t that difficult to move those processes into completely unrelated fields. Our legal department at ThoughtWorks uses some of the agile software development practices in how they think about contracts. Of course, across industries, countries and roles the practices do change. It doesn’t make sense to do pair programming to plan a wedding

Agile thinking appears to be in a sweet spot. There is overlap with the lean movement, the maker movement and design thinking for example.

Yes, it is certainly getting there and is definitely not the evil A-word it once was. I started working for ThoughtWorks in 1999 and many clients wanted to bring in this style of working but insisted we didn’t use the word agile. You don’t have to worry about that any more, but there are still questions. My response is that you might not do all of the practices but the principles are fundamental. You need to ground yourself in the principles.

For example, if you are creating software to make medical diagnoses if you get it wrong people might die. So, you need to bring a different level of rigour than you would do if you were creating software for a sandwich ordering system. But you still need to have feedback, you still need to regularly and rigorously test what you are doing, and need extensive collaboration between people who are working on different parts of the system so that they truly understand the underlying assumptions. You might do the practices differently but that does not mean you are not following the principles and values.

That is definitely becoming more accepted and is allowing the Agile Alliance and the concepts to branch out to different parts of organizations. This is also influencing the way strategy is thought about. A strategic plan that doesn’t show any concrete change for five years is highly incompatible with an agile and lean way of thinking.

Now people are thinking about applying the concept of a Minimum Viable Product to strategy. [A Minimum Viable Product is, as Eric Ries said, the “version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”] How can we break strategy into different streams? How can we build feedback cycles into strategy so we know early on that the strategic change is achieving the strategic changes we want? Lean thinking, flow thinking and the concepts of feedback from agile are all part of how you take a strategic vision and turn it into a strategic change programme. And that is how this realm of agile thinking is moving into the strategy arena.

Over the last century companies have mastered how to create strategy, but it seems that in the software development world you have mastered the art of implementation. Now it seems the two are meeting each other.

The whole process of agile software development is to take a higher-level articulation of what your business level requirements are and translate them into implementable chunks of technology. This is taking it further: how do you decompose a strategic change initiative into different streams and business requirements to get feedback?

There are all sorts of implementation aspects of any strategic change initiative – technology, process change, the introduction of new partners into an ecosystem and so on. But by using the mindset of decomposing — in order to get transparency and feedback on how the processes are working and how successfully they are being executed – this entire collection of ideas can influence the implementation of strategic vision

It seems that software development’s role in the modern society is actually overlooked.

Yes, I think so. Increasingly it is what keeps the technological age going. More and more industries are being defined by technology. Differentiation between companies in the same industry is being driven by their ability to adapt new technology and to adapt to new technology. And that is going to continue. Think about airlines and their ability to recover after a bad storm. It is a logistics problem but also a technology problem. More and more industries are having to think about their business in the context of their technology, their grasp of technology and technology’s ability to help them differentiate themselves from their competitors.

What still excites you?

One of the things I like is that it is still extremely dynamic. As we are addressing new problems we have to think about how we are going to approach those problems. It is still constantly changing and that is what I always loved about technology.

This is an excerpt from Strategy@Work, a Brightline and Thinkers50 collaboration bringing together the very best thinking and insights in the field of strategy and beyond.