Deep In the Value Stream

How Far Do We Go?

In my first few years of DevOps experience everything was clear and the goals, the end results and the tools to get there were just hitting the market. Everything seemed kind of easy.

Simply, state the problem to be solved like config, infrastructure, secrets, build and release and there were bound to be at least 3 things to choose from online. The market is still new

and there are lots of nice and some not so nice products to play around with. So, I'd pick one up off the shelf of community and Google results that best implemented the principles I had read about.

The approach and the proof of concepts were solid. Choices were easy and implementation was mostly guided thorugh all kinds of resources online. Mix that with a little creative freedom and you've got yourself

a little powerhouse of a setup. This was a fantastic way to ramp up from within my small DevOps team, but fastforward a few months and things weren't quite all cracked up to what I thought they'd be.

Laying the groundwork with sophisticated tools was actually only about 30% of the battle. Sure, I can fling code out into production in like a minute but was it even good? Realizing I've either setup the best thing or maybe it was the worst thing,

at that point I was sure it was the best and I was right. The goal still remains, more deploys NOT more problems. The new feeling of not knowing what might come out the other end of that CICD pipelie I setup couldn't be ignored anymore. Feeling responsible

for the new speed at which bugs could get out into production made me realize that (like said in Google's SRE handbook) this automation is applied force and amplifies what ever problems were already there.

Now that the problems were visible, I had the buy-in from above to periodically switch on the development hat and get into the teams.

This is where I learned how necessary it is to go far and deep into code. I began the most accessible way, not checking Jira for re-work labels, not analyzing statistics out of jenkins, nor github stats, none of that was really necessary. I just began visiting dev teams every few days.

I'd listen to them, size up their leadership style and start checking out code. Well first, I'd just look at it for anti-patterns, overly complex code, bloat etc then I started checking code out. The I started making pull requests.

If you've worked with developers before and you're new somewhere, I highly recommend hanging out with them like i mentioned above. You could get in and make pull requests without showing face but your code will always get into master faster if you're 'one of them.'

Not only will your code get in faster but your trust factor will sky rocket which is just as important as being a great developer. Most importantly though, you'll learn from each other. What to do, what not to do, how you'd solve a problem vs how they did. This is just one example of how to properly

get a DevOps culture across. Once you have the beginnings of that, you're postured to make real change.

Lets take inventory of our propensity to change:

1) You have the foundation setup, a solid CICD pipeline for Team X and their projects. (check)

2) You have their trust and commradory as a developer, they pain/you pain. (check)

3) You've gotten into their sprints to see where bugs most commonly appear. ()

4) You've reviewed their testing capabilities. ()

5) You've identified weak and strong points in their value stream. ()

Ok, so you've got a distance to go but the first and most important pieces are out of the way. I see also a lot of management scoff at this inventory list although I've never actually presented like an inventory list. These steps are, however, absolutely necessary pieces to

real change in the development cycle. The completion of this check list is the path to better code, better understanding and therefore, by the transitive property, better business.

When you start on number 3, you start to see with fresh eyes, the issues and buried context of what problems within the team. More often than not, there's a general sense of 1 of 2 (hopefully not both) sentiments being haste or complacency. In either case you're going to identify a reason for either,

the developer is too siloed and therefore unexcited about anything OR this is a startup egos along with business are driving decisions. You'll operate in both during your career because you should! There is a third observation I've had where someone in a startup mentality is affecting their team as part of a company that has

all the luxury of planning, following Scrum to the nines and yet still acts like the world is burning. Get involved with these people, the psychology of it all is fascinating. Sometimes there are no problems but they're created, sometimes there are tons of problems and we're in denial. As long as

you can identify steps out of the cave and make small but forward progress you'll be on your way to numberr 4.

I say testing capabilities in item 4 and that can be taken 2 ways:

* The availbility of some sort of automated testing mechanisms that you can put into CI

* The testability of the code

Arguably, the first bullet point is easier to get ahead with because there are tons of products designed to make your life easier. Like Sauce Labs, for example, is a service that will execute your selenium tests reliably so you don't have to maintain a grid. The second bullet point, well, we're talking about code written by all skill levels of developers, possibly over decades. When I look to see if code

'is testable' I'm actually just looking first for unit testable code and then I go up the pyramid. It doesn't take much to check for testable code. If you find that your teams' code isn't testable, you know what your next step is. Its perfectly acceptable to take 10% of a sprint and use it for improvement. This 10% could be spent refactoring. What I've found is 99% of the time, refactoring will make code testable given the refactoring follows the principles of good engineering.

Great. I've identified some untestable code, lets say a method that is doing way too much. I broke out the logic into two seperate methods and now I've made a pull request. Explain why your refactoring is a good move. You've made peoples lives easier by creating two reusable methods instead of one, single purpose method. And additionally, the most important piece, the goal, I've written a unit test to accompany my new code in the same commit. Now lets take inventory:

1) You have the foundation setup, a solid CICD pipeline for Team X and their projects. (check)

2) You have their trust and commradory as a developer, they pain/you pain. (check)

3) You've gotten into their sprints to see where bugs most commonly appear. (check)

4) You've reviewed their testing capabilities. (check)

5) You've identified weak and strong points in their value stream. ()

Ok, now we're on to number five. It could be called 'Identifying Next Steps' because the information you're scouting out will be used to predict and identify areas of easy success and areas of improvement. You'll use technology and the previous 4 steps to

enhance both areas, this is a very good avenue to pull items into a backlog.

A natural flow into improvement, influence and ultimately a better botton line for business involves periodic sampling of team work, behavior, work flow and value stream management.

Ask Us