Last week I went to snowy Columbus, OH for a regional software / quality assurance conference called QA Or The Highway. QA Or The Highway is a one day conference, this year, it was preceded by a one day workshop on teaching software test design.
The workshop and conference were fantastic, but the conference keynote was particularly interesting to me. Gareth Bowles did the closing keynote on his experience working at Netflix and why they do a lot of testing in production rather than the normal pre-release testing we see.
Lets take a closer look at his keynote.
I’ve had both the pleasure and the challenge to lead an initiative over the past five years called Weekend Testing. It’s a loose model based on the idea that a session is announced, a mission is declared, and people are invited to participate over Skype. It takes place over the course of two hours. The sessions are informative, fun and, in my opinion, very organic. While I may have a general idea of a topic or a goal, where the session will go or how it will be received is anyone’s guess.
The biggest challenge for me personally is to try to come up with topics that are unique and interesting. I’m not alone in this initiative, I have a couple of other facilitators that help with developing sessions as well (my fellow Unchartered Waters writer Justin Rohrman being one of them). It was during a recent conversation with Justin, as we were discussing how to propose new sessions, that we started talking about how difficult it can be to make something that is “new”. As we were talking, I shared with him what I call the “Becker-Fagan Effect”. What is that, you ask?
Last week, I talked about a way of thinking about thinking of social classes in software companies. The less obvious it is that we make money for a company, or the more often we have to deliver bad news, the less likely it is that we are part of the ‘it’ crowd.
How does the model effect us in a practical sense, and how do we change it from a dart board with defined boundaries, to more of a swimming pool where everyone is mingling?
I just came back from vacation to 212 priority-one email threads in my inbox. I have two days to hit the high notes on replies, get two proposals in, write an article or two. Then I have two days of technical work, Daddy Daughter Camp, then I drive three hundred miles to help organize a workshop, then speak at QAORTheHighWay, drive Three hundred back, consult for two more. On the weekend I see the family I haven’t really seen since vacation, then dive back in just about the time that program work is due for two conferences and tax season gets serious.
I just emailed Emma Armstrong, a friend of mine at RedGate Software, telling her I had time for a conversation … in about a month.
My work in progress is too high.
When work in progress is too high, you get stressed. The quality of your work goes down. You take shortcuts, and everything takes longer.
One task that takes ten hours can be done in ten hours. With ten tasks, performing one hour at a time, the average task now takes close to a hundred business hours to complete. And those numbers assume that you have no loss in focus as you switch between tasks.
It Gets Worse
Network theory tells us that when a transportation channel gets overloaded, things don’t just slow down to number of tasks*duration — instead, movement slows to a halt. You’ve likely experienced this when there is an accident on a four-lane highway when there is an accident blocking on lane under moderate traffic — you don’t go 75% of normal speed, you drop to 5%. Or less. We call this a congestion collapse event; the less-fancy term is gridlock.
I even had an assignment in graduate school to calculate the speed at which the network would degrade after 75% of capacity was reached – (we used Tanenbaum’s Computer Networking Book) — the short answer is never run your Ethernet network at over 80% of capacity.
When your work in progress is too high, you end up telling people you’ll call them next month … if you’re responsible. If you won’t, or can’t say things like that, you end up doing everything poorly. The system collapses.
The fix for excess work in progress is finish what you’ve started and not take on new work until you’ve finished. It sounds easy, but a consultancy that does that without ever considering the future will quickly find itself with no work in progress, a very different, and not so good, problem to have.
What Matt Is Going To Do
With some great personal pain I’m going to have to go back to two wonderful conferences and suggest we talk about 2016, not 2015. I’m going to have to tell the folks at TvForTesters and TestingCurator.com “not now.” I am going to let a draft proposal go unsubmitted and tell a friend from another continent, that no, I do not have time to build a talk together, as valuable and fun as it would be, and as much of a slam-dunk, easy-peasy work it sounds like.
Because my work in progress is too high.
I do not want to do these things. I have to do them in order to provide the quality of work my friends have come to know and expect. When I begin to dig out from all this, in early March, things will be a little better, and by April, better still. And yes, I will continue to refine my early-warning systems so they kick in a bit earlier, and yes, I will still need new work – though my ratio of paid to pro-bono may need to go up a bit.
Sadly, too many employees, teams, and divisions, feel they can not do this. Work is pushed onto the team, shuffled around in priority, and people feel they can not say “no” or even “maybe.”
There are a few things you can do, but in the meantime, I’d like to ask the readership: Is your work in progress too high — and what are you doing about it?
Companies can be modeled in all different ways. The Gervais Principle, mentioned here a couple times before, slices up companies based on who stays at the bottom and who rises to the top. I have been thinking about a different model lately, one that slices companies into layers based on social classes and social value. Or at least, perceived social value.
Scrum: The Art of Doing Twice The Work in Half The Time isn’t just a book about scrum. It’s also a book about Jeff Sutherland’s incredible life, a story about how scrum came to be, a touch of Lean and Toyota Production Systems, and some insights about why scrum works.
The first paper on scrum was published in 1995, but Jeff was experimenting and creating the foundation of Scrum before that while working at Easel Corporation. Twenty years have passed now, it’s pretty crazy.
Lets take a look at Jeff Sutherland’s latest feelings on Scrum and productivity.
It’s review time in my part of the work world. Once again, it’s time to sit down, examine the year that has past, and objectively determines what it is I have done over the course of the year. Along with this is the question of how this can be reported upwards to managers and HR.
This can be frustrating. It is a process where I need to look at what it is I am doing in my everyday work, and somehow show that I am doing more than just “doing my job”. The bigger question, however, comes down to “what does it mean to actually do more than my job?”
Planning is a polarizing topic in software development. The reality is that all different types and amounts of planning will get the job done, and software made it into production long before people were arguing about when and how a plan was created.
In more traditional waterfall organizations, every bit (or so we thought) of the work is planned out ahead of time, sometimes months ahead of time. Before the programmers go to work, something akin to a small novel will be handed over explaining each little detail of how the software should look and work.
At the opposite end of the spectrum is the agile crowd where the perception is that no planning occurs at all.
Agile software development principles strongly encourage team development, team resource sharing, and the creation and sharing of knowledge. This is a wonderful goal, but why, so very often, do we see the system stacked against the team, and focused on the individual? Think about who generally gets promoted in organizations. This is, of course, subjective. I can’t speak for every organization, but in my own experience, the person who gets promotions, bonuses and higher pay raises tends to be the stand-out individual that “the company cannot live without”. For the sake of this story, let’s call them “the hero”.
We all know these people. They are the ones online at all hours, answering questions, finding some unique way to solve a problem, and being praised for doing so. They ride in to save the day, have near universal admiration of their teammates, and management extols their virtues.
What could possibly be wrong with this picture?
On August 1st of 1966, Charles Whitman climbed a tower a the University of Texas and went on a shooting spree. After, the coroner discovered that Whitman had a tumor in the part of the brain that controls anger and aggressive behavior. A few days before the event, Charles wrote in his journal about noticing feeling different over the past weeks and months.
The book leads up to a question of whether we ask the right question in criminal cases: blamability VS ability to be rehabilitated. I think we are asking the wrong questions in software and would like to talk about that.