At the recent 2019 Capability Counts conference, hosted by the CMMI Institute, I presented a session related to Enforcing Quality with DevOps Pipeline gates, where I provided an introduction to the concepts and technologies of DevOps, and how to use the concepts of Continuous Quality to improve software quality earlier and throughout the application lifecycle.
Here are the slides, published on SlideShare, if you’re interested.
A dedicated employee who will work harder, with a greater sense of urgency (and maybe some extra hours when needed) is great. But what’s much more valuable than someone with that work ethic, is someone who can see when working harder isn’t going to work, and they need to change their approach.
Think about someone using a dull saw to cut a huge pile of wood to build a house — they’ll look at the schedule and say “I don’t have time to sharpen my saw”, which is ridiculous to think about. But we do it all the time when we try to shift into a higher gear and work harder to “dig out” of a busy season/project instead of thinking about what should we change.
It is so valuable as a leader to determine when a situation can be surged over, and when you need different resources/capacity/people/tools to overcome the situation. Years ago, I was helping a Project Manager whose team was continually well below the needed velocity to get to the project’s finish line on time. He kept trying to work nights and weekends to get back on the track, but simple math made it very clear that he could not single-handedly get the project back on track. So we had to investing in both a technology and some additional people to help his team finish — it was easy to easy for those investments on his project; but it was much better to ask for them early in the project’s life as opposed at the end when he would be doomed to fail.
Think about if you need better processes/checklists, or a tool (e.g. software application) to help you be more efficient), or more people on your team, or something else. Take the time to step back and think about how to change the game you’re playing so you can actually win.
There should be a word for people who have the annoying tendency to point at problems and talk about them, instead of trying to actually improve the situation (or maybe there is, and I just don’t know it). I don’t know if you’ve been in a meeting with one of these people, but it’s so frustrating to listen to someone pontificate on and on about some problem and how it’s SO horrible, without trying to come up with any ideas, or asking someone to help them solve the problem, or just stop talking about it so someone else can try to solve the problem.
I’m not saying you should wait to bring a problem to your boss until you have a solution — for some teams/problems that’s a good idea, and for others that’s a horrible idea, and you need to get help for problems. But what I am saying is that you should focus your attention and energy on fixing the problem, or removing the problem, or getting around the problem, or changing the situation so it’s not a problem anymore, or something else productive.
I went to the eye doctor recently, after my eye was bothering me. I had slept in my contact lenses for several nights (which I’m prone to do), and my eye started bothering me. In the past, when this happens, I take my contact lenses out, throw them out, and take a few days off of contacts. This time however, my eye was bothering me much more than usual, so I went in to see the eye doctor. I’m glad I did — I had a corneal ulcer, where bacteria had been stuck inside my contact lens. The eye doctor got me a prescription for some antibiotic eye drops and explained how lucky I was, since the ulcer wasn’t on the pupil itself (which can cause people to lose partial sight the rest of their lives!!!)!
The doctor asked me “Do you know you’re not supposed to wear your contacts overnight?” and I explained that I certainly did, but I had no idea what the real risks were — I assumed eye doctors said that, but that my approach to taking a break when my eyes bothered me was fine.
This is a great reminder of how important it is to communicate risks in a tangible, clear way. It’s easy to say “That’s risky” or “This is not a best practice” or “It’s better not to do that”; but if we don’t take the time to truly articulate the possible impacts, explaining both the likelihood of something happening and the impact (severity) if it does happen, very bad things can happen.
Edward Tufte’s book Visual Explanations provides a powerful case study of this concept: Engineers recommended the Space Shuttle Challenger not be launched based on specific weather conditions, but the launch was approved due to a lack of clearly communicating risk.
I’m no expert, but here’s some baby advice for anyone about to have a child:
I recently chatted with Tom Cagley on the Software Process and Measurement Podcast (SPaMCAST) about some of my experience helping scale operations at Halfaker using best practices from various business books (e.g. Good to Great), frameworks (e.g. CMMI), techniques (e.g. Agile Scrum), and tools (e.g. JIRA). I really enjoyed our discussion on why I was excited to JIRA, a tool that is not very opinionated, so we could configure it in some specific ways for individual Halfaker departments and projects.
The SPaMCAST is a great resource for learning more from great thought leaders in the Agile, Process Improvement, and Software Engineering world. Check out the interview at:
And if you’re looking for a Podcast app recommendation, check out Castro for iPhone/iPad. It has this great “Inbox” concept (works like an Agile backlog, where you can accept things into the backlog and then prioritize/re-prioritize them.
Early in my career, I was a leadership development conference (through Lockheed’s great Engineering Leadership Development Program), where we played a game called Gold of the Desert Kings — it was a group game, in a big event space ballroom packed with engineers from all over the country. I don’t remember the rules of the game, but I do remember that it was a powerful reminder of how important it is to plan before you start working.
It’s easy to say we should plan before we start doing work — people say things like that all the time:
But while we talk about this often, most people often regress back to a tendency of “jumping in” under pressure, instead of taking a breath and investing the energy of actually building a plan.
At the individual level, people are very quick to start working, trying to “make progress” and “feel productive” without investing the time to validate that they’re working on the most valuable thing. When groups of people (teams) are involved, we’re even worse at this — not only does the team want to jump in to avoid the plan of group planning and not feeling productive, everyone wants everyone else on the team to be productive (busy) so they feel they’re not the only one working hard. This creates this nasty culture where the team is trying to keep everyone busy (Instead, Goldratt’s The Goal teaches that we need to optimize the entire system, not at the individual person or machine level).
Yes the plan will change, but it’s not the first version of the plan is not the valuable part — it’s the exercise of pulling together all the different pieces of a project and thinking about them together that is valuable.
While making progress on some new task feels more rewarding and productive than building a plan, whether it’s an Agile backlog; a resource-leveled Microsoft Project file; and/or a few quick PowerPoint slides summarizing major activities, schedule, resources, and budget; INVEST the time to make a plan — make sure before you start sprinting in some direction that you’ve actually checked to see if that’s where you should be running.
My grandfather, a NASA engineer who worked on telecommunications systems for many of the Apollo missions was always coming up with things I never saw anyone else doing. Some of that came from having engineering education and skills, but much of it came from a willingness to learn new things — he was never intimidated to do something new.
He loved telling the story of his father wanting to keep squirrels off his grape vines, so he
problems. My grandfather didn’t want my dad worrying about the car when he should be focused on school, so my grandfather bought a mechanic’s book on the VW bug and over a weekend he rebuilt the entire engine in his garage and brought it back to my dad. I heard this story while helping my grandfather adjust the spark plug timing on an old 1970’s Plymouth in his driveway — it was a fun afternoon learning how engines run.
As I’ve gotten older, I’ve realized how each person has different tendencies. Some of us are introverted. Some are analytical. In addition to personality axes like introverted vs. extroverted, thinking vs. feeling (see Myers-Briggs); people often have a tendency to either live in one of these times instead of balancing their time among them:
Each of these perspectives is important in moderation, but people sometimes get into trouble by being too focused one view — they can get stuck reliving the past (they miss life entirely, always looking behind them), living only in the moment (reacting to the present without looking down the road and making any plans) so life happens to them instead of creating the life they want, or only focusing in the future, so life passes them by while they make and refine plan after plan. Don’t get stuck in only one of these — make time to look at all 3.
To quote the cinematic classic Spaceballs, which is almost partially relevant to this discussion:
Colonel Sandurz: Try here. Stop.
Dark Helmet: What the hell am I looking at? When does this happen in the movie?
Colonel Sandurz: Now. You’re looking at now, sir. Everything that happens now, is happening now.
Dark Helmet: What happened to then?
Colonel Sandurz: We passed then.
Dark Helmet: When?
Colonel Sandurz: Just now. We’re at now now.
Dark Helmet: Go back to then.
Colonel Sandurz: When?
Dark Helmet: Now.
Colonel Sandurz: Now?
Dark Helmet: Now.
Colonel Sandurz: I can’t.
Dark Helmet: Why?
Colonel Sandurz: We missed it.
Dark Helmet: When?
Colonel Sandurz: Just now.
Dark Helmet: When will then be now?
Colonel Sandurz: Soon.
Dark Helmet: How soon?
