It’s performance review season.
The temperature outside has been steadily dropping for a month now. Unless you’re in California or Florida, you probably have to let the car run for a minute to melt off ice on the windshield. Instead of having a few more hours of sunlight each day at the end of work, it’s pitch black and may as well be midnight.
You know that that means, and it isn’t a signal for Santa’s arrival.
Everyone hates them. For managers it is a month long time suck of paperwork, dividing up a shrinking budget, and reviewing work that may have happened 9 or 10 months ago. For employees, it’s a time to strategically talk about the work you did. You want to give an honest review, but not so much that you kill your chances of getting more money for the next year.
How do you turn the yearly performance review into something that works for, instead of against you.
There has been a lot of research lately on the effects of sitting all day on a persons health and fitness. We really don’t need research to see this. Most people that spend most of their time in front of a computer slowly feel what is happening to their waist line and more importantly, their long term health. We get out of breath going up a couple flights of stairs, picking up the kids gets a little harder and more tiring, household chores leave us sore.
I don’t have any suggestions for Christmas gifts this year, Matt can help you in that department. But, I do have some fitness suggestions to keep you healthy and happy for years to come.
“Startups” are the new cool place to be.
But what are they?
For today, let’s define a startup as a company with potential for massive profits but an unproven business model. (Our senior contributor, Matt Heusser, likes to point out the definition of a proven business model, that you can drop a dollar in advertising in and a dollar fifty comes back. If the investment of the next five million dollars has risk involved … you’re probably a startup.)
Today I’d like to take a look at the forces around startups, using the example of mobile application sold in the play store, through the lens of Michael Porter’s Five Forces competitive model.
Imagine working at a small software start up. There are maybe 10 people at this point and everyone feels like they are a part of something; owners of a living, breathing thing. Your little company is doing well. The team is building good software and the market is responding with “yes, more!” by throwing money your way.
Now, it’s time to grow the company and scale up your efforts. You need more developers, more sales people, and more software to sell.
How do you keep the magic? How do you take a small set if ideas that work well, and grow them to work in a company that has not 10s, but hundreds or thousands of employees?
This is the question that the book Scaling Excellence: Getting To More Without Settling For Less tries to address.
Let’s take a deeper look and see if the scaling problem can be solved so easily.
It’s December, a time when programmers, sysadmins, testers, and managers (especially managers) think about getting a thing or two for a person or two.
You might give up and get nothing; I certainly did enough of that my first decade in IT.
You could spend a hour asking Amazon for ideas, all of which seem not quite right, or give up in five minutes with a USB stick or Tux Stress Toy.
Or you could hang on for a few ideas that might be a little too silly, a little too business, or, perhaps, just right.
Agile came about as a response to the extreme standardization of software development process that was popular through the early 2000s. That standardization mostly came in the form of waterfall and Rational Unified Process (RUP).
The principles of agile suggested the exact opposite of processes like RUP and waterfall. Instead of a one size fits all approach, we now have extreme customization. There is no common starting place and every team applies the principles just a little different — some use scrum, some use kanban, some TDD here, and a CI system there.
Managers noticed that loosening up on standardization got software done faster and want to spread that goodness through their company.
There is a problem though, agile doesn’t scale.
Back in 1993, I performed my last show as a professional musician. This had been an endeavor that I had pursued, quite doggedly, for the better part of a decade. I had a number of successes and failures along the way, and I learned a lot of skills that would serve me well in my future career as a software tester.
The past few weeks have brought me full circle, in that I accepted an opportunity to perform with a band once again. One of my former band mates reached out to me and told me about a project that he was working on, and asked if I’d be interested in coming “out of retirement” to sing once again. After considering the time commitment and the logistics, as well as the technical challenges involved, I said “Sure, let’s do this!”
I have always believed that my time as a musician, as well as performing in a band, was critical to my success as a software tester and my ability to work in IT in general. That may sound like a strange way to come to an IT career, but in truth, the two disciplines (music and Information Technology) are surprisingly compatible. Both are creative spaces. IF you have never considered IT a creative space, think about the way that problems are often solved, and the way that solutions are derived. Very often, the logical and first planned approach doesn’t work the way that you anticipated it would. Musicians are taught to improvise early on, and often a performance can go sour rapidly if they cannot think on their feet if a problem occurs.
While I was in Postdam, Germany for Agile Testing Days 2015, there was a blizzard of options for talks and workshops I could attend. With close to one hundred speakers, there was no way I could attend everything I wanted to, but one workshop in particular stood out to me. It was delivered by George Dinwiddie and Stephan Kämper regarding The Three Amigos Principle.
I figured I’d learned everything I’d need to know about this concept years ago. It’s pretty simple. A programmer, a product owner and a tester walk into a room… and no, this is not a set up for a joke, that’s what they do. They get together and discuss the details of a story, so that everyone can be on the same page. In my company, we most often have this interaction when a story is “kicked off”.
The idea behind the Three Amigos principle is that software testers and programmers can get involved in the process of defining, developing and testing stories earlier. What often happens, though, is that a story is reviewed from a high level, some questions are asked, and the general consensus is that we can get into the details as we progress.
As I was listening to George and Stephan share their experiences and some examples that they put together for us to work with, they shared an idea that I felt was quite powerful, and made a lot of sense. It’s called “Example Mapping”, and was developed by Matt Wynne.
Last week I introduced a story about what bad corporate communication can look like. I talked about the post, and the experience that lead up to it, with my colleague and co-blogger here on Uncharted Waters, Matt Heusser. He made me realize that that past was two in one, it was a story in a story.
The juicy part of the story is about how development managers come to be, and the problems that creates. There is also the matter of how I dealt with this phenomenon as a newly minted software practitioner and what I’d try do different a second time around.
Let’s get to it.
A friend of mine got this line in an email from the corporate office last week:
As part of a corporate effort to improve our ability to assure high-quality software is undertaking a study to determine the corporate capability of our Quality Assurance teams. Factors under review include: resource alignment, technical skills, technical skill gaps, tools in use, and testing techniques.
That email looks like a mashup of half the business lingo we learned in undergrad. The weird part is that no one knows what any of those words mean. The people reading it are usually left confused and probably feeling some anxiety about their position in the company. The people that wrote the email were probably trying to make the wording vague enough so that anything that actually happens will still fit the original story.
I’m not convinced this is how business emails should go.