In January, I wrote a little bit about how to do a better job slicing up stories. In my experience, there is always a healthy amount of debate around what size a story should be. Should we make this a 3 or a 5, a 5 or an 8? Inevitably we have to revisit the question of what a point even means. Are we talking about hours of work or difficult or ideal work days (whatever that means)? I don’t think these conversations are terrible useful unless we are intentionally driving to make a piece of work smaller.
So, that begs the question of why do I care whether or not a piece of work is smaller?
I have worked under a few different employee structures in my tech lifetime — all employees on site and in the office all of the time, all employees in the office except for that outsourced team (which quickly grows into several), everyone remote and working from the office or wherever they feel like being that day, and everyone in the office with exception of one or two people. I’m working in that last scenario today. The team is mostly on site, and there are two developers including me that work remote.
Working from home has always been my thing, it’s a comfort zone. I have personal space, and can be hyper productive. Being one of the few people on a team that is remote is an interesting dynamic, though.
Most of the job descriptions I read are either in the form of a job advertisement, or a job description on an internal wiki. Neither are particularly helpful. In the past, I have either avoided applying because the ad listed every skill on earth when what they really needed was a junior. Or, I ran forward and applied to advertisements that were completely understated and well out of my skill range. Bad internal job descriptions can be used like a sword when it comes time for skill assessment and review.
Getting these right always feels like an impossible chore with not a lot of upside. I like to focus on two areas with these, skill and culture.
I got that email a few years ago at an awkward time; I was in Germany at the Agile Testing Days Conference.
So I wrote the email you might expect. For a duration of less than a week, we are talking about consulting, at this rate. At two weeks to six weeks, here’s a second rate. For six to twelve weeks, here’s a third rate. At over twelve weeks …
And so on. There was a lot of “if” and “or.”
Looking around the room, I saw Ilari Henrik Aegerter, known as a sharp negotiator in business. I asked Illari what he thought of my proposal.
His evaluation boiled down to “too many words.” That is, all I needed was one sentence, a single hourly price. If I had an ideal contract length, I could throw that into the email. So the reply could be as easy as “Assuming about six months, we’re looking at $X/hour.”
Done, one line. Yes, we got the deal.
These sort of brief replies will massively improve the chance of success when trying to get to a decision.
Today I’ll tell you why. Continued »
Every company I have worked with has some sort of technical debt. One organization years ago was so bad, we had to do something similar to debt consolidation. We had gone years without really dealing with various problems in the code and build system. The product I was working on was delicate enough that normal feature development was dangerous. In the end, we made a special team to handle some much needed refactors in our SDK and in our now 4 hour long build.
Like all debt consolidation, this was disruptive and meant we had to do without some team members, and a lot of time was lost to coordinating and merging branches. I’m not convinced the end result was much better than the big ball of mud we started with.
I prefer a more sustainable approach to managing technical debt.
Last time I explained how private equity works. Given that these companies exist to buy and sell companies, and that they have nearly $800 Billion in deals in 2015, it is likely that you, or a friend, will or are working with a company owned by a private conglomerate.
What can you expect, and what should you do about it?
That’s our topic today. Continued »
As family-run founders and CEOs retire, and the children have no interest in running the business, it’s more and more popular that the company sells to a private equity firm. Friends, Colleagues, and even clients call to tell me they are excited that the organization will be run by “professional managers” who “really get it”, “think entrepreneurially” and “want to invest in the business.”
Two years later, they call me back, sick of the management by spreadsheet, outsourcing, downsizing, and the constant demand for quarterly growth.
What’s going on?
A few years ago I ran into a tester at a conference that was moving away from testing work. He was working for a company that had their developers pairing for nearly every code change. What he described seemed like magic. He told me that two developers work on one change until it was done. When he said done, he actually meant done, as in ready to ship. Not some weird internal definition of the word that really means ready to hand this piece of work to some other group so they can do their thing in isolation.
I finally had the opportunity to get some experience in this environment and have some novice observations that I’d like to share.
If you’ve driven down a major freeway lately, you’ve certainly seen the billboards. As we tune them out, the marketing boards became more outlandish, then had 3-dimensional components that got our eyes, then moved to billboards that rotate multiple images. For some reason, seeing the tail-end of ten second show made us want to wait, see the others, hope to glimpse that first one again … and realize it was just an ad for dental impacts.
On the road on in the bathroom, the trick is the same, to catch and hold the attention of a captive audience. Over time, the we tune out the marketing, so the ad executives need to find new ways to ‘juice’ the message.
The exact same thing is happening with technology marketing, and it’s really a lesson in time and attention.
Back in the 1990’s we used to have a long, painful process we called regression testing. That was the final step before pushing the code to production. It happened after the code was ‘complete’, and pretty much involved re-testing everything. Since the code was typically a big ball of mud without well-separated concerns, any change anywhere could break anything, so we had to re-test all of it. The re-testing was to make sure the quality did not regress, with a new feature breaking an older feature. Hence the term “regression testing.”
Most of the automation strategies I get brought in to help with are plans to do just that: Take the regression testing and have the computer do it, click for click. Inevitably this leads to automation delay, and, more often than not, test tooling project failure.
Today I want to describe a more excellent way.