More hardlining

Matt Heusser says

If your company is just starting to talk about "agiling up" it's software process, my advice is to forget about timeboxed iterations and test driven development. Oh yes, those are good things, and they can enable agile software development, but let's be very clear:  if the team isn't self-directed, cross-functional and respecting of its people, it's not Agile software development. It's ... something else.


Hold on to those ideals. Communicate about them clearly. Fight for them, leave no room for misunderstanding, and you might just make your little part of the software development world a better place.
I think that is noble, and worth fighting for.

Read the whole thing by Matt Heusser.

Hardlining

I wrote the following toward the end of my last contract.  I hesitated to post it because I didn't want to offend the folks I worked with, and because I worried about the effect it might have on my own marketing.  With some distance now, it doesn't seem that offensive,  and if it eliminates some potential opportunities, they're likely to be in places I wouldn't want to spend 40 hours a week in anyway.

My current "engagement" has turned me into a hard liner. I was burned, and I saw the light. I'm not going to go into details, because I don't want to be blacklisted as a troublemaker.

But I suspect I have no choice: I am a troublemaker.

I'm a true believer, and what I believe is this:

There is no Agile but XP and success is its profit.

Anything else that calls itself Agile is just a compromise with an increasingly myopic business/bureaucratic culture obsessed with short-term profit and the illusion of control and predictability via hierarchy.

Scrum may rein in some of the worst tendencies of that culture, but it doesn't get at the heart of the problem.

XP is about two things: one is communication - the dynamic perfection of process.

The other is perfect software.

This is not the static Baudelairean perfection of BDUF.  It's dynamic, minimalist, infinitely flexible.  To be an XP developer is to be a Zen calligrapher inscribing sacred language, to apply all one's intellect and energy to creating and maintaining software that does exactly what the stories say, no more, no less.

XP originated in the context of OO.  Unlike relational databases,  OO didn't spring full-blown from simple, elegant mathematical models, but it has evolved into something damn close.

This vocation is absolutely incompatible with the hierarchical/centralized model in which coders have no autonomy.

The bureaucratic model runs on the differential presence of one human emotion: guilt.  You rise to the top of a bureaucracy by becoming (or being born) a sociopath,   pushing risk downward.  Those stuck at the bottom accept this burden because they are guilty. The vision of future reward,  through graduation to heaven,  winning the lottery, or the application of sheer pluck and grit, is a consolation, not a motivating force.

I've been there - recently - I know exactly how that guilt works. People who work in the environment I'm talking about  would recognize the power of that guilt - if not for the protective psychological repressions and distractions - the bread and circuses - that make it bearable.

XP flourishes in startups and small businesses that can't afford IT departments.

But I want to take it into the belly of the beast.  XP is strong medicine, tough love.

Part II - Heroism

Waitaminit!  The success of TradDev [i.e.  waterfall/hierarachy/cmd&ctl] is not all about fear.  There's a carrot, not just a stick.  It's the solitary pleasure of heroism.   And the dark side of that is empire building and job-security-thru-opacity.

I had a heroism moment of my own:  successfully refactored some legacy Flex code without a net - i.e., no tests.  That was scary, and given the pathological coupling of the undocumented/untested codebase, it could have been a disaster.  (Actually, it still could be.  While I'm on that subject, instead of working effectively with legacy code by building a test harness around it, the team is drawing diagrams to document it. This will just contribute to its rigidity.)
...
As I write this, two heroes are talking near my desk.  It's a happy conversation. They're reinforcing each other's sense of being on top of things, and the buzz of working without a net in a risky environment. So what if it's about BDUF?
...
Now I'm idle.  No corkboard with cards for this iteration waiting to be picked up,  no pairing.  Waiting to get a JIRA (i.e., a task) assigned to me by our manager, who's working from home.  Yet another example of waste in the TradDev world.  I'm here waiting, so I'll bill for it, but it feels nasty.  If I offered to go home, what would happen?

Agile Manifesto Reprise - This Time it's Personal

Stole this from Ron Jeffries and I'm posting the whole thing cuz it's my story too except for maybe the cars:

>    Where will YOU be in 3 years?

Well, in my case I want to be alive and in good mental and physical
health. 


Looking back over various places I might have "wanted" to be, here's
what I think today: 


I thought I wanted promotions, to be given more "power" as a
recognition of how good I was. This reflected the organization I was
in, which valued power. I was wrong. I didn't get a lot of joy from
power. I did get joy from being able to solve harder and larger
problems by having more people working on them with me. 


I thought I wanted more money. This reflected my good taste in cars,
and has certainly given me some pleasure. However, the highest
paying jobs I have had were also the least pleasurable, and
ultimately my lack of pleasure in them caused me to perform poorly. 


I thought I wanted more women. You can imagine how that worked out. 


I thought I wanted to be like people I admired. Many of them were
major jerks (even more so than I am naturally) and emulating them
did not serve me well. 


What I want, today, is to spend every possible moment doing things
that I enjoy, with people I enjoy doing them with. I enjoy doing
things that I do well, and things where I can sense that I am
improving. I enjoy doing things that other people appreciate. 

Clarification of previous post

Actually, that last post was a nitpick - things are going well on this project.  My bottom line is in the black:  the question I've learned to ask myself about a job is whether it is an energy source or an energy sink, and this one has become a source.  The team is coalescing, including management, customer reps, etc., in spite of the legacy ceremony.

Trust/coherence is building, and the only question is whether/when management will perceive this and start dismantling the ceremonial edifice.

Efficiency and Trust

Haven't posted for a while because I've started a new contract.  The team is nominally Agile, the customer is nominally on board, but ... not really.   There's a lot of ceremony, no pairing or TDD expected (although we would not be punished for doing it),  a lot of micromanagement of time with JIRA (be sure to charge that 15-minute daily standup to the right task!).

And I finally made the connection....

What do you do when your team/company is all excited to be “agile”, while your customers want to operate in the traditional, heavy-weight, documentation-driven approach?  ...  In most cases it turns out that they don’t trust the software team and hence they want to push all the risk to the software development side.
-- I Say Agile, You Say Traditional, Document-Driven

Ceremony is the cost of doing business in an environment without trust.  Agile is efficient because trust allows us to eliminate ceremonies of security/CYA/blame/risk-shifting, which waste resources.

The word "ceremony" as used in Agile circles could almost be glossed as "institutionalized Muda (waste)".  As an anthropologist, I think of it from the perspective of Durkheim: He saw religion as a mechanism that shored up or protected a threatened social order. 

For example, estimates "cast in stone" are sympathetic magic, telling a highly structured story in the hope of imposing certainty on a situation involving major unknown risks.  Estimates in a traditional environment are not a tool but a prayer - or an oath.

...

I will not identify the customer or the consulting company I'm subcontracting through.   Not for any reasons of trade secrets or confidentiality, but because of this:

The customer's dress code is the new biz casual - i.e., jeans, polo shirts and sneakers are fine for everyone.  The consultancy requires us to wear the old biz casual - no jeans, no sneakers, dress shirts.  I was told this is because we want to impress the customer by being "a level above them".

Consistent so far.

But then - we have casual Fridays!   Not the customer - they're always casual. Just the "one-level up" consultants.

WTF?

It's like

... but because we really care about all our ... uh ... development associates ... ,  no beatings on Friday.

Moo-dada!

I won't believe a consulting company is Agile as long as it carries the baggage of the Old Biz Religion.

[UPDATE: see the clarification.]

Rockclimbing, Baguettes, Agile Skills and Opposing Forces

Got into some interesting conversations recently - check out Slack: we're not slacking off! and FORCES Behind Skills.

Life/Death/Agility 6: How Many Deaths Will it Take?

Milo passed this little gem on to me. It was published eight years ago and it makes just about every argument I've been making in this mini-series.  Why so long and still no change?

The passage quoted below may explain why "critical XP" still isn't happening:  a chicken-and-egg problem.  Read the whole thing for details on "Ron's project" and "the audit".

The theory of punctuated equilibrium holds that biological species are not likely to change over a long period of time because mutations are usually swamped by the genes of the existing population.  If a mutation occurs in an isolated spot away from the main population, it has a greater chance of surviving.  This is like saying that it is easier for a strange new fish to grow large in a small pond.  Similarly, disruptive technologies (new species of technologies) do not prosper in companies selling similar older technologies, nor are they initially aimed at the markets served by the older technologies.  Disruptive technologies are strange little fish, so they only grow big in a small pond. 

Ron’s project was being run under a military policy, even though it was a commercial project.  If the company policy had segmented off a commercial area for software development and explicitly allowed the team to develop its own process in that segment, then the auditor would have been satisfied.  He would not have seen a strange little fish swimming around in a big pond, looking different from all the other fish.  Instead he would have seen a new little fish swimming in its own, ‘official’ small pond.  There XP practices could have thrived and grown mature, at which time they might have invaded the larger pond of traditional practices.


But it was not to be.  The project was canceled, a victim not of the audit but of the economy and a distant corporate merger.  Today the thing managers remember about the project is that XP did not pass the audit.  The little fish did not survive in the big pond.


...


[in case you don't recognize How many deaths will it take...]