Agile | Matt Studley - Technical Coach

Why I’m not looking

Posted on August 10, 2020August 10, 2020 by Matt Studley

I, like many since the COVID-19 pandemic started, was released from my contract in April. I’m not sending resumes out every day to every agile coaching job I see on the market, though. In fact, I am being much more selective in what I am looking for and what I’m doing. It’s not vacation time, either. I’m up every day, working.

What am I up to?

Building this blogging habit. Thanks for joining me, by the way!
I am also figuring out how to edit video and audio in order to launch a video/audio series with one of my colleagues, Tyler Haycraft.
I am participating in coding projects where the customer is first and the art of the craft is second.

But why?

Why am I focusing on blogging, video editing, and seemingly anything but “finding a real job”? Because I’ve spent the last 10 of my 12 years in the industry dealing with situations that put me in dissonance with myself. And after a decade of being quiet, or even passive – I’m sick of it. So I’m going to spend the next several months saying what I have to say, and doing what I want to do. Period. Because It’s time I stop shutting up about it.

I’ve always used coding and technical practices as a way to do good in the world.

I’m not great at carpentry, metalworking, sewing, drawing, or other maker skills. Code is how I make things. I don’t code just for the sake of coding though. I code for people. I code to solve problems for people. And it’s the moment I see my software solving that problem, and the smile on the face of the person using it, that makes me think all the toil was worth it.

I adopted agile principles at my core two years into my development career because it made so much sense. It stopped releases from being late because it got rid of big, risky releases. It made us developers constantly talk with the customer so we would do the right thing.

Blending my technical skills and my people skills to become what’s been labeled as a “Technical Agile Coach” has always been my superpower, of sorts.

But looking around…

… a lot of the agile industry has gone away from doing what is right for the customer or the craftspeople. Scrum has come to be a synonym for agile (it isn’t) that gets forced onto teams. SAFe is becoming a synonym for agile at large enterprise companies (it isn’t). If you look, really look inside most corporations, especially in insurance and in finance industries, you can see that we haven’t changed at all. If anything, “Agile transformations” made things worse by wasting millions of dollars and making developers more miserable.

No more.

No more scrum mastering just to actually be expected to be a manager’s right hand. No more “Agile transformations” that are actually just big let’s-lay-a-bunch-of-people-off-and-do-more-with-less scams. No more.

Will I work again?

Absolutely. But I’m not actively looking for 40 hours a week “Agile transformation” positions right now, and that’s because I’m pretty frustrated with my industry. I’m frustrated with what we collectively have done to our own industry. And I want to get back to basics. I’m not sure what the next evolution is for a Developer turned Scrum Master turned Agile Coach, but it’s time to change.

So what’s next?

As you might have seen from my first video, Should Agile Coaches be Technical?, I am passionate about coaches having technical skills. I’m not just going to sit here and pontificate on a soapbox about that. I’m going to build some playbooks, some courses, some worksheets, maybe even an app or three, that help agile coaches, coaching software teams, get better at the craft. If that works out, cool.

I’m also going to keep blogging. I have a lot to say about my time working in this industry and it’s time I uncorked this bottle.

What I will probably do is talk with my network and, if the connection is right, do some non-transformation team level coaching, part-time. Teams that just want to get s#!t done but need an extra perspective. No SAFe, Scrum, or other framework BS. Just a radical focus on the customer and the team.

If none of this works out, I’m sailing away. You might find me on an island near the equator sipping something blue from a coconut.

Photo Credit: My lovely wife, Victoria Studley

Save your budget and hire the right coach

Posted on July 20, 2020July 20, 2020 by Matt Studley

How do we navigate the Agile Industrial Complex to make sure we are getting the right people and solving the right problems? Most of the A.I.C. revolves around a coach or a team of coaches. I’m going to talk this week about how to go about starting a turn towards agility.

Before you start, make sure you are focused on hiring help for an organizational problem, not a departmental or team problem. I wrote a blog post on this last week, make sure you check it out.

If you are asking an organization-level question – and you understand that you’ll be changing the way the entire organization works (this means the entire corporation: marketing, sales, HR, finance, no really… everything) in order to achieve better results – then you’re ready to look for some coaches to help you through it.

By now you know that this isn’t going to be easy. Having some help is a good thing.

The first thing to understand about an agile transformation is what I call the Transformation Paradox:

You become agile by being agile.

What this means is that agile is not a noun. It is not a person, place, or thing. It is an adjective. You use agile practices, behaviors, and mindsets applied to the action of accomplishing your organization’s goals. It’s not about being agile. It’s about being better at reaching your goals.

My first piece of advice: Avoid choosing an agile framework when you first start out.

Do not get tempted by SAFe, Scrum at Scale, or any other framework. There is no framework for “Agile practices at company XYZ”. You and your team, guided by a good coach, help you author this.

Instead of trying to find a framework, you want to find one coach, or maybe a few at most, who can do the following:

Work with you to flesh out the desired measurable outcome of the effort invested in moving to a more agile way of working.
Build a trusting relationship with you and the rest of your executive team.
- Chemistry and trust are critical to success but are hard to objectively measure. You have to be able to work with this person.
Objectively, and honestly, look at the flow of work through the organization and spot the issues affecting it.
- The coach has to have access to all corners of the organization. The coach has to be able, to be frank with you, and you have to listen. This is why having the correct problem to solve is so important.
The coach needs to have experience and knowledge of multiple patterns, tools, practices and can use his or her experience, backed by data and facts, to present a unique combination of actions and behaviors that bring your organization closer towards an agile mindset.

The best way to find these coaches? Look towards individual coaches or small, independent practices. Individual expert coaches will have a profile site, some sort of an LLC, or otherwise are incorporated, and should have a portfolio of previous companies where they did work.

Here’s a quick tip: Surf Twitter and LinkedIn agile groups.

Watch for those who ask good questions and foster good discussions, and start from there.

If a coach or agile practice leads with a pre-made, certification-heavy framework rather than a business outcome that they worked with you to create, reconsider whether working with them is in the best interest of your organization.

A lot of large staffing agencies have started to build or purchase agile practices. Their recruiting network can get a lot of coaches in front of you quickly, and it can be easier to have another organization do the vetting for you. But take heed. They also have disadvantages. Sales staff, tempted by sales goals, may advise you to hire more coaches more quickly than is appropriate, leading them to push quantity and not quality. Trust, but verify.

I personally believe you have enough problems as a business leader without also dealing with a third party organization trying to hit some sales goal that is not aligned with your business outcome.

Like my tip above about surfing Twitter and LinkedIn, you can help detect certification factories by what they post. If they post lots of certification classes, offer an “easy button”, and put more emphasis on their title than their outcomes, then consider what their focus is.

They should be focused on you.

Finally – do not set aside a huge staff budget for agile transformations. Most successful agile transformations start with a single team experimenting outside the normal constraints of the organization. A single coach can run this experiment. This is how your organization discovers what will actually work in your real, actual business.

If you hire ten coaches all at once, you invite a lot of thrash and chaos into your organization as they try to figure out what works. Please don’t do that.

Run one experiment, with one, or maybe a few senior-level coaches. Then work with them on how to scale what is proven to work, by having done it already at your company.

Hire a coach. Work with that coach to determine a definition of success, a logical first step, and then fund and support that step.

Plan. Do. Check. Act. Repeat.

Photo by Micheile Henderson on Unsplash

Thinking about hiring an agile coach? Consider this question first.

Posted on July 13, 2020July 13, 2020 by Matt Studley

This post is aimed at the leader that is thinking about one or all of these things:

Starting an agile transformation
Hiring agile coaches or scrum masters to boost your teams’ performance
Trying to reduce the operating budget while bringing a product to market faster

There are a ton of resources, advertisements, and agencies that all revolve around agile coaching, especially targeted at enterprise-sized companies. If you’re in a leadership position in a company that deals with technology (hint: yes, that’s your organization) you’ve at least been pitched to about the merits of Agile Development.

Unfortunately, in the last several years we’ve seen an intense wave of what is now called the “Agile Industrial Complex”. That’s all the certifications (CSM, CPO, SA), frameworks (SAFe, Scrum, Kanban, etc), agencies (“agile consulting practice” is a common name), conferences, and the list goes on. For all of us that are in this industry, let’s be honest and take our lumps on this one: a lot of this isn’t actually helping organizations’ agility. In many cases, it’s hurting it.

I’ve seen and been part of more than one transformation where the following was all happening at once:

Leaders didn’t state the problem they were trying to solve because it was “business” and not for IT members to worry about
An agile practice’s sales team acting as representatives between the business and the coaches.

It took months just for the coaches to figure out what the real problem was that they were trying to solve. At bill rates in the hundreds of dollars per hour. Paying a bench of coaches thousands of dollars per week to work on the wrong problem is a waste of your organization’s money.

Before you start talking to agencies or coaches, ask yourself this one question:

What is the business problem that we need to solve?

The answer to this question should keep you and your leadership peers up at night.

If you’re wondering what kinds of problem statements work well with agile practices versus ones that don’t, here are some good examples:

“We’re losing market share because customers are frustrated with our product.”
“We’re not innovating enough.”
“There’s an emerging market we want to capitalize on, but we might not beat our competition to market.”
“We need to add a widget to our product to please our customers, but it’s really hard and we don’t know how to do it.”

And examples of what to avoid:

“Development teams are not fast enough.”
“We need to reduce operating expenses (opex).”
“We need to say we use Agile development to attract better talent.”

Either way, your problem statement is still valid

If you are relating to one of my “Not great examples”, this doesn’t mean your problem is invalid. These are also real problems that are challenging. But agile isn’t the right tool for unilaterally fixing these problems. If you need to reduce your operating expenditure, reduce it. Starting by identifying waste in your processes is a good start. If you use traditional methods, like staff reduction, you’re probably going to lose development speed – but a bad agile transformation being done for the wrong reason is going to dramatically increase your spending and will definitely reduce your development speed.

How can I tell if agile coaching is right for my organization?

Here’s a quick litmus test on whether the problem you are trying to solve can be solved by adopting agile practices: Your problem statement is an organization-wide statement. Not an IT-department-only statement.

This leads me to quote another expert on agile that I agree with on this matter: Allen Hollub.

“Teams aren’t agile. Organizations are agile. “
Allen Holub – “How Agile Work Actually Works with Allen Holub”, Programming Leadership, https://youtu.be/nhkj52oYGyM

If you are about to start an agile transformation that is only for your IT or development department, if the impression is that agile is “just something developers do”, stop now. You don’t actually want to take on an agile transformation. Take your hundreds of thousands of dollars in the budget for coaches and do something else with it. You could literally buy a yacht for yourself and do less harm to your organization.

If the problem you are trying to solve with agile targets a single department, please consider why you have that problem. There is a larger organizational problem causing it. There is no framework, conference, agile certification course, or coach that is an “easy button” for fixing organizational issues. They also can not substitute for the combination of experience and context that your team members possess in regard to your specific industry and problem space.

Agile isn’t for me. Now what?

Ok so now what? What if you need help, and want someone to help you that can get you going in the right direction? At this point, we’re talking about executive coaching and we’re leaving the agile transformation space. And that’s ok.

Now we’re no longer talking about agile coaching or an agile transformation. There are a lot of executive coaches that specialize in helping leaders set the right expectations and learn how to focus effort on the right problems.

I still want to talk to an agile coach

I’m prepping another blog post that will help navigate how to navigate the Agile Industrial Complex. Here’s a quick tip that cuts through the noise:

Most smaller shops and independent coaches, including myself, will give you a free one on one consultation that lets you discuss your specific situation, and determine the best path forward. Just remember to be honest with the problem you are trying to solve.

It’s okay if you aren’t ready for or don’t want an agile transformation.

If you’ve read this far, thank you for reading! I’ve seen millions and millions of dollars spent on agile transformation after agile transformation that actually made things worse. I don’t want that to happen to you.

Title photo by NeONBRAND on Unsplash

Automation isn’t just for developers

Posted on July 6, 2020July 6, 2020 by Matt Studley

When I write the word “Automation” in the context of a company – what are the first things that come to mind? If you’re used to working in a technology company, you might think of any number of things like CI/CD, Jenkins, Teamcity – automated testing – probably some other things too. Allow me to ask – when I asked about automation, did you immediately think of developers and coding in your head? You’re not alone.

But why do we limit the application of these processes to just the technical folks in the engineering team? If it can benefit engineers, it can benefit everyone else as well. I’m going to give two examples that show that automation – and a lot of devops practices for that matter – are for everyone, not just the engineering team.

A UX team that doesn’t use code – but it still can use automation!

In my first example – I once worked with a team that creates user help content in the form of web documentation. When they get ready to release a new version of their software, there is a corresponding release of documentation for the new features they made. The developers enjoy an automated build, automation testing, feature toggles – they do really well as far as devops practices go. The UX team that works on the web documentation? They manually test – they have a test environment, and they manually check each change they made – if they have time.

It doesn’t have to be this way. If we can make automated testing for web apps like Facebook, Spotify’s web player, and Fidelity’s financial retirement dashboards – we certainly can equip our web-based documentation teams with the ability to run things like dead-link detection, asserting that the new feature’s page tree is up and looks right – all sorts of things. How much time does the team take reviewing what they already did by hand – when we could have a machine do it. And then think about being able to automatically check everything you did in the past so that you can detect if something accidentally broke. There isn’t a code developer anywhere near this team – but that doesn’t mean this team deserves any less treatment with automation.

Can automation help reduce those boring status meetings?

Have you ever sat through a status meeting, where slide after slide, week after week, you see the same thing – this feature is red, this feature is green… so on so forth? This is another spot where automation can save everyone a heck of a lot of time – and give you an hour back on your calendar. Ask yourself this question the next time you are in such a status meeting – “Do I need to be here in order to learn the information being discussed here, and does everyone else need to be here in order for me to ask questions?

Do we need to manually create those slide decks every week? If the primary functions of creating the slide deck week to week are copy and pasting, then no – you can automate this! Don’t spend time copying and pasting, and don’t spend time in an hour-long status meeting where the rate of reading information is down to the lowest common denominator. What could you, and the poor soul who has to author the slide deck every week, do with that time back?

To wrap this all up – automation is not just for engineers or coders. It’s for everyone. If you feel busy but not productive, that is what automation is perfect for!

So automation is for everyone – now what?

If you’re reading this and thinking “This sounds great, but how do I start?” – contact me! Join my discord server Lunar Agility – https://discord.gg/jb75nn, or reach out directly linked in https://www.linkedin.com/in/matthewstudley/ – I’ll be happy to take a look at your specific scenario. If there’s enough interest I can even create a class.

Can VR diagrams be used to better articulate process flow?

Posted on August 21, 2019 by Matt Studley

When VR first started getting into the reach of mainstream consumers, I was excited. I remember my first experience, riding down an elevator. I looked down at my hands, and when I wiggled my fingers in the real world, the VR fingers wiggled, too. It all matched up, and I felt my brain say “Yup, those are my hands.” It was a complete suspension of disbelief.

A lot of VR is currently centered around fun and games. I’ve been so immersed that my reflex system engaged and launched me into a very non-virtual, very real, very hard wall during a mishap with a virtual fighter plane. Everything but my pride was fine in that incident, but this got me to thinking… Can we utilize virtual reality to enhance our communication and digital articulation within the Agile coaching space?

I’ve got a few things that I’m researching and spending some think-time on right now, but the first of them is how we as coaches describe process problems to leaders.

I think a lot of diagrams try to describe multi-dimensional problems in two dimensions

In a two-dimensional diagram like Visio, Gliffy, etc, it would be hard to get a holistic overall picture that was meaningful. Often what I’ve seen is a process map for each of the horizontal slices of the process, or worse, a diagram that’s so large trying to fit everything in that it almost can’t be opened by your laptop. While creating Lean process diagrams for several teams inside of an insurance company – a lot of the difficulty and resistance from individuals to assembling those diagrams came down to frustration at the lack of information a diagram had. “It’s not a two-dimensional problem.” I would tell them. “YES!!! You get it!” They exclaim.

Another thought – the average human brain can retain seven (plus or minus two) things in short term memory. If we have Architecture, QA, Development, UX, and Project Management horizontal slices each with their own, we’ve already taken five of the slots before we’ve even dug into the problem. If you are an Agile coach trying to impart change on leadership that is happily horizontal, you are starting with a problem that’s already almost too big to describe in a way the brain can naturally grasp it. This, of course, assumes that your audience isn’t taking up those precious slots with weekend plans!

Can we use VR to make this easier?

So the thought occurred to me – can we use VR to better articulate what is happening when we ask teams for a feature? I spent some time putting my oculus to work and this was the result.

Now, if you’re inner Agile coach is screaming when you see this, that’s a good thing. Can you spot all the process issues?

I used an Oculus store application called Noda that is designed to create mindmaps, but I used it to create a fictional Flow to production Map, a spin on a Lean Process Map. It shows a fictional team, but follows a lot of patterns that I’ve seen. It captures a lot of hand-offs of a team that shows typical horizontal-slicing that occurs within enterprise teams that have not yet finished their Agile transformation.

The third dimension VR affords lets me do things like including the tools the development team is using but organize the blocks in such a way that when I look at the diagram head-on, those blocks are hidden and I just see the flow. But if I want to see what’s behind the curtain, I just need to duck my head around the block! That’s a lot better than, during a meeting, having to fish for another Visio tab or another slide in a slide deck.

The development process from an angle similar to that a traditional diagramming application would give.
A write code node with defect returns heading into it.
Behind the scenes of the development process.

Development team and data team interaction

Additionally, how many teams have described a process where they early on have to engage another upstream or downstream team and ask for a unit of work before they can continue their unit of work. with VR, we can take the diagram and map that process at a right angle to the main process we are mapping, showing an entire additional set of work that has to occur for this flow to production. Normally, that would go on another tab, the slide deck, or image. Now we can just turn our heads and see it. In this example, I show a database team being asked by the QA team for test data. When the inevitable question of “Why does it take the data team eight hours to get us a schema?” We can go through how the data team handles the request for that schema.

I think this does a lot better job of showing what happens when an organization makes a change and says “go”. The developers don’t just start coding – there’s architects, QA leads, and all sorts of activity that kicks off. Showing how far-reaching the change process gets and how quickly is powerful.

This is what makes me think that as virtual reality gets more and more accessible it can be used as a tool that can be used in everyday business to articulate difficult multi-dimensional problems.

But VR isn’t in the office – yet

It’s true, if I asked a client to purchase VR headsets for everyone in their engineering team, I would be laughed right out to the parking lot. I don’t think VR technology is enough of a commodity just yet for this to go get everyone into VR right now. But I think with the reality that virtual teams are here to stay, and a lot of new company being started without an office at all, that this technology is going to become more important and useful.

I think it’s reasonable to give the presenter or coach a headset, and to have it in their toolbox as a way to show complex problems that would be well served by having a third dimension and full immersion to present with – especially with the latest set of VR headsets like the Oculus Quest being fully stand-alone with no expensive gaming computer required behind it.

Even so, I recently demonstrated this map using Zoom to share the virtual space to a fellow agile coach, who had no issues seeing the 3D space. ” So it’s not a question anymore of “Do we have the technology.”. It’s now “How do we make it consumable for our audience.”

I think there is a lot of potential here – what are some of your thoughts? I’ de be interested to try this in the wild – any takers?