Faster! Faster! Faster! That’s what every software company seems to be screaming for right now… Give me more SPEED, Faster! Faster! Faster! Give-me Agile, Give-me DevOps…
I’ve spent most of the last 5 years working for large companies that have become obsessed with speed and change control. That said, the joke is, “They test in Production” even though QA and DEV environments exist but are very lightly used for what they were built for.
That’s bull, you say! Really? If you or your deployment team are constantly rolling-back code releases then what does that mean? Please read on…
Is Apple to Blame?
Everyone today wants to be like Apple raking in billions of $, right? Apple is awesome at building and delivering products … fast! But I recall a while back when the new iPhone 4 was released with a problem where it would lose its signal if you held it a certain way. Remember that story, and seeing Steve Jobs on the news getting in front of bunch of reporters and saying, “Just don’t hold it that way!” [Paraphrased]
Aside from the way this issue was perfectly handled by Steve Jobs, it was a problem that was missed (or ignored) by Apple’s QA. Would you want to be the guy or gal who had to delay the release? Hell no! But it shows Apple is made of humans too…
Has IT Finally Become Obsolete?
For years, IT has lived in a box with nicely drawn out boundaries between technology teams. We have networking, security and server engineers all separated out in neat groups that we like to call teams. And on the other side of the curtain, we find a bunch of people that are called developers (as well as other creative names).
These people (Developers) are constantly stressed out because sales and marketing are never happy with, well – ‘Sales numbers’. It seems the customer always wants something else, or something new, or something changed. And – as they say, “Shit rolls downhill,” and therefore the dumping ground is Engineering or using the new buzzword – DevOps.
The food chain (or pecking order) looks like this: the customer feeds on the sales team, the sales team feeds on marketing, and the marketing team feeds on product development, PD feeds on the DevOps Team. Only DevOps fights back or ignores PD! This cycle plays out over and over, until there is a re-organization. Then the cycle starts all over with fresh people and nothing really gets fixed because nobody really knows what they need to fix.
Been there and seen this movie several times.
By no means am I an expert but I’ve watched this movie multiple times and have come to the conclusion that people are the problem. So what’s the solution if people are the problem?
Here’s my recommendation in 5 steps to solve the people problem. They will not be easy to accept or implement.
1. First you need to start with clear leadership that knows what he or she is doing. In other words, this is not an experiment for them or their first rodeo. They need the experience of having been there before. I think more projects fail for this one reason and it’s because it’s human nature to want to use existing staff that have no concept about what to do or where to start. Then of course we want to pick our closest friends because we want people we can trust.
Point: This is a recipe for failure and it happens all the time. The solution is to hire a leader that’s done before.
2. Next, it’s about finding experts in the field to consult with that will be honest and tell you the truth. If your experts are telling you what is coming down the track is a train, why aren’t you listening to them?
Trusting the people that should know what they are talking about is another key. Also note that the experts should actually have a track record of success and not just be your trusted friends that are telling you what you want to hear.
Point: Listen to your advisors unless you are more experienced or informed than they are.
3. Number three should actually be number one on the list – listen to the customer’s feedback before you build or code anything.
Steve Blank wrote a great book that everyone in software development should read. It’s called The Startup Owner’s Manual. It’s a big heavy book, more than an inch thick, and has plenty of examples of how people are the problem. According to Steve’s research, one of the main reasons software companies fail is because they are not getting customer feedback regularly. Steve talks a lot about something he calls “Customer Development.” He actually recommends that executives go out and talk to their prospective customers regularly so they understand the problems they need to help solve.
According to Steve Blank, far too often features and products are created that nobody has asked for. Not only is this a waste of time and money but no doubt it caused a lot of stress to produce something that wasn’t wanted.
- Do you know what your customer are saying?
- Also, how is what the customer is saying being translated?
- More importantly, is the external customer the only customer who should be listened too?
Herein is the problem that causes most of the trashing among developers and engineers. Listening…. Or more accurately put, not listening then making a bunch of assumptions that are wrong which turns into a blame-game and only adds to the problem and causes more delays.
Point: Get everyone on the same page and understand what the objectives are before any work starts. Even small steps taken in the right direction are progress.
4. If software development has been around for decades, why then has product development become such a problem in the last 3 – 5 years?
My guess is because – in today’s instant gratification world we want everything now. Thus – the “Lean” books, blogs and raving testimonies of how Agile Project Management will solve all the problems. And don’t forget everyone that has read an Agile book has become an overnight Agile expert. Except Agile actually adds to the problem because the proper time it takes to adapt the teams to Agile, or more specifically Scrum processes, has not taken and the people whom have always done things their old way never seem to change so we end up having a race car with no gasoline (Or as ScrumBob calls it, ScrumFall which combines Scrum with waterfall).
DevOps is a Culture
Along with the Agile process has evolved a technical group called DevOps. DevOps team players are supposed to just do whatever needs to be done regardless of what they used to do. The problem is these folks are normally very proud of their accomplishments as network, security, or system engineers. So when a developer asks them to do small tedious things is insulting. This is because the DevOps culture required to have this cross team relationship has not developed.
As a former Marine, I recall the Marine Corps training everyone to be a basic grunt before they sent us to specialized training of any kind. Everyone knows how to fire an M16 and can shoot the balls off a charging Rhino at 100, 300 and 500 meters. [Exaggeration mine own] Marines are also trained to cover each-others back. In a DevOps culture, team members are expected to do the same. The USMC takes this very serious and has a motto that says, “The Few, The Proud, The Marine.” In other words, not everyone is selected or is cut out to be a Marine.
Scrum and DevOps teams should be made up from people that can adapt, do what they are asked when they are asked, and according to Steve Blank, they must be able to pivot (change direction) fast. Most software companies are trying to just force everyone to become Agile and it causes problems (I’ve seen it twice at two big companies). It doesn’t work that way!
Point: If you have a group of people working for you that need to know all the details before they can do any work, or they always have to have input, or they need to include their own methods or processes because they are ‘Process oriented” – God bless them, but you need to find another team or you will fail. I’m not saying to fire them because these structured process driven people are still valuable but they are just not part of the “Few” that can be called Agile or DevOps.
5. Reward your top performers. If 80% of the work is done by 20% of the people, then why aren’t they getting 80% of the pay? Or at least bonuses?
People will surprise you for incentives. Was LeBron James the key to the Miami Heat winning the NBA Championship in 2012? Is there any surprise that he makes so much? Yet, we want to treat people like cattle and expect them to perform like champions!
Just to be balanced on this touchy point, if you are paying people like champions and they are behaving like cattle then you are the problem. My guess is these low performers are your friends, or because they’ve been around since the company was founded nobody wants to hurt anyone’s feelings.
Good luck solving the customer’s problems because people that will not adjust or adapt will constantly consume 80% of your valuable time because they are never happy and are always spreading the gossip of how they were right and you were wrong.
Point: Reward the rock stars and remove the problems….fast!
How does VMware fit into Agile and DevOps?
You may be thinking, “What does all this have to do with VMware vSphere?” Well, VMware vSphere, if built right, will provide all the speed on the backend that DevOps need to support developers. One of the most important keys is making infrastructure transparent and simple to use. This smoothing out the wrinkles helps.
The complaints I’ve heard from developers are normally related to needing servers NOW, not 2 – 3 weeks from now. The bottom line is to make your infrastructure transparent … a non-issue.
Here’s the reality, if you can’t solve this problem you will soon find out the hard way that developers have a straight communication path to the president or board of directors, and once they complaints and noise start and becomes loud enough for you to hear it, it’s already too late and decisions are already made about your job new job title.
Avoiding Mistakes with Agile, DevOps and VMware Takes Guts.
In summary, the five steps for DevOps success are:
- Leadership –Start with experienced leaders that know what they are doing.
- Expertise – Surround yourself with technical expertise.
- Listening and understanding – Stop assuming you or your staff understand the customer’s problems unless you have actually spoken to the customer yourself and heard what they are saying.
- Agile – Being able to adapt and pivot without trashing. Not everyone can do this and those that can’t should not be on the team.
- Rewarding top performers and remove problems. As I stated, I am convinced people are the problem so if you can’t do what needs to be done let someone else do it.
- Bonus: Making infrastructure transparent.
Do you agree or disagree with my point of view? Please leave your comments.