A few weeks ago we hosted another episode of our Continuous Discussion (#c9d9) podcast, this time talking about "Continuous Improvement ". Our expert panel included: Chris Nicola , co-founder and CTO of WealthBar; Daniel Rolnick , CTO of Yodle; Pete Grant , an architect specializing in automated testing; and our very own Sam Fell. During the episode, we discussed key prerequisites for continuous improvements, lessons learned from the field and tips around Organizational Design, Communication, Automation and Blameless Culture for facilitating and empowering change.
Key Prerequisites for Continuous Improvement
"Having a goal that you can't achieve with your current organizational design is a prerequisite" #c9d9 @petejgrant pic.twitter.com/ExDnmfqV1X — CloudBees (@electriccloud) June 28, 2016
Grant advises to aim high to see improvement: “One of the best prerequisites to have is a goal that you can't achieve with the current organizational design that you have. If you can say that you can deliver this one project that's worth tens of millions or even hundreds of millions and you couldn't have done that before, then your stuff is worth tens of millions or hundreds of millions - that is the thing which people can get motivated behind.”
Prerequisites for continuous improvement come from the organizational level, according to Rolnick : “An underlying prerequisite is having an organization that wants to change, is willing to change and is thinking about change. Give people a forum to have conversations and empower them to then take action on things they are measuring, see or observe. That way they don’t just have problems, they have solutions.”
Prioritizing is key for continuous improvement, per Nicola : “I think a lot of the time when you take a look at what's on the board you have to ask yourself, ‘Are any of these things we're talking about that we're not happy with pivotal to goals of the organization and our system? Are they going to actually result in big improvements?’ If they are, I suspect you'd be a lot more focused on them. If you're not sure, then it's very hard for people on the team to really understand why they're a priority, and so often they get left to the way side in favor of things that are more urgent.”
Have a #culture around maturity to handle conflict of change & the ability to self-reflect - @chrismnicola #c9d9 #ContinuousImprovement — CloudBees (@electriccloud) June 28, 2016
Do not throw out processes that haven’t worked in the past – they may work today, says Rolnick : “There is no guarantee that what didn’t work in the past won’t work today. Now may be the right time for it, or there is enough infrastructure there to support it. Revisiting processes as the world evolves, your company evolves and the market evolves is always important. Take time to step back and reflect on your processes.”
Having a solid management structure is crucial to continuous improvement, according to Grant : “One thing that helps a lot is being able to see everything that is going on, such that you can actually have that idea of the centralized commander of a project without having to come back to the one person who knows how everything is going on.”
Nicola discusses the negative effects of the “null-process”: “It’s something like - if you want to get something done in this organization, first you got to be friends with Bill, if you're friends with Bill then Bill will listen to you, and then you might make some progress - but if Bill doesn't like you, well, all bets are off. That's a really bad thing for a culture in organization, and it undermines effective communication within organizations. So I think we do need to be clear in organizations, we obviously don't want excessive or unnecessary processes, but we do need to have processes particularly around communication.”
Have purpose, agenda and preparation if you are going to call a meeting -- @petejgrant #c9d9 pic.twitter.com/cLsQtQze6H — CloudBees (@electriccloud) June 28, 2016
Look at the value of what you are doing when it comes to communication, advises Grant : “I think that what is fundamental is the stuff you are doing - if it is valuable enough then you can afford to say – ‘You know, this is a bit more than a five day thing, let's just put eight days in the plan.’ When you are clear on the benefits and they are that big, then you can call out that stuff in advance, set those expectations, which means you can afford a smooth transition.”
Communication should be spearheaded by leadership, according to Nicola : “Explicit processes should be there; in my opinion, it's a leadership thing, it needs to be done. We often talk about the problem with top-down management, but the job of management is of course to be top-down when it comes to recognizing where the lack of an explicit process is creating conflict, or negative conflict within your groups in organizations. They need to say, ‘OK, I see that we're not making progress here in our discussion, I'm going to propose that we do this a different way, a more explicit way.”
Company culture can have significant effects on communication levels, says Rolnick : “If you have a culture that is embracing of making change and is not judgmental of where the change is coming from, anyone should feel comfortable questioning the process. Even a process that everyone does every day – they should be comfortable to ask, ‘Why do we do it this way?’ They should be willing to say it and people should be willing to hear it and receive it.”
How Automation Helps with Continuous Improvement
"With passive tests, your effort isn't just used during dev/test, they are audits you can always run in your environment" #c9d9 @petejgrant — CloudBees (@electriccloud) June 28, 2016
Grant recommends Jenkins and DBfit to help with automation in data warehousing: “From a data warehousing point of view, my automation recommendation would be to start with the kinds of checks that you can use to make sure your data is right, and do them in a way that you can use them in production and on all of your development environments. Then, then have Jenkins control all of it, because Jenkins is a good tool for that, also a tool called DBfit, which works really well with data warehouses.”
Assess if automating is right for the task before jumping into automation, advises Rolnick : “When you encounter a manual process in your flow, don’t just say ‘Hey, we should automate this,’ you should ask, ‘Is it worth automating?’ If you are doing it often enough and it takes long enough, then it’s worth automating. Unless it’s really hard – then the payoff may not be there.”
Nicola on the automation of code: "The code itself should be testable, with almost no need for extra test frameworks or harnesses. That unit, system, or sub-system should be autonomous by itself, and verifiable on its own - this gives people the clear and explicit definition: ‘This is how you test this, this is how you verify it's working.”
"Giving people the power and comfort to be able to talk about anything, gives people a lot of power"--Daniel from @YodleTech #c9d9 — CloudBees (@electriccloud) June 28, 2016
"When something goes wrong, having people step up and take responsibility makes blame irrelevant." - @petejgrant #c9d9 — CloudBees (@electriccloud) June 28, 2016
It’s not always the people to blame, remarks Rolnick : “Giving people the power and comfort to be able to talk about anything drives a lot of this. Everyone has a situation where they were the root cause of something, but more often than not it is the tooling or process that really failed, they were just the person at the steering wheel when it failed.”
Don’t discredit those that make mistakes, says Grant : “When you have processes that are stronger, the people become a lot more valuable and everyone has a much better credit balance with everyone else on the team. Even though they may do things wrong from time to time, overall even people who mess things up are still valuable, and that can be a function of how well the team is set up and structured.”
Nicola advises to use caution when using the term “blameless culture”: “Ownership is really the key thing here. I do sometimes worry that the term blameless culture maybe focuses on the wrong part of it - you want a culture that fosters ownership, and makes people feel comfortable taking ownership on things that are sometimes going to fail. One of the ways that you do that is by having a good root-cause analysis, or retrospective processes, that allows people to take ownership, review and determine the root cause, and take action to remediate.”
Watch the full episode here:
Want more Continuous Discussions?
We hold our #c9d9’s every other Tuesday at 10 a.m. PST . Each episode features expert panelists from the community, talking about DevOps, Continuous Delivery, Agile and more.
Stay up to date
We'll never share your email address and you can opt out at any time, we promise.