Matt Studley - Technical Agile Coach

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

What I see when I read a job posting (Part 2)

Posted on August 24, 2020August 19, 2020 by Matt Studley

This is a continuation of going through a Job Posting for a Software Engineer that was posted the first week of August in 2020. We’re continuing our series of going through this job posting and pointing out where it may not be landing as well as recruiters and hiring managers think it is.

Make sure to check out Part 1, where we go through the hook of the job posting, here!

Who We Are-
With an energy that is infectious and a singular dedication to building on our successes, our people have grown our company into one of the world’s leading {redacted to protect identity} with more than {number} points of distribution in more than {number} countries worldwide. The success that we have built from our many years of creating products that people love is something we delight in sharing with our approximately {number} employees. But the best part about working at {redacted} is being associated with well-known brands that people identify with great taste, delicious products and consistent service across the globe.

This is an advertisement.

I’m a millennial – the demographic that’s approaching peak saturation in the workforce. Millennials don’t react well to this. Here’s a Forbes article that goes through some research on how Millenials react to advertising like this: https://www.forbes.com/sites/michaelfertik/2019/02/14/how-to-get-millenials-to-trust-and-respond-to-your-advertising/#4215c5236c81

The key from this article is “Millennials don’t trust advertising, celebrity endorsements or any of the more traditional, one-way communications strategies.”

This paragraph goes from bad to worse when it says “The best part about working at {place} is being associated with well-known brands… “. The best part of working here is I get to wave a flag? An opportunity to hone my craft while providing value to customers and making the world a better place by… no… just waving a flag. Got it.

With all the polarized, vigorous, and starting-to-be-violent flag-waving in the global context, maybe 2020 isn’t the best time to use “be associated with our brand” to attract talent.

We are poised for even greater success, and we need enthusiastic people who are looking for career growth at a company that encourages innovation and nurtures entrepreneurial thinking. If you enjoy a fast-paced environment, have a positive attitude, and are looking for a company that invests in its employees then please apply! For more information, please visit { Website URL }

We touched on why the term “fast-paced” makes me nervous in Part 1. A positive attitude is an interesting addition here. I don’t disagree with this but want to know more. This is where one of my interview questions would come from, this statement here.

How do we learn and get feedback for ourselves, our product, and the company as a whole?

If asking critical questions is not “a positive attitude”, then this is a recipe for trouble.

Put another way – I absolutely enjoy and think it is ok to expect someone to have a “Let’s do this!” attitude. I think if someone says “Hey manager, our approach is wrong” and the response is “You don’t have a positive attitude” then we have a real problem.

There’s a really good set of questions, one of which is “does failure cause inquiry”, and I’m trying to find the link to that list.

In Part 3 we’ll be getting into the actual role description. Up until now, it’s still all the equivalent of an advertisement for the company’s brand.

I think we need to do better.

As stated in the Forbes article, advertising like this doesn’t work anymore. Millennials are too skeptical, and social media for jobs – Glassdoor being one of the most prominent, is going to cross-check any claims made in this part of the job post very quickly.

Tip: Always write your job posting as if Glassdoor and other reviews were attached to it.

The Glassdoor review for this particular organization is 3.4 out of 5. The top pro was a benefit for time off, the top con was a lack of upward mobility in the company.

Let’s combine the Glassdoor comments and the paragraphs above into an amalgam of interpretation:

“Work in a fast-paced (high stress), positive attitude (you may not be able to question status quo practices) company with a really great brand (which is the best part of your reward for your work, our brand). We expect you to work in your role without expectation of promotion, but you can enjoy some extra time with your family. “

Sounds like I’m assuming a lot of negatives here but if we really boil down the expectations here combined with what the social networks are saying in reviews, this isn’t a great start.

Stay tuned – we’re going to rewrite this to do better at the end.

What I see when I read a job posting (Part 1)

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

LinkedIn has continued to send me job alerts. Constantly. Looking at job postings has always been a mixture of emotions for me, ranging from curiosity to repulsion. Something struck me the other day while looking at these job postings and it made me wonder:

Are we critically missing the mark when it comes to job postings in the technology industry?

So over the next several posts, I’m going to take a job posting that LinkedIn sent me and comment on its parts. At the end of the series, I’m going to rewrite it.

Note: Some parts will be obfuscated to remove specifics that identify the company.

Location: {Removed. A suburb of a big city.}
Senior C# .Net Back-End Services Developer
Do you want a fast-paced and exciting work environment? Grab a coffee, let’s chat.

So we’re three lines in. Location is becoming less important than timezone as we shift to the realities of remote work, but some people do still want to go into the office. No worries here. The third line is where we already run into some trouble. I’ve seen “fast-paced and exciting” on almost every single job posting and I don’t think we convey what we mean anymore by putting that on here.

Do I want to work somewhere fast-paced? Not if that means frantic. I want to work with a company that has a sustainable pace that is productive and not busy.

If things are exciting it can be good, bad, or both

Excitement means a peak of emotional and physical demands, and it’s not sustainable. You can’t be fast-paced and excited all the time and expect to be productive. Busy, maybe. But not productive.

Let’s take a lesson in how demolition teams approach a job

Several years ago I was working at an office complex that was removing shale with demolition charges and the demolition team was on break. I stopped to chat on my way walking back from lunch and remarked that they must have an “exciting” job. I mean, they get to blow stuff up for a living, right?!

“No way!” they said. “When we set this off it should be pretty underwhelming. If it’s exciting, RUN!”

The philosophy of a demolition team should be applied to our office environment.

“But they work with explosives!” you might say. Yes, and they can hurt someone if things get “exciting”. Likely a bunch of rocks go flying into a car parking lot and a lot of windshields have to be replaced. The rear window of my mother’s station wagon was taken out because of this. Hundreds of car windows were smashed. It was really bad!

Do you know what’s also bad?

A security breach with millions of credit cards exposed due to someone missing something because they had been going full-out for a year in a “fast-paced and exciting environment”. They’re burnt out. In fact, that does more financial damage than taking out hundreds of car windows with a demolition charge gone awry.

For those curious

the demolition team let us watch the explosion from a safe distance. The entire area being blasted was covered in a giant blanket made from old car tires. You felt the explosion in your feet, and the blanket had a wave ripple through it. A little dust was raised up. That was it. It wasn’t even that loud.

There’s a lesson here

If your work environment is constantly fast-paced and exciting, then it’s probably scrambling because something is wrong. Work should be productive and fulfilling. That fulfillment is what will excite me.

But exciting because of deadlines and heroics to make those deadlines?

No. That’s just exhausting.

2020 is exhausting enough, thank you.

Photo Credit: Photo by Markus Winkler on Unsplash

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

A visual aid to Lead Time and Cycle Time

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

I’ve noticed that there is a lot of confusion in our industry on the subject of Cycle Time and Lead Time, so I made a visual diagram that should help clarify things a bit.

Both of these times are lagging indicator metrics that measure how long it takes for a feature to go from one part of a value stream to the other. Here’s the basic break down of the two:

Lead Time: The time from when a customer asks for a feature to the time a customer receives that feature in production.

Cycle Time: The time from when the development team/makers start work to when they finish that work.

The Visual:

Note: You may have non-development activities that occur after development is complete, and this is part of lead time but not cycle time. An example of this: Organizational Change Management activities that are happening after development.

Why is this important?

A perfect scrum team doing 2-week iterations will start work and then finish it in 2 weeks’ time. So, a perfect scrum team’s Cycle time is two weeks. But… when did the customer ask for that feature? When did they actually get it? Did we release the feature the same day we finished it? Or did it wait for a release, or the end of the Product Increment (PI in SAFe land)?

The lead time might be a lot longer than two weeks. And it doesn’t matter how fast your cycle time is if the lead time is still too slow. That’s why knowing and tracking both numbers is critical to help inform your team’s continuous improvement efforts.

Post in the comments below – do you know what your lead time is from your customer’s perspective?

A Tool for Cross Functional Teams

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

In this post, I’m going to review an equation that helps you evaluate how cross-functional your team is. It also is good for identifying the constraining skill for your team members. This helps the team pick what training it should focus on, and gives an awareness of where it may be having constraints in its flow.

I have a spreadsheet linked at the end that will help you with the calculations.

One of the Extreme Programming tactics that are commonly encouraged in teams that are working towards incremental development is swarming. Swarming is where instead of pulling in multiple stories/work items individually, the entire team works on a single story.

There are a few reasons why a team may have trouble doing this.

One of them that we are going to focus on specifically today is the team’s cross-functional skills, or T-shaped skills.

Ideally, your team is made up of T-Shaped skills – meaning that everyone has deep expertise in one skill, but is competent in at least one other skill that another team member is an expert in.

Thankfully there is a simple math equation that can point out the skill constraints on the team:

C% = Sum(Ms) / S * M

C% = Cross functionality %

Sum(Ms) = Sum of number of skills that members have

S = Number of skills

M = Number of team members

Cross – functionality (C%) is defined by counting the number of skills each team member has (Ms), divided by the number of skills (S) multiplied by the total number of team members (M).

A cross functionality score of 100% means everyone has every skill. You can readily swarm and employ swarming easily.

50% means half the team has half the skills. You can’t swarm easily, and XP principles are difficult to employ. In addition, vacations or other availability issues easily block the team.

Let’s make this easier.

Let’s look at a small web application team as an example. They use MongoDB for the database, Nodejs and ExpressJS for the backend, NodeJS and ReactJS for the web front end, and they use Docker and Kubernetes for their deployment infrastructure. There is a user experience designer on the team, and for this example we’ll say they have the wireframing skill in Adobe XD. That’s 7 skills total to deliver something fully functional to the customer each increment.

Let’s say your team has seven people on it. They are:

John, a web developer with 2 skills: ReactJS and NodeJS.
Jane, a developer with 3 skills: NodeJS, ExpressJS, and ReactJS.
Bob, a developer with 4 skills: NodeJS, ExpressJS, Kubernetes, and Docker.
Sarah, a User Experience Design expert with 1 skill – Wireframing in AdobeXD.
Jill, a senior developer with 5 skills: NodeJS, ReactJS, Kubernetes, Docker, and MongoDB.
Liam, a developer with 3 skills: NodeJS, ReactJS, and Kubernetes.
Kate, a database specialist with 3 skills: Kubernetes, Docker, and MongoDB.

So to figure out the cross-functionality of the team:

Let’s first calculate the total number of skills possible. That’s 7 team members and 7 skills. 7 X 7 = 49.
Sum the current team member’s skills: 2+3+4+1+5+3+3 = 21.
Calculate the Cross functionality percentage: 21 / 49 = 0.42 or 42%.

The final result is a Cross-Functionality Score of 42%.

What this means is that your team can’t swarm very well. Less than half of your team has any half of the skills needed to deliver an increment.

What’s the constraint? Adobe XD, with one single expert. (This is a Brent from The Phoenix Project if you’ve read that book). Now, in order to alleviate this constraint, your team should start learning from Sarah, and Sarah can perhaps pick up ReactJS skills.

Remember, we’re not rating people on expertise, just possession of enough skill to deliver the next increment.

Use this worksheet to make it even easier

If your mind went to a spreadsheet right away, with a matrix that lets you build your team members and skills, then let me give you a head start. Here’s a Google Sheet that has this example pre-populated:

The spreadsheet contains the formulas that identify the most constrained and least constrained skill.

Make a copy, and try making one out for your team.

I hope this helps you help your team become more cross-functional!

Photo by Josh Calabrese on Unsplash

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

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?