There has been an interesting discussion happening on twitter as of late about the perceived value of individuals in an organization and the skills they bring to the table. I have found myself in the past several weeks in the interesting position of having to take on much more of a role I had not anticipated needing to take on, that of release manager. At the beginning of April, this was a job that was just done by someone else and I provided testing support to make sure that we had solid code going out the door. Today, I am the release manager, much of which has to do with merging branches, writing and maintaining scripts to make sure the revision numbers are correct, and a variety of small housekeeping jobs.
Prior to taking on this role, I was seen positively by my team, but outside of my immediate test team, I was really just another tester. Helpful, to be sure, but still seen as “other”. Once I started taking over the release management, though, there was a subtle change. My comments for stories were taken a little more seriously and acted on a little more quickly (at least that was my impression). My comments about potential fixes more times than not now get worked on quickly. Comments have generally been positive. What happened? Just a little paradigm shift, but one that has proven to be very interesting to see unfold.
I often go into new and different organizations that have new and different tech stacks. Once I finally get my arms around unstructured data analysis tools like Splunk, it is probably time to change, to go work with a rails shop that is using Amazon Web Services (AWS) combined with docker to create build-deploy pipelines that use CircleCI that …
It’s all fine, don’t worry about me. I can pick up a yeoman’s understanding of the technology soon enough. The problem is the difference between an understanding good enough to help the business and good enough to be a practitioner. I tend to ask how the tool works, to see more than a demo of a build-deploy run, but how to actually create and maintain a new project.
Sometimes people are surprised by the question, and say “it’s super easy, you just do it” without actually showing me anything.
For example, I once saw a fitnesse demonstration that had a bunch of code functions, inputs, and expected results. Run the application and it reaches down into the Software Under Test, calling the code function, comparing actual to expected.
But how did it work?
Someone had to actually write some code to connect the two systems, right? Continued »
That is a trick question.
Despite the fact that there is a blog post once a week or so, and tweets far more often about the nasty work environments people are enduring in the name of Agile, it doesn’t seem to be failing at all. As far as I can tell, agile is still thriving and growing, and probably hasn’t quite reached the point of market saturation.
That seems to be the case at least based on the number of agile themed conferences, meetups, and consultants that are available.
So what gives?
Have you ever noticed that the answer is “no” more often then it is yes?
This can be extremely frustrating. In some cases the company just spent several thousand dollars to send you to a course or conference. If nothing changes, the conference was a waste, right?
And yet the answer is no.
You can be careful — picking a topic that requires no training, no consulting, no new software. You can find free and open-source tools to use, or even offer to come up to speed at night, on your own time.
And yet the answer is still no.
How is that possible?
Let’s look at it from the Boss’s perspective.
What Does the Boss Get?
Assume your new pet project fails – who will take the blame? The boss will. After all, he approved it. Assuming the project succeeds – who gets the credit? You do, after all, it was your idea. Looking at this, there is no upside for the boss. It is a classic heads-I-win, tails-you-lose scenario. Only someone who owes you a favor, or someone you have some power over, would go along with something like this, and, sadly, the type of person willing to try is unlikely to have a long career in management.
Here’s the alternative to getting permission: Do it yourself anyway. Say, for example, you want to add a batch command that takes in userId’s from a file and deletes them, instead of hand keying the deletes one at a time. Or pair programming. Or adding unit coverage to a particular module, or some other small changes to the codebase. Who’s to stop you from doing this?
Mostly outmoded ideas about how we spend our time.
Most knowledge workers have some amount of time assigned to a task such as a story that really needs to get done. We also have a second set of time – discretionary time – that is really up to us. If you take an extra five minutes in the restroom, or have another cup of coffee, or decided to sit in on another team’s standup meeting, or just spend an extra twenty minutes on email (or reading this blog post), you won’t get fired. In fact, no one will notice. The assumption is that use of time will make you more productive (as opposed to skipping the bathroom all day), so it is fine to just do it.
Add up that time and it could add up to hours per day.
So just do it.
The Time Argument
An XKCD comic shows the payback to automating a particular manual chore over a 3-year time horizon.
This allows you to think of the payoff of an experiment — If you have to do it every day, and it saves you five minutes, that’s a lot of time saved over three years. Another, more fanciful XKCD shows the danger of guessing wrong, so be wary, as automation needs to be maintained.
Still, it it’s worth doing, and you can do it it in discretionary time, or, perhaps, a little sweat time at night, consider just doing it. Don’t ask for permission.
In fact, if you need to get permission, go the other way: Don’t pitch the boss, pitch the team – with the project as your idea if it fails and that you will share the success if it succeeds. Timebox it, limiting it to a two or three week experiment with a dozen hours invested per week.
Have a few successes, and you’ve changed the pattern for “innovation”, from top-down to by anyone. You’ve hacked the culture, created a more fun place to work, and maybe, started a ripple that can turn into a way.
Let me go a step further: Most major productivity and technical innovations in large companies are created by lone wolves, doing things in their spare and discretionary time, that are later recognized by the establishment. I call this the Charles effect, and I’ll talk about it next time.
This past weekend during our most recent Weekend Testing session, we focused on some exercises centered around Accessibility. The experience was both interesting and enlightening. Interesting in the fact that there is always a greater appreciation when confronted with challenges outside of our own, but enlightening in the sense that it can be very difficult to make the mental switch to “think differently” about our experiences.
If I had a dollar for every time I heard “we’d like to do unit tests”, or “test-driven development”, or “make design patterns a discipline”, “limit work in progress”, or “get serious about improving testing”, I could certainly take today off.
These express a desire to try something new and that’s great. If you have an idea and get serious about that idea idea you might find yourself becoming the internal coach, champion, cheerleader or sales leader of the new idea.
If that makes things feel a bit awkward, well, I hope today’s blog post will help. Continued »
In March, Zappos CEO Tony Hsieh sent a company wide memo announcing a change to a flatter organizational structure called Holacracy. Tony also offered a severance package for those that were not interested in The New Way. 210 Zappos employees took the package and will be leaving.
Zappos began making changes to have a flatter organizational structure over a year ago. It looks like they are getting serious now.
Gender and diversity issues in tech is a difficult thing to talk about. People are understandably sensitive. As a white male, I’ve never dealt with any kind of disadvantage related to diversity. Me giving an opinion on the topic, is skewed at best.
When we look in most tech companies there is a clear majority of white males between the ages of 25 to 35. Especially when we look in the programming departments. Some people look around and see the work getting done by (mostly) skilled people and say “what’s the problem?”.
Others look around and note that there are many under represented groups — people of color, and women for example.
It might be easy to say that because you don’t participate or haven’t observed people being mistreated, that it doesn’t happen. That would be completely untrue though.
I would like to talk about the issue a little bit.
In a recent episode of Silicon Valley, the team hires a young programmer to write their Cloud Implementation. And I do mean young; much closer to ten than twenty. When “The Carver” asks the age of the CEO of Pied Piper, and is told “twenty-seven”, he winces, sucks in his breath, and says “yikes.”
While the ages are exaggerated (the show is a comedy) these sorts of problems really do happen; we’ve covered it here in the past. Members of the technical staff who are over forty seem like rare birds. Complaints that old programmers won’t learn new tricks seems legitimate, and too many of my older technical friends are more interested in escape and survival than in reinventing themselves.
I don’t think the problem is entirely them – it is not a freewill issue. Nor is it ageism (though that does happen) — it might be more accurate to say that there is a system force that makes it hard for older technical staff to adapt to changes in the way work is done. Today I’ll explore that, along with what you can do about it if you want to stay in the game.
It’s been with me now for about three years. It was a gift from my friend Elisabeth Hendrickson when I participated in an Agile event she was hosting. Since then, it’s been a talisman of sorts, and today, it goes with me everywhere I can take it.
I’m not referring to the NERF gun ;).