It’s been ten years since I read “Big Agile Up Front” on the C2 wiki. That article describes an “enterprise” where team members who have to go through a “deployment” routine in order to get a unit test to ru. They hook up their continuous integration server to an “Agile” Gant chart which control ever change and reject the “planning game” as unprofessional. (“Game? This is no game!”)
At every step, the decision seem right. They are “Enterprise-y.” Grown up. Mature.
Yet every single step slows down delivery. It robs the place of joy. Somehow it takes nine months to get anything done.
What is happening here? Continued »
Earlier in the week I wrote a post, Why Johnny Can’t Agile. The post made a point that we might consider giving up on “saving” legacy code bases. That is, code without unit tests, with a high change failure rate, where a change in one place might break another. Perhaps it is all just too hard, and we should all give up. My arguments were strong, stirring, compelling. And wrong.
To be fair, I had data. Over the past few years I’ve worked with a dozen organizations, and interviewed or been “near to” a few dozen more. Many of them do big public presentations about their agile adoptions. When I visit, they invariably have sprints, stories, and standups. The work may be sliced thinly – perhaps too thinly. I see stories like “a new etr to the table” that could be written as “create a single INSERT statement in a database that is essentially a cut and paste.” Everything seems to take a long time. There is not much joy. The magical feedback and improvement loops that inspired the title of Jeff Sutherland’s book Twice The Work In Half The Time — those simply do not happen. In my previous piece, I called a real agile adoption “next to impossible.” This was my working hypothesis:
I’m starting to wonder if we should say “legacy systems should be managed differently than greenfield development. Count the cost. You may come to different conclusions.”
It was Lisa Crispin, one of my peer reviews, that pushed back strongly on this. After all, she had been on companies that had broken through (as had I), more than a few times. If I wanted to give up on saving legacy projects and teams (which is most of them), why the sudden change of heart?
After the new year I wrote this article, then asked for a few rounds of peer review. My reviewers, including Lisa, pointed out that I was wrong. Or, perhaps more politely, they pointed out I could benefit from a different perspective. I decided that I was wrong. Instead of changing things, I decided to present the original post, as-was, and ask for your feedback, before presenting some corrections. Assuming forewarned is forearmed, there you go. Tell me how I am wrong.
Because I am.
I was talking to Lisa Crispin earlier today about the state of devops survey. That survey identifies four levels of “performers.” For performance measures it looks at how long it takes a change to get to production after commit, how frequently new code goes to production, or the percentage at which a change “fails”, creating new problems. These measures are more concrete and “hard.” They are easier to measure, but don’t include all the concepts in Agile software. Collaboration, for example, is remarkably hard to measure. Still, we’d tend to call the companies that are high achievers on the DevOps survey “Agile.”
For some reason, it is next to impossible for established organizations to get there. Continued »
Mis-classifying in-fact employees as independent contractors is not new. What is new is California’s law, AB5, which strictly defines the independent contractor role. According to the Washington Post, AB5 is “aimed at Uber and Lyft.”
Except, of course, Uber is saying the law does not apply to them.
It seems like something out of a science fiction Novel.
Let’s break it down, and what it means for software. Continued »
John Cuttler just put up a common conversation on twitter. That is, the “no matter what you are wrong” conversation with management. John’s example starts with management asking what the problems are. The team takes time to create the three hundred tickets to address the technical problems. After a long delay, management says they can allow the team to spend 8% of their time to fix the issues.
The conversation death-spirals.
It’s a good thirty-second read; check it out for yourself.
This problem is so universal. It connects to my own experience — repeated experience. John says the “sad cycle” is “so predictable.” Jeff Kosciejew proclaims “I’ve worked at this company!” How is it possible the same terrible conversation has happened to all of us?
Last time I talked about the people-people with the soft skills that had taken over Agile Software Development. It is easy to dismiss them as the “hippies with the flip-flops and the love beads.”
Yet they have taken over.
What, exactly, are soft skills anyway?
How can they be so magically powerful that the people-people always “win”?
Today I’d like to take a hard look at soft skills – and why they matter in business. Continued »
The growth rate of the software field in the USA means that more than half the people have less than ten years of experience. Meanwhile, Scrum has been established as the default way of doing software for about ten years. Combine these facts and you get one stark reality: The majority of people in software today have spent their entire careers in a world where Scrum was “how we do it” and waterfall was “old and busted.” It seems that on a daily basis I am told that “Agile” is bad and “sucking the life” out of team members. We have forgotten our Agile History.
This is a pattern. I’ve seen it before.
And, with a little Agile History Lesson, we can stop it from happening again. Continued »
Twelve years ago I was complaining about this term, Heuristics. The term itself is incredibly simple in meaning – the kind of thing you can learn in thirty seconds. People seemed, to me, to be using it to “sound smart”, to create insiders (who knew the term) and outsiders (who did not).
Today I see the value in it – the term is precise. I want to bring you on the inside.
Let’s start with that thirty second definition.
“Attend to what you eat, how you sleep, and exercise” won’t solve every weight problem. You could have an insulin problem or other medical condition. Yet it is good enough, often enough, that it is a go-to idea for us. The engineering term for an imperfect way to solve a problem is a heuristic.
Many of us have our heuristics internalized. They are implied in the way we work, and can be as simple as “if you want to get anything done for the day, don’t start with email. Start by doing the work”, followed by “at the end the the day, park your work to start it immediately tomorrow.” Those are productivity Heuristics. (By the way, it is prounounced “Hew-Ris-tic”) Today I want to talk about my heuristics in software testing.
I spent most of my youth – and a good part of my 20’s – obsessed with things. As a mathematics major, then computer programmer, they were abstract things. You couldn’t even touch them. I worked with ideas. Christmas was something to put off until December 20th, then either guess, or, if I was lucky, work a list someone else gave me. The people in my life that mattered were close family. That is, if I remember them.
Eventually I realized the truth. Ten years from now, no one is going to remember if that project was on-time or a day late. What they will remember is how you made them feel. In IT, you can do better than 20% of people just by bothering to get a card for a few people that matter. Get to 10% by putting a lottery ticket into it.
If you prefer to think of life as a video game, consider this post about how to break above the top 5%.
This year, I’m going to do something unusual. Christmas gifts that won’t break the bank but can blow the doors off. At the end, I’ll review my more historic stocking stuffers, the kind you can get from Amazon for ten bucks that can lead to a great ice breaker.
This year, I want to do better. Continued »
A few days ago, I put out a post on twitter about Documentation.
That post was my most-replied-to, most-liked, most popular in weeks.
It’s time we talked about it.