Mary Poppendieck, une de mes auteures préférées en TI, a rédigé deux excellents articles depuis les 6 derniers mois. Je trouve que ses articles valent toujours le temps que l’on y consacre. Je vous les propose si vous avez un bon 30 minutes de libre devant vous.
Dans cet article, Mary parle de friction dans toutes sortes de domaines relatifs au TI. La deuxième moitié de l’article est principalement centrée sur la friction dans les gouvernements. J’ai fait ressortir quelques extraits et me suis permis de mettre en gras certains passages:
Uber is among the largest of a new crop of startups – investor Chris Dixon calls them full stack startups – that bypass incumbents and reinvent the entire customer experience from start to finish with the aim of making it as frictionless as possible. Full stack startups focus on creating a world that works the way it should work, given today’s technology, rather than optimizing the way it does work, given yesterday’s mental models.
Large companies have the same full stack of capabilities as startups, but these capabilities lie in different departments and there is friction at every department boundary.
Code bases created and maintained by full stack teams are much more resilient than the large and calcified code bases created by the project model precisely because people pay attention to (and change!) the internal workings of “their” code on an on-going basis.
Broadly speaking, these fiascoes are caused by the process most governments use to procure software systems – a high friction process with a very high rate of failure.
One country that does not have an IT fiasco story is Estonia, probably the most automated country in the world. A few years ago British MP Francis Maude visited Estonia to find out how they managed to implement such sophisticated automation on a small budget. He discovered that Estonia automated its government because it had such a small budget.
The UK government changed – seemingly overnight – from high friction processes orchestrated by procurement departments to small internal teams governed by simple metrics. Instead of delivering “requirements” that someone else thinks up, teams are required to track four key performance indicators and figure out how to move these metrics in the right direction over time.
It turns out that when governments move from the old mental model to the new mental model, many of the things that were considered “good” or “essential” in the past turn out to be “questionable” or “to be avoided” going forward. These are
- Requirements generate friction.
- Handovers generate friction.
- Organizational boundaries generate friction.
- Estimates generate friction.
- Multitasking generates friction.
- Backlogs generate friction.
Teams need only three lists: Now, Next, and Never. There is no try.
Once upon a time, governments assumed that obtaining software systems through a procurement process was essential, because it would be impossible to hire the people needed to design and develop these systems internally. They were wrong. They assumed that having teams scattered about in various government agencies would lead to a bunch of unconnected one-of systems. They were wrong. They were afraid that without detailed requirements and people accountable for estimates, there would be no governance. They were wrong. Once they abandoned these assumptions and switched to the low friction approach pioneered by Estonia, governments got better designs, more satisfied consumers, lower cost, and far more predictable results.
Lien vers l’article complet: Friction
Five World-Changing Software Innovations: How They Happened
Dans cet article, Mary raconte les 5 innovations que nous n’avons pas suivi pendant que nous parlions d’Agilité depuis 15 ans. Celles-ci sont:
- The Cloud
- Big Data
- Antifragile Systems
- Content Platforms
- Mobile Apps
Voici quelques citations pour vous donner le goût de lire l’article:
Concernant le Cloud:
The idea that infrastructure is context and the rest is core helps explain why internet companies do not have IT departments. For the last two decades, technology startups have chosen to divide their businesses along core and infrastructure lines rather than along technology lines. They put differentiating capabilities in the line business units rather than relegating them to cost centers, which generally works a lot better. In fact, many IT organizations might work better if they were split into two sections, one (infrastructure) treated as a commodity and the rest moved into (or changed into) a line organization
À propos du Big Data, Mary raconte la petite histoire du Big Data depuis 2001:
Netflix, which has a good number of reliability engineers despite the fact that it has no data centers.
En ce qui a trait au Content Platforms:
Three entrepreneurs – Chad Hurley, Steve Chen, and Jawed Karim – tried out an interesting use case for video: a dating site. But they couldn’t get anyone to submit “dating videos,” so they accepted any videos clips people wanted to upload. They were surprised at the videos they got: interesting experiences, impressive skills, how-to lessons – not what they expected, but at least it was something. The YouTube founders quickly added a search capability. This time they got the use case right and the rest is history.
Video is the printing press of experience.
À propos des Mobile Apps:
By 2014 (give or take a year, depending on whose data you look at) mobile apps had surpassed desktops as the path people take to the internet.
The nature of mobile apps changes the software development paradigm in other ways as well. As one bank manager told me, “We did our first mobile app as a project, so we thought that when the app was released, it was done. But every time there was an operating system update, we had to update the app. That was a surprise!
Lien vers l’article complet: Five World-Changing Software Innovations: How They Happened