More than once recently, I have both seen and had discussions about DevOps. Usually it begins with someone making the claim that the rising popularity of the term is silly. There are a few different ways to think about DevOps. Something along the lines of — a set of methods and tools that help developers get code into an environment faster — is good enough for me. Practically, DevOps has people writing test automation to reduce testing cycles, using tooling to get builds faster, and building tools to get a product delivered sooner. I like to think the word as an abstraction, like the word agile (or Agile if you must). It covers a vague group of things that you may, or may not do.
The debates I see are usually claims that DevOps is NOT new, ops and development have been working together to release software since the beginning of time. I think they are right to some degree, but I also think it’s worth digging in to.
I’ve had a chance to help out with a number of events this year, many of which have needed to have what are, to me, fairly straightforward technical things that need to happen. Tickets need to be sold (or payments need to be processed), updates need to be sent out, and some fun stuff needs to be planned. Having spent twenty-five years in the tech industry in varying capacities, I will confess that I take many of these interactions for granted. I do some quick research, try out some vendors I’m familiar with, ask some friends their suggestions, and then I implement them. Some of them need a little tweaking here or there, or I discover something I didn’t consider when initially setting it up. A few fixes, and we’re back in business.
When it comes to talking about estimates on this blog, most of our time is spent avoiding them. That is, we talk about #noestimates, or alternatives to estimation. Some times, though, the boss wants a number. Today, we’ll provide one simple reality that companies tend to avoid about estimates … and what to do about it.
Here’s the reality: We never know exactly how long a project will take. Short of a Crystal Ball that tells the future, the best we can come up with a probability distribution; generally a Weibull Curve. To the far left of the curve, we have no chance of finishing the project on time, no chance at all. Then, at some point, we have a blip – the curve tics up. This is the everything goes right date; if there are no interruptions, no multi-tasking, and no re-work, we could get it done there. In their book Waltzing with Bears: Managing Risk on Software Projects, authors Tom DeMarco and Tim Lister call this the nano-percent date, and suggests that technical staff are very good are figuring out that date.
The problem, of course, is that the nano-percent-chance date becomes the date. Powerpoint decks are created with the date as a bullet point; bonuses are slated to go out if the project completes “on time.” All this based on the schedule that has a 1% or less chance of success.
As happens on projects, things do go wrong, and the nano-percent date flies by.
Here’s what to do about it.
There is trouble in paradise, there was bound to be.
We are finally getting reports of how the latest management and organizational structure, Holacracy, works in practice. When I say reports, what I mean is that the sweet sweet kool-aid of new and shiny has worn off a bit and people are finally willing to talk about their experiences.
The fact that someone tried Holacracy is fantastic, we will learn from it.
Let’s take a look at why this style of management might be problematic for some types of organizations, and what the future of management might look like.
Each year I try to pick one gift for friends in technology. In 2013 it was Cubu, a card game that combined strategy and politics. Last year I got Zero to One, a book on startups and building the future by one of the founders of Paypal. I’m a little reluctant with books, because buying one implies an investment of time, so I went with an AudioCD folks can listen to in the car or while doing chores.
This year my plan was Strategy and the Fat Smoker, a book on the difference between knowing what to do business-wise (limiting work in progress and focusing for example) and actually getting it done. The fat smoker, after all, knows he needs to quit smoking, diet and exercise. And yet …
The fat smoker idea sounded good. There is no AudioCD available, the book is a bit of a slog, and, worst of all, it really seems to focus on strategy for a services firm. That’s great for my colleagues who are consultants and contractors, but not so great for other friends and clients.
Most of my gift ideas in 2015 have those sorts of drawbacks . I thought I’d tell you about all of them, early, maybe get your advice — and maybe give you some ideas. Continued »
There is a lot of folk wisdom surrounding sales that I’ve been reading about over the past year or so. All of this has of course become a lot more important since I went independent and now to some degree my ability to sell myself will determine how long I can do this. Most of the old-school literature and advice around sales revolves around the phrase ‘always be closing’. The gist of this, is that every time I’m talking to someone, I should be driving toward getting them to sign on the dotted line. Every interaction is about moving from the courting phase into paying work.
Whenever I talk with people that I respect that somehow have sales as part of their role, maybe they are business owners or service sellers, that phrase never comes up.
Yesterday I came across an article that was called – IT doesn’t matter; written by Nicholas Carr around 2003 (almost 12 years old). It was published in Harvard Business Review. Back then, he was ridiculed for the thought, which now seems to be proving right and apt in the current business situation.
Start-ups are coming up in a big way and lot of new businesses are either generated or driven by or driven through these. And looking closely at quite a few of them , one can see that most employees use all sorts of tools, apps, networks, devices – however, there is no central IT team.
Let’s talk about what that means in practice. Continued »
There are quite a few ways to figure out how long a task I am working will take. Some people use estimates, some people abandon estimates all together and just do the work, and some use an idea that Matt calls Yesterdays Weather where we base next month on what we have been able to complete in the past.
Right now, I use a mixture of those techniques to figure out what I can get done from month to month. For the most part, that has been working well. It is definitely early in my independent career to call this a trend, but I have not missed a deadline yet.
The problem is, my flow is really wacky.
Yes, the title is cheesy, but it is not click-bait, I really do think I have an idea to encourage new speakers, new talks and new avenues of exploration and experimentation. The added benefit, it often involves food or, at the bare minimum, hot or cold liquid.
Over the past few years, I have traveled to and participated in a variety of conferences covering a variety of subjects. In almost all of them I’ve been able to participate in an event that goes by different names, but meets the same purpose. Lean Coffee(tm) was started by Jim Benson and Jeremy Lightsmith as a way to discuss Lean business techniques without having to make a big structured bureaucracy. The idea is that the group doesn’t rely on anything or anyone, just people showing up and deciding what matters to them.
No one really likes performance reviews. They are uncomfortable for managers and usually disappointing for the employees getting reviewed. If you work at Accenture, then you recently got lucky.
This is probably more of an experiment at this point. Accenture is trying this out to see how they can manage promotions, reviews, and management without formal review. My guess is that they will be successful, they aren’t the first to try this out. There are plenty of studies pointing to data that says performance reviews aren’t all that useful. But, I think their success will hinge on abandoning other forms of snake oil management at the same time.