{"id":8259,"date":"2021-11-18T20:29:23","date_gmt":"2021-11-18T20:29:23","guid":{"rendered":"https:\/\/andrewdoran.uk\/blog\/?p=8259"},"modified":"2021-11-18T20:44:38","modified_gmt":"2021-11-18T20:44:38","slug":"a-seat-at-the-table","status":"publish","type":"post","link":"https:\/\/andrewdoran.uk\/blog\/2021\/11\/18\/a-seat-at-the-table\/","title":{"rendered":"\ud83d\udcda A Seat at the Table"},"content":{"rendered":"
I picked up Mark Schwartz\u2019s A Seat at the Table<\/a><\/em> as I have recently been thinking about how we can move away from the perception of our IT team as the people who \u2018turn up and fix the Wi-Fi\u2019 to one where we are seen as true business partners. The book took me by surprise in being less of a self-help manual and more of a well-articulated argument as to why the old ways in which we did things no longer apply in the digital age. It is brilliant.<\/p>\n

<\/p>\n

Schwartz has a way of encapsulating key concepts and arguments in short, smart prose. The book contains the best articulation of the case for Agile, Lean and DevOps that I have read. There is so much wisdom in a single sentence, for example:<\/p>\n

\"What<\/p>\n

One of the books referenced heavily in A Seat at the Table<\/em> is Lean Enterprise<\/a><\/em> by Jez Humble, Joanne Molesky and Barry O’Reilly which I read some time ago. Lean Enterprise<\/em> goes into more detail in terms of the concepts and mechanics used in modern software development such as continuous integration, automated testing etc. and brings them together into a coherent whole. Schwartz does not cover these topics in detail but gives just enough information to make his case as to why they are the sensible way forward for developing software.<\/p>\n

A company may typically engage their IT department as if they are an external supplier. They haggle and negotiate, they fix scope and cost and they then the work starts. This approach does make some<\/em> sense for working with a truly external vendor where they are taking on some of the financial risk of overrunning and you are able to specify exactly<\/em> what you want in detail, for example where physical IT infrastructure is being delivered, installed and configured. It makes little sense when you are creating a new software system. It makes even less<\/em> sense when the IT team are colleagues in the same organisation, trying to work out what investments will make the biggest impact on the company. We win and lose together.<\/p>\n

First of all, we came to speak about \u201cIT and the business\u201d as two separate things, as if IT were an outside contractor. It had to be so: the business was us and IT was them. The arms-length contracting paradigm was amplified, in some companies, by the use of a chargeback model under which IT \u201ccharged\u201d business units based on their consumption of IT services. Since it was essentially managing a contractor relationship, the business needed to specify its requirements perfectly and in detail so that it could hold IT to delivering on them, on schedule, completely, with high quality, and within budget. The contractor-control model led, inevitably, to the idea that IT should be delivering \u201ccustomer service\u201d to the enterprise\u2014you\u2019d certainly expect service with a smile if you were paying so much money to your contractors.<\/p><\/blockquote>\n

For readers who are familiar with why we use Agile software development methods, the arguments against the old \u2018waterfall\u2019 approach are well-known. What is more interesting is that Schwartz also points to issues that advocates of the Agile approach have exacerbated. Agile people can be suspicious of anyone that looks like a manager, and want them to get out of the way so that they can get on with the job. Schwartz argues that the role of managers and leadership is to remove impediments, many of which the Agile team cannot easily deal with on their own:<\/p>\n

When the team cannot accomplish objectives, I am forced to conclude that they cannot do it within the given constraints. The team might need members with different skills. It might need permission to try an experiment. It might need the help of another part of the organization. It might need a policy to be waived. But if the task is possible and the team cannot achieve it, then there is a constraining factor. My job is to remove it.<\/p><\/blockquote>\n

What if someone on the team is really just not performing? Perhaps not putting in his or her share of effort, or being careless, or uncooperative? Well, then, dealing with the problem is simply another example of removing an impediment for the team.<\/p><\/blockquote>\n

The critical role of middle management, it would seem, is to give delivery teams the tools they need to do their jobs, to participate in problem-solving where the problems to be solved cross the boundaries of delivery teams, to support the delivery teams by making critical tactical decisions that the team is not empowered to make, and to help remove impediments on a day-to-day basis. The critical insight here, I think, is that middle management is a creative role, not a span-of-control role. Middle managers add value by contributing their creativity, skills, and authority to the community effort of delivering IT value.<\/p><\/blockquote>\n

He makes a clear case for getting rid of \u2018project thinking\u2019 completely. If you want a software delivery initiative to stay on budget, the only<\/strong> way to do that is through an agile project. The team will cost the organisation their run rate which is almost always known in advance. Work can be stopped at any time, preserving the developments and insights that have been created up to that point.<\/p>\n

As a former PMO head, and with my current responsibilities of running a portfolio of change initiatives, it was interesting to see the approach to \u2018business cases\u2019 recommended in the book. Instead of signing off on a set of requirements for a particular cost by a certain date, you should be looking to assess the team on what they want to achieve and whether they have the skills, processes and discipline to give you confidence that they will:<\/p>\n