De Teloorgang van de Projectleider in de DevOps wereld

Disclaimer: This post is in Dutch, I will translate it into English at some point, but by clicking here you can read a translation by Google.

Update: Lees ook het artikel "Agile Projecten: De veranderende rol van de Project Manager" voor een bredere uiteenzetting.

Ze zijn er nog, vorige week heb ik er nog eentje gezien. Een echte projectleider. Zo eentje die, wanneer je het hem, of haar, vraagt, een certificaat kan laten zien waarop duidelijk vermeld staat dat een Prince2 cursus met goed gevolg is afgerond.

De projectleider is een uitstervend beroep. Althans, in de Software ontwikkeling. Gelukkig maar, want ze hebben er helemaal niets te zoeken. Althans, in de Software ontwikkeling.

De vraag is echter waarom er toch zoveel projectleiders in de IT-sector te vinden zijn. Een simpel antwoord is er niet, maar waarschijnlijk komt het omdat we in zoveel andere sectoren ook projectleiders hebben. In de bouw bijvoorbeeld, daar hebben we projectontwikkelaars en die realiseren bouwprojecten en die worden dan weer geleid door projectleiders. En net als dat we de kapitale fout maken in de IT-architectuur door de IT-architect te vergelijken met een ‘gebouwen’ architect[1], doen we dat ook met projectleiders.

We denken dat we projectleiders nodig hebben in de IT en dat komt vooral door die vermaledijde waterval methode die we sinds mensenheugenis in onze IT-projecten toegepast zien. Kolder natuurlijk, die waterval methode, er is nog nooit een project opgeleverd dat binnen het geplande budget en in de geplande tijdspanne iets bruikbaars heeft opgeleverd. Kan ook niet, want er is geen enkele gebruiker die ook daadwerkelijk weet wat hij, of zij, wil. Laat staan dat de gebruiker weet wat hij, of zij, nodig heeft.

Geen wonder dus dat we al onze pijlen tegenwoordig op agile methoden richten, het liefste zoals ze dat bij Spotify doen. In het kort:

Je hebt een idee, je ontwikkelt de software, je laat de gebruiker bepalen of het een goed idee was en je gaat verder met het volgende idee.

En hier gebeurt het dus. Dit is waar aan het licht komt dat de projectleider niet in de IT thuishoort. Want als je denkt dat deze cyclus een project is, dan heb je het flink mis. Ook trouwens als je denkt dat een aantal van die cycli samen een project vormen.

Het fundamentele probleem van een project is dat een project eindig is. Je begint aan een project en op een gegeven moment is het project klaar. We zijn klaar als het project af is. En dat is natuurlijk kolder voor IT-projecten want IT-projecten zijn nooit af. Haha, denk je nu, dat is de bekende IT-grap, dat projecten altijd over tijd en over budget gaan. Maar het is geen grap, want wanneer een IT-project klaar is, dan begint het allemaal pas eigenlijk.

Wanneer het project namelijk klaar is, wordt de software gebruikt en pas dan kunnen we eraan werken het bruikbaar te maken. Kijken we nu naar de projectleider, dan is zijn, of haar, werk gedaan als het project is opgeleverd. De projectleider wil dus alleen maar de software aan een gebruiker geven. Binnen de tijd, binnen het budget. Los van het feit of de software wel bruikbaar is.

De projectleider richt zich dus op wat de gebruiker wil hebben en niet wat de gebruiker nodig heeft. En dat is de fundamentele reden waarom IT-projecten onzinnig zijn, en waarom projectleiders desastreus zijn.

Dat hebben we gelukkig al een tijdje in de gaten en daarom zijn we met agile begonnen een paar jaar geleden. Los van het agile manifesto[2] en de hype rondom Scrum, zijn we in de IT al meer dan 20 jaar heel actief in het iteratief ontwikkelen met een zo kort mogelijke development cyclus. En daarom zijn we sinds die tijd, tot ongeveer een jaar of 5 geleden, druk geweest met projecten die software iteratief opleveren. In plaats van lange waterval trajecten hebben de projectleiders hun projecten in kleine watervalletjes verdeeld. We zien dat iteratieve projecten minder uitlopen voor wat betreft tijd en geld. Maar nog steeds krijgt de gebruiker wat hij wil en niet wat hij nodig heeft. Of zij natuurlijk.

Het moge duidelijk zijn; Zolang software ontwikkeld wordt in door projectleiders geleide projecten, dan resulteert dat in gewenste, onbruikbare software.

En toen was er agile en Scrum en sindsdien krijgt de gebruiker wat hij nodig heeft en niet per se wat hij wil hebben. Door niet van meet af aan vast te leggen welke functionaliteit de software moet opleveren, maar gaandeweg de scope bij te stellen en bestaande functionaliteit aan te passen tot iets bruikbaars, hebben we agile projecten die iets bruikbaars opleveren.

De echt goede projectleiders weten om te denken naar deze nieuwe manier van werken. Het is het type projectleider dat niet meteen in de stress schiet als niet duidelijk is wat zijn team moet opleveren. De scope van het project, maar ook de duur, wordt daarmee bepaald door het budget. Het project is afgelopen als het geld op is. De projectleider wil, als hij, of zij, hart voor de zaak heeft, dus zoveel mogelijk functionaliteit voor dat budget opleveren.

En daarom is de projectleider niet meer nodig. Want het snijdt geen hout om projecten te scopen op basis van hoeveel geld er beschikbaar is. Dat moge duidelijk zijn.

Dan is er nog een ander klein, piepklein, puntje van aandacht met dat nieuwe agile werken. Al vroeg, namelijk zo snel mogelijk, staat er, in een echt agile project, iets in productie en wordt het gebruikt door echte gebruikers. Dat moet misschien worden aangepast omdat het niet bruikbaar is. En plotseling is de projectleider ook verantwoordelijk voor het oplossen van productieproblemen.

Alle, of in ieder geval nog teveel, organisaties hebben nog een galvanische scheiding tussen de projectorganisatie en het operationele beheer. Change-Run organisaties met duidelijke, vaak tot in den treure uitgewerkte, hand-over procedures. Verschillende verantwoordelijkheden en vaak ook verschillende budgetten.[3] Deze organisaties staan bol van de silo’s die wel op zichzelf optimaal werken, maar gezamenlijk verre van optimaal zijn.

Het Change-Run model blijkt in de praktijk niet te werken. Dat wordt vaak ontkent. Vooral door mensen die denken dat de waterval methode werkt. En veel van die mensen zijn projectleiders die hun teloorgang ontkennen en anders nog niet onderkennen.

Ze gaan teloor omdat organisaties door hebben dat projecten in de IT uitermate onzinnig zijn. Er is natuurlijk een hele groep organisaties die gewoon hip is en niet snapt waarom ze het zijn. Een steeds grotere groep snapt het wel en richt zich wat wenselijk is en niet meer op wat gewenst wordt.

IT-afdelingen transformeren zich meer en meer van projectorganisaties naar productorganisaties. Organisaties stappen af van Change-Run scheidingen en stappen over op DevOps[4]. Gespecialiseerde teams worden ontbonden en multifunctionele teams worden ingericht. Er worden geen softwareprojecten gedaan, maar producten ontwikkeld in software. Omdat er geen projecten meer worden gedaan zijn er geen projectleiders meer nodig. In geen enkele vorm. Wel zijn er product eigenaren nodig. Helaas voor al die zonder-werk-komen-te-zittende projectleiders, is een producteigenaar niet zoiets als een projectleider. De producteigenaar is namelijk de eigenaar van een product, die snapt het product, en begrijpt vooral wat wel en wat niet bruikbaar is. Hij, of zij, is verantwoordelijk voor het product, cradle-to-grave, van wieg tot in het graf dus.

Hij, of zij, heeft het mandaat om te welke functionaliteit op welke wijze geboden wordt. Is ook nog eens budgetverantwoordelijk voor het product. De producteigenaar is wordt niet beoordeeld op de hoeveelheid functies die in de beschikbare tijd en met het beschikbare budget in productie gehesen wordt, maar wat de waarde van zijn, of haar, product voor de organisatie is. En die waarde kan alleen gemeten worden wanneer het product daadwerkelijk gebruikt wordt.

Maar er is hoop voor de projectleider. Er zijn namelijk aardig wat product eigenaren die het ook nog niet snappen. Ze ontwikkelen hun product in een project, dat nog behoorlijk wat trekjes heeft van een waterval traject. Of in ieder geval iteratief. En zo lang product eigenaren nog niet helemaal snappen wat een MVP[5] is heeft de projectleider nog werk. De huidige lichting producteigenaren zijn nog onvoldoende ervaren in het opleveren van een iets. De projectleider, en zeker een die bekend is met iteratieve trajecten, heeft hier dus een flinke streep voor. Maar voor hoelang?

Het tij keert namelijk, product eigenaren begrijpen meer en meer wat hun rol is en hoe zij deze het beste in kunnen vullen. Organisaties komen erachter dat het niet verstandig is om hun projectleiders om te scholen tot product eigenaren. Los van het verfoeilijke Prince2, is het ook nog eens zo dat de projectleider onvoldoende kennis en vaak geen affiniteit heeft met het product. Dat ‘ene iets’ waar een organisatie geld mee verdient. Producteigenaren komen dus uit de business en niet zoals de projectleiders, uit de IT. De projectleider is dus overbodig.

Daarmee is de teloorgang van de projectleider dus onvermijdelijk. Niet een kwestie van of maar van wanneer.

Zoals altijd, bedankt voor het lezen van deze post en ik hoop dat de post je aan het denken heeft gezet. Ik realiseer me dat ik nogal kort door de bocht ga en het allemaal redelijk zwart/wit neerzet. En zoals met alles op het internet moet je ook dit artikel met een dosis gezond verstand lezen. Moet je zelf de nuancering aanbrengen. Ik wil je uitnodigen om dat laatste te doen via de comments van deze post. Waarschijnlijk dat anderen het ook interessant vinden te weten hoe jij erover denkt, en uiteraard staat het buiten kijf, dat ik het interessant vind.

PS: Er zijn projecten in de IT die iets neerzetten om er vervolgens nooit meer aan te komen, of door te evolueren. Dit zijn de projecten die je wel zou kunnen vergelijken met projecten uit de bouw. IT-infrastructuur projecten waarbij iets fysieks wordt opgeleverd. In het gunstige geval wordt er gefaseerd opgeleverd, zodat er snel genoten kan worden van de opbrengsten, maar wanneer opgeleverd kan er niet echt worden gesproken van doorontwikkeling. In deze gevallen is een projectleider nog zeker wel nuttig. Maar in een wereld waarin ook infrastructuur meer en meer in code wordt uitgedrukt is ook hier eerder sprake van productontwikkeling dan van projectontwikkeling.

---

[1] Maar daar gaat dit artikel niet over, wil je weten wat daar mis mee is, dan kan je mijn blog post over die architect lezen. Die vind je hier: https://itarchitectureandstrategy.blogspot.nl/2015/02/how-youll-fail-as-it-architect-when-you.html.

[2] Kijk op http://agilemanifesto.org/ voor het manifesto. Lees het aandachtig voor je je conclusies gaat trekken.

[3] Change-Run organisaties zijn het gevolg van het niet begrijpen van Taylorism. https://en.wikipedia.org/wiki/Scientific_management, net als het agile manifesto.

[4] In een DevOps organisatie werken ontwikkelaars (Dev) en beheerders (Ops) nauw samen. Zie ook: https://en.wikipedia.org/wiki/DevOps

[5] Een MVP, Minimum Viable Product, is een versie van een product met de minimale set aan functionaliteit om toch nog waarde te scheppen voor de gebruiker. Zie ook: https://en.wikipedia.org/wiki/Minimum_viable_product

The Bimodal misconception, why Gartner has to realize the ignorance of its customers

Okay, first of all, I'm talking about Gartner's Bimodal IT thing here which is defined by them, that is Gartner as follows: "Bimodal is the practice of managing two separate but coherent styles of work: one focused on predictability; the other on exploration.", which is taken from here. And it makes no sense, because Gartner omitted to mention that this is an application architecture thing.

The problem I have with Gartner's definition of Bimodal IT is that it implies rather explicitly that predictability and exploration don't go together, which is of course totally correct. You explore because you can't predict. But the reason why Bimodal IT was introduced is because we face a stand-off between waterfall and agile, between Silo'd IT and DevOps, between client/server and service oriented systems, between legacy and the new world.

Reading the rest of Gartner's definition (Mode 1 is optimized for areas that are more predictable and well-understood. It focuses on exploiting what is known, while renovating the legacy environment into a state that is fit for a digital world. Mode 2 is exploratory, experimenting to solve new problems and  optimized for areas of uncertainty. These initiatives often begin with a hypothesis that is tested and adapted during a process involving short iterations, potentially adopting a minimum viable product (MVP)  approach. Both modes are essential to create substantial value and drive significant organizational change, and neither is static. Marrying a more predictable evolution of products and technologies (Mode 1) with the new and innovative (Mode 2) is the essence of an enterprise bimodal capability.) you understand the flaw in their reasoning. The flaw is in that the definition assumes that an organization can be divided in two ways of addressing its business, or rather that it can adopt a way of working in that it addresses its business simultaneously in a 'we know what the customer wants' and a 'we want to know what a customer wants' way of working. Which is bogus, of course. Totally bogus.

At one of my current clients, Bimodal IT is a hot topic. Here it is used such that the back-end systems are considered Mode 1 systems and the front-end systems are considered Mode 2 systems. Furthermore, the epic mistake is made to consider everything running in the cloud to be a front-end system and everything in the on-premise environment, which is a traditional data-centre, to be a back-end system. Makes no sense to me, and I can guarantee that within the next 6 months there will be back-end systems running in the cloud.

To understand Bimodal IT, we need to understand why the term was coined. Basically, you need to re-read the definition and understand what is being said. You need to put it in the context of time, and address it from an architectural perspective. Because that is what Bimodal IT is, well that is its raison d'etre.

So, let's start with 'one focused on predictability' and forget about this. It's an ambiguous term. Ambiguous because for one we want our software delivery cycle to be predictable, we want the quality of our solutions to be predictable and we want the costs of our solutions to be predictable. At all times, no difference between front-end and back-end, no difference between cloud and data centre and no difference between old and new. At the same time, we can't predict what the best feature set of our solution is. We can't ever predict it, no difference between fron
t-end and back-end, no difference between cloud and data centre and no difference between old and new.
So predictability only applies to our solution delivery process and not to our solution.
And then there's 'the other on exploration' which we should forget as well. It's an ambiguous term as well. It's ambiguous because we need to always explore to find the right feature set for our solution. This is because we can't predict the right set. It has nothing to do with where we're hosting, whether it's front-end or back-end or anything else.
So Bimodal IT by Gartner's definition makes no sense, because from the outset it's wrong.

But here's the catch, at the time Gartner coined the term, it made perfect sense. It's just that Gartner forgot to mention that Bimodal IT actually hinges on application architecture.

Back to this customer. Bimodal IT is used as an excuse not to comply with the ancient and really seriously out dated processes in IT that are (to be) followed within this organization and I assume unwillingness to try to modernise the processes. By just simply referring to Gartner and their definition of Bimodal IT and stating that this is the exact situation at their organisation, some of my clients architects and project managers are implying that the processes only apply to what's running in the back-end and what they're working on, which is the front-end.(*)

Let's see why thinking in terms of Bimodal IT is making sense. It makes sense because at the time Gartner coined the term, we developed our systems predominantly being Waterfally and the hipsters were being Agile. There was nothing exploratory about it, and read the Agile manifest and it says nothing about exploration, but the more about predictability.
Mode 1 and 2 are all about delivery cycles. Mode 1 is long, Mode 2 is short. One could say Mode 1 is about being ignorant and Mode 2 about being smart.

So, ignorant vs smart, what's that about?

Well, in Mode 1, we tend to think that it makes sense to first define the complete solution, design it and build it before we deliver it to our users. And because for some reason, release into production always results into (often major) headaches, we also tend to think it makes sense to not release that often, so we limit the occurrences of headaches. Hey, if you only bang your head against a wall twice a year, you only run the risk to crack your skull twice a year. So makes perfect sense, doesn't it?
Then there's Mode 2, where we think that is makes sense to just grab the most important, or valuable features and develop these and take them to our users, and then do it again with the next most valuable solutions and put them out to our users. And we tend to think that because we only release a tiny thingy, it's very unlikely that it'll go wrong and will only cause (if at all) a dull feeling in the back of our head. Hey, if you nudge your head against a wall every few days, at the most you know that the wall is still there, but that's about all to be felt.

So Bimodal IT is where one group of people thinks that doing something really hard is less risky when you make it even more complex but do it fewer times and the other group of people thinks quite the opposite, that doing something really hard is less risky when you simplify it and do it more often. Kind of practice makes perfect.

And yes, years ago when Gartner came up with Bimodal IT, we really had this Mode 1 and Mode 2 division as described above. But in this day and age, the Mode 1 people are a rare breed. Mind that we're discussing this in an era where major banks (ING) are firing pretty much everybody that is Mode 1, where major airlines (KLM) are spending millions of €'s to transform in to a full Mode 2 organisation and where it's hip to be Mode 2 at IT departments of local and national governments.

But Bimodal IT is there to stay for a while. Not because of predictability, nor because of exploration. Not even because of Waterfallians (Mode 1 people). Nope, it's because of Monoliths. Those ancient systems that were delivered in a day and age when we thought Client/Server was awesome and everything should be consolidated into one system so we could guarantee data consistency and we could really vouch for abiding to the DRY principle (Don't Repeat Yourself).

These systems can't be changed, they are architected to be unchangeable. We don't want them to be that way, but they are. It's because our application architectures of a couple of years ago resulted in unchangeable systems, we can only change them by changing the complete system. The monoliths are preventing us from becoming post-Bimodal IT organisations.

Back to the misconception. Bimodal IT is something that has to do with the monoliths in our IT landscape and nothing with how we perceive our IT or the systems in our IT landscape. The misconception is that we need to adopt a Bimodal IT approach to how we do IT because we don't have to. We have to get rid of the monoliths and we need to start by isolating them behind a layer of changeable software. Hide them like a skeleton in a closet of services.

By adopting Bimodal IT today, or continue with Bimodal IT today, means you either have a totally wrong understanding about how to manage your IT department, or you are still in the previous millennium when it comes to IT architecture, or you're just using Gartner's reputation as an excuse for not having to modernise your IT processes.

Thanks once again for reading my blog. Please don't be reluctant to Tweet about it, put a link on Facebook or recommend this blog to your network on LinkedIn. Heck, send the link to my blog to all your Whatsapp friends and everybody in your contactlist.
But if you really want to show your appreciation, drop a comment with your opinion on the topic, your experiences or anything else that is relevant.

Iwan


Although this post is my personal opinion, there're quite a few articles to be found on the internet about this topic that I've read. So here're some interesting reads:

- Gartner Glossary: Bimodal IT
- Gartner's bimodal IT mistake: DevOps can deliver velocity and quality
- Bimodal IT: Gartner's Recipe For Disaster
- Beware the Dangers of Bimodal IT
- Gartner’s Evolution of Bimodal IT
- The Flaw at the Heart of Bimodal IT




*: Interestingly enough, they forget to mention that the back-end is running on-premise and they're in the cloud and yes, the front-ends hosted on-premise are just as much under the same regime as the back-ends.

Architecture Principle - Service Interface Compatibility Principle

Architecture principles are ground rules by which we develop our software. This ranges from ways of working to styles of coding, from software decomposition to business compliance, from infrastructure choices to security implementations. As you can see, it covers pretty much everything related to the development of business value, online, offline and internal.

Description

The typical SOA application landscape is defined by services. Through service orchestration the behavior of (online) services is implemented, business value is created. A service consists of two parts;

1. The implementation of the service, 
2. The interface of the service. 

Both components have their own respective life-cycle. Resulting in a situation where through time the implementation of a service is evolving typically to support evolving non-functional requirements. For example to evolve from a relational database to a NoSQL database. Or from home-grown development to the use of an online service. Analogous, the service interface can evolve over time as well, typically because the resource it represents evolves over time. For example the amount of data captured about a customer can increase over time from just a name and number to also include an email address, date of birth and marital status.

Service implementations typically change because of (more) technically driven reasons, will service interfaces typically change because of (more) business driven reasons.
Where as the service implementation is more of a service internal discussion, i.e. how the service is implemented is irrelevant as long as the defined behavior is provided, the service interface is a service external discussion, i.e. how the service can be consumed is relevant to whomever uses the service. Thus, the service interface must be kept as stable as possible, i.e. when the service changes, the interface should stay relevant for existing users and become relevant for new users.
Service interfaces can change for three reasons, that have to be factored in when complying to this principle:

1. The resource represented by the service becomes richer, i.e. fields are added. In this case there is no impact to existing consumers. Provided that the the consumer abides by the principle that 'Unknown makes Ignored', in other words, the consumer will ignore any fields that it wasn't aware off. For example, with a Person resource that contains a Name and a Phone number, the new version also holds and email address.
2. The resource represented by the service syntactically changes, i.e. existing fields in the resource are for example renamed because of an enrichment of the resource data. For example, with a Person resource that contains a Name and a Phone number, the new version renames the Phone number to Business phone and adds a new field Mobile number.
3. The semantics of a resource changes although the data doesn't necessarily changes. For example a Person resource becomes a Law Enforcement Agent as all captured information pertains agents in law enforcement.

Keep in mind that the service interface is a contract, it is not just the technical procedure/function call or the URI to access the service, but also the description of the input and output values. Their constraints, limitations etc. Hence the reference to 'behavior' in the text above. For more on behavior see my post Oh Behave! How JIRA turned into a Veggie Salad.

Rationale

Since a service doesn't know about its consumers, the Producers make no Assumptions about Consumers Principle, it is unknown what the consequences are of changing the interface of the service. And therefore it is impossible to quantify the impact of such a change, hence the viability of that change is extremely hard to define. So the interface can not change, or rather, changes to the interface may not impos an impact on any of the consumers.

Implication

The implication of this principle relates to both the service as well as the consumer of the service. In all cases, the old interface should stay available for those consumers that rely on the old interface.

Producer implication

Service interfaces are to limit the impact of change, meaning that syntactic changes to the resource are to be implemented by extending the resource, i.e. adding fields, instead of changing the existing resource, i.e. changing fields. This caters for changes 1 and 2 as described above. Service interfaces that require a semantic change, i.e. the change defined in 3 (above), in fact result a new resource, and hence the identified of the resource should change.

Consumer implication

Consumers must abide the principle of 'Unknown means ignored', hence any information in a resource that is unknown, should be ignored.

References

Your API versioning is wrong, which is why I decided to do it 3 different wrong ways
VERSIONING REST WEB SERVICES
Versioning RESTful Services