“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.
Michael O’Church first came to my attention for his blog commentary on the gervais principle. Later I learned that the prolific blogger had worked for a google and other tech titans. Last week, he published an expose on the early-stage Silicon Valley funding works, titled Y Combinator and Paul Graham are bad for the world. I thought the world deserved to hear a different view.
It’s time for me to tell my story. Continued »
Some agile and lean people like to use the phrase ‘fail fast’. That slogan is usually a call to be brave and try new things that might not work out. Looking a little deeper, there is an encouragement to find what doesn’t work early rather than later when the stakes might be higher. I’ve never been a fan of the saying. Failing isn’t my idea of a good time whether is happens now, or later. And aside from that, I think it encourages the types of behavior that slow a company down instead of drive it forward.
Let’s take a closer look on what it means to fail.