Month: July 2020

A Tool for Cross Functional Teams

A Tool for Cross Functional Teams

Posted on 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:

  1. Let’s first calculate the total number of skills possible. That’s 7 team members and 7 skills. 7 X 7 = 49. 
  2. Sum the current team member’s skills: 2+3+4+1+5+3+3 = 21.
  3. 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

Save your budget and hire the right coach

Posted on 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.

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

Posted on 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

Automation isn’t just for developers

Posted on 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.