Scrum is one of the most popular tools among companies claiming some sort of agileness. Every company I have worked for, or with, in the past decade has had an official daily scrum or at least some sort of daily status meeting that had very clear ties to the scrum format.
Despite the near complete saturation within software companies, most people have problems with the format. The meetings become a benign, no value add, aspect of daily life. Or, they create information overload when the team gets blasted by its own problems on a daily basis.
Is Scrum just a narrow tool that isn’t useful for most teams, or are most teams just plain bad at making use of it?
My colleagues, Matt Heusser and Markus Gärtner have been busy working together to publish a new book called Save Our Scrum.
Let’s see what they have to say.
Companies have a hard time putting out software, and an even harder time doing it on time. There are lots of different things that can go wrong from veering way off course from what the customer wants to never ending problems in implementations to having no clue how far you are from the beginning or how close to the end.
For the past 20 years or so whenever people are having these problems, a new process framework has been the answer. There is XP which puts 2 programmers working on one problem, lean tries to remove all the cruft so that all you are left with is value, and then there is scrum.
Scrum is often one of the first things people try when they want to shake up their development process and hopefully fix a lingering problem or two at the same time.
Why Scrum though? What is the value in this practice?
Many years ago, I had an opportunity to get certified in a number of areas at a company I was working at. This was actively encouraged for a simple reason. The software company that was licensing products for our use and deployment gave us a price break if we had x number of people on our staff certified in particular areas. While the certifications had a specific means to an end, at the end of the day, it wasn’t so much the certification that lead to anything different about the work we did or the responsibilities we were given. A demonstrated commitment to understanding and using the skills we had acquired had more to do with being trusted with taking on greater roles and responsibilities than the certification ever did.
Email has been around for a long time, and is starting to fade from popularity, but it is hard to underestimate how much it changed how professional communication happens. We went from expensive long-distance phone calls that had to be carefully scheduled and timed, to electronic letters that can go around the globe in an instant.
Now, email is the exact opposite of cool. It still gets used pretty often, but instead of pulling up Outlook every time we want to talk to a coworker, it is for things like long form memos from the CEO that end up dissected in a news article a few days later. Stuff that needs to live for a while gets jammed into a wiki where everyone can see it and edit when needed.
Email has traded places with messaging services. It has been a gradual change for sure, different IM clients have been used, especially in tech forward companies, since the mid 90’s. Now, IM is the gold standard for office communication.
Lets take a look at why that is good and bad.
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.