the phoenix project - it misses the three ways

This commit is contained in:
Fred Pauchet 2019-10-05 21:23:42 +02:00
parent 877768a8dc
commit 4a8066b0e6
1 changed files with 93 additions and 0 deletions

View File

@ -0,0 +1,93 @@
# The Phoenix Project
IT is pure knowledge work, and so therefore, all you work is like that of an artisan. Therefore, there's no place for standardization, documented work procedures, and all that high falutin' rigor and discipline that you claimed to hold so near and dear.
Your job as VP of IT is to ensure the fast, predicatable and uninterrupted flow of planned work that delivers value to the business, while minimizing the impact and disruption of unplanned work, so you can provide stable, predicatable and secure IT service. (p. 91)
The only thing more dangeroux than a developer is a developer conspiring with security. The two working together gives us means, motive and opportunity. (p. 39)
By reducing the number of projects in flight, we are keeping lanes of work. (p. 275)
## Technical debt
Unplanned work might be called anti-work, since it further highlights its destructive and available nature. "That's why it's so important to know where unplanned work comes from". (p. 161) Unpallned work kills your ability to do planned work.
Technical debt comes from taking shortcuts, which may make sense in the short term. But like financial debt, the compounding interest costs grow over time. If an organization doesn't pay down its technical debt, every calory in the organization can be spent just paying interest, in the form of unplanned work. (p. 195)
People think that just because IT doesn't use motor oil and carry physical packages, that it doesn't need preventive maintenance. Because the work and the cargo that IT carries is invisible.
Preventing oil changes and vehicules maintenance policies are like preventive vendor patches and change management policies.
## Manageability
In order to control the system, we need to reduce the number of moving parts.
* Work in progress goes out
* Due date performance goes up, as work in progress goes out.
It takes some of our most frequent services requests documented exactly as the steps are, what resources can execute them and time how long each operation takes.
We must convince that IT is capable of not just screwing up less often, but helping all of the business win.
There are three internal control objectives (p. 252):
1. to gain assurance for reliability of financial reporting
2. compliance with laws and regulations
3. efficiency and effectiveness of operations.
Infrastructure should be treated as code. Environments creation may be integrated into the development process.
"Value stream map" = estimate the time needed for each step, through deployment pipeline. This should be allowed through a common build procedure.
"Months before the product launch, the code is already in production. It's merely a flag toggled and it's already tested by internal uses/testers" (p. 352).
ITIL = automation around change, configuration and release management.
## The Three Ways explained
Voir notes Nextcloud ;-)
## Team
* A/B Testing
We need short and quick cycle times to continually integrate feedback from the market place.
A great team performs best when they practice: practice creats habits, habits create astery of any process or skill. Repetition, especially for things that require teamwork, creats trust and transparency. (p. 275)
Until code is in production, no value is actually being generated, because it's merely work in progress stuck in the system.
"We can make something work short term and figure out a long-term strategy as we go". (p. 329)
"Don't be the idiot that failed because he didn't asked for help" (p. 336)
The five dysfunctionments of a team:
1. Absence of trust
2. Fear of conflict
3. Lack of commitments
4. Avoidance of accountability
5. Inattention to results.
## Flow
In any system of work, the theoretical ideal is single-piece flow, which maximize throughput and minimizes variance.
"The flow of work should ideally go in one direction: forward. When I see work going backward, I think 'waste'. It might be of defects, lack of specification, rework, ... Regardless, it's something we should fix." (p. 285)
## A gérer dans le processus de développement
* Features
* Stability
* Security
* Scalability
* Manageability
* Operability
* Continuity.
CIA :
* Confidentiality
* Integrity
* Availability