FleXP: A People-Centric Approach to Software Development

(00:09:35.03)

Gretchen:
Alright, so casting your stars, this is our first section, you can't put on a great show if you don't have great performers. These days, we all know that good talent really can be hard to find Jeffrey, you had some great statistics around that.

Jeffrey:
Yeah, so one of the things that I've been doing is looking at where the reality is with respect to demand for developers here in the US, these numbers are always taken from a couple different sources, from the Bureau of Labor Statistics, as well as the National Science Foundation, and there's a couple things that I would point out. So the blue line here is the good news, it is the number of net new Bachelor's of Computer Science and Engineering from 2009 until 2017, the last time that the data is available for. So the good news is, we're almost doubling in 2017, the number of new comp sci graduates produced compared to where we were in 2009, so there is net new talent coming into the field. The challenge however, though, is if you look at the the teal line here, that is the net increase in software development jobs in the US year over year, so in years where the teal line is above the blue line, that's where the number of net new jobs was even more than the supply that we're getting. Now, you might look at that and say, well, it means we're getting more graduates than we are new job growth, so what's going on here? This doesn't take into account the number of folks that are retiring, and we know the baby boomers are starting to retire and they're leaving. It doesn't take into account the developers that stop writing code because they become a development manager, or they may become an architect, and they're not writing code on a daily basis, and so basically, you look at this data and say, we are barely keeping up with the increase in overall demand, let alone the replacement of developers in the US, and as a result, what you see with the purple line, there is a steady arch upward in the mean salary for software developers. We're now making just a little bit over $104,000 a year, so if you write code, it's a good story, but if you're trying to find the talent to deliver the software that is important to you, it's getting harder and harder.

Gretchen:
Absolutely, we're seeing the same sort of thing at Solstice, we've done a little bit of research ourselves, 86% of hiring managers are saying that it's challenging to hire software engineers. That's that's no surprise to anybody, we had a little survey with Career Builder. It looks like in Chicago alone, there are four Java programmer jobs for every three qualified applicants, and let me tell you the talent acquisitions team at Solstice Kin + Carta is feeling this pain too, we are seeing these trends play out right on the ground here, and not to toot our own horn, but we are a consulting firm that's located in Chicago's loop right across from Ogilvie. We have a wonderful culture and we're pretty attractive for younger talent, but at this point, we've got it compared to 2017, we had 56% of folks actually coming to us, so they were applying through various means, the website or a recruiting jam. Now in 2020, 19% of folks are applying, and we are having to source 54%, over half of our folks, we have to source them, we have to go out and beat the bushes and try to find leads for good talent, so we're spending more money, we're working hard just to get that right talent in the door, you have some suggestions for how we can do a better job at this, Jeffrey.

Jeffrey:
Yeah, so so when I talk to clients all the time about the developer gap, as we call it, and they ask, well, what do we do about this, what are our options. We tell them that there are five; three which are pretty obvious, we've had for a while, and two that are maybe emerging and may be a little bit less obvious. So the first three, hire whoever you can and industrialize delivery, and that's the software factory model, I personally call it the test, so you put a mirror in front of them and if they fog it, then you hire them and that can work. You know that challenge with that, is that you get a wide variation in the skill set that the folks that you hire have, and you have to put in place processes and delivery models that can deal with that wide variation in skills. The second option is to hire the above average talent and then get out of their way, you know, that's what I actually think is more like the Broadway production because you're hiring people in, essentially expecting them to be able to pick up the dance moves quickly, to be able to expect them to sing on key to be able to expect them to read music to hit the ground running. The third thing you can do is you can hire digital agencies or systems integrators.

Over the years, one of the things that we've seen is developers tend to migrate to firms that make their business out of creating and delivering good software. I mean, Solstice as an example of a company that, you know, if you don't have great developers, it's hard to create a sustainable business, and keep the client list that you have. Now, the other two are more interesting, and I think in some ways, they are a reflection of the fact that we have a developer gap in the space. It's hard to hear it as a developer, but maybe one of the ways that we deal with this is we write less code, we sing fewer songs, we put on fewer plays, and one of the ways we do that is by doing things like adopting platforms and packages. When you think about something like Amazon, let's take Amazon lambda, as an example, one of the things that lambdas lets me do is write less code, write less infrastructure code, so I can focus on the code that matters from a business perspective. One that's related to that, then, is this move that we see toward low code tools, and I know as a professional developer, it's easy to say low code. Those are tools for you know, folks that are not like me, but you know what, there's a lot of business folks out there that are so desperate to be able to deliver the software that matters to them that they are going out, and they're building these solutions, and they are putting them into production. My peer John Rhymer has written extensively about that, and it is a legitimate way to deal with the shortage of developers that organizations need, but across all those strategies, what we're going to spend the rest of the day talking about is the one that I like the most, which is strategy number two: finding above average developers and getting out of their way.

(00:16:25.02)

Why do I like that strategy? Well, if you take the main alternative that I see folks do, which is the hot test, the problem that happens with that is as you scale up, you try to scale Agile and you bring in more and more teams and the experience of developer that the developers have vary complexity, inevitably rises. The complexity of delivering a software project across six individual Agile teams is significantly more difficult than one team of seven and so what tends to happen is the average skill level of the developers that you are trying to enable, as you scale those Agile processes, begins to decline, the number of developers that have up to date skills that know how to use Cloud Foundry or have experience with lambdas, or know how to provision a Kubernetes cluster also goes way down, and so the net result of that complexity is the need to put processes that act as guardrails around them to compensate for the lack of skills, and that leads to a set of dysfunctions that creep into an organization that can have a real impact on keeping that top talent. If you want to commit to that strategy number two, we've done some research on this at Forrester, there's a piece I wrote a couple years ago, it's called The Social Future of Software Development, and it looked at the practices that leading ISV enterprises were putting into place to try to find those developers. We're more than just the developers that were the classically trained or the ones that were truly inspired, what we found was that, you know, it kind of starts with the idea of pain above the market average in whatever market you are. If you're not prepared to do that, then you need to consider one of the other five strategies.

Now, not saying top of market, I'm saying above the market average, because once you get above the market average, there are other factors that clicked in. It's important to connect to the communities that developers work and live in transportation is an important issue. Having a location that's downtown, not being in a cube farm in the suburbs, are something that millennial developers are really interested in right now. Committing to diversity in your development shop, if you've noticed, over the years, a number of the large software delivery organizations have begun to report their statistics on diversity and the reason that they're doing that it's because it's important to them and because it's important to the developers that they hire, and it's something that should be important to you. We've seen a lot of organizations get very creative by generating their own pipeline with internships, you know, I have a son who's now productive, and you know, he started his first 4k software job when he was a junior in high school, and he did six years of interning at companies and basically, was able to get to the place where he wanted to be. Along the way, a lot of those companies where we're working to create that level of talent, and hiring those interns, wherever they can, it's something that we've written about, how to run a great internship program, finding developers that other companies miss. This is an example of where a low code strategy can help out because you can create some of your own development talent internally from the business experts, or you can go to the code schools that are out there and hire development right out of those alternative educational pipelines.

The last thing that we see organizations doing is exploiting their development culture, being proud of the shop that they have created and using that as a recruiting tactic. You know, I first saw that one started to solidify and see the financial industry showing up at conferences like Eclipse Khan or reinvent or were next, and if you're not getting out there marketing, the kind of organization that you're creating, you're going to have a hard time getting the interest from these from these top tier performers.

Gretchen:
Absolutely, I feel like one of the key things that we do right at Solstice Kin + Carta is the culture piece, really understanding what it is that engineers need to feel satisfied at work, and one of those things that we've learned is process, so how are we asking them to work together, what's our way of working, if you want those Juilliard trained performers on your stage?

Jeffrey:
Want to think about it this way: when it comes to process and a Broadway show, the stage crew is every bit as critical as the lead, if the stage crew isn't hitting its marks and everything isn't, you know, set the way that it should be, Spider Man falls, you get injured, so you've got to have both. So when you think about process, and you think about scaling Agile in particular, the question is, how can we scale these processes in a way that they enable creative workers?

Gretchen:
Absolutely, you have a great comparison here for yeah, mental models for this tech.

(00:21:24.06)

Jeffrey:
And I just cringe when somebody comes to me and they say that we want to create a software factory, or what process should we select to scale our Agile processes? Because a lot of times, I feel like they've fallen into the trap of how do we build the most efficient factory possible, and I can tell you, as a former developer, and somebody who's been in the space for years, if somebody tells me, hey, we'd like you to come work in our software factory, I can't think of any place else that I would, I would rather enjoy working in less than a factory, I don't want to be in a factory, I want to be in a place where I can use my creative talents to do things that matter. The reality is that most software is not something that you are creating a million times, it might be something that you're shipping a million times, but you're not creating it a million times. Every application has a certain amount of uniqueness to it, in my opinion, it's more like a painting. And so I think that software development is not at its core algorithmic, although there are algorithmic processes that support it, it is heuristic, and so I think we need to think about managing it with respect to heuristic processes, so the reason I use that Broadway production metaphor and you can choose other things, how did Motown town create the wall of sound and manage all of those performers? How does Spielberg put together a production crew and create so many great movies and why do the same people keep showing up? There are processes that are used to manage creative endeavors, but they are different from the processes that are used to manage algorithmic endeavors. And so when you think about how you scale Agile, in my opinion, that is at the core of choosing to execute strategy number two, from your talent perspective, as opposed to strategy number one, if you accept that software development is your risk stick, then you say what are the management models and the process models that we can put in place to support heuristic work, enable it, and where appropriate, provide the safety harness that keeps Spider Man from falling.

Gretchen:
Yeah, absolutely, I love what you shared earlier, when we were talking, you said that the main minor for almost all comp sci majors was something creative, or Gmail, and in particular, if you're not familiar, email is one of the top five comp sci programs perennially in the US and they're the number one minor at CMU., You got all these injuries, and then you got folks that are taking on piano or whatever, and I think part of that is because of the creative nature of developers, and it's how we tend to express our creativity in text, as well as another look in other manners.

(00:24:19.04)

Jeffrey:
We're going to go through a couple of ideas for ways that you can start creating the culture, creating the environment that engineers want to work in. Number one, is modernizing your technology, this is where I see scaling hit a wall, a lot of times, by the way, when I'm working with companies that are trying to create some sort of scaled Agile process, you can't get done at the end of a sprint or an iteration, if you don't have a CI CD. If you don't have automated tests, there's no way to create shippable code within iteration without some sort of modernization, and also your stars don't want to work on this monolithic code base of technical debt, they want to work on the new stuff on the cool stuff, they want to deliver quickly to production so they can see the results of their work very quickly. I have a little metaphor that I like to use here, this is the Winchester mansion in San Jose, California. This was built by Sarah Winchester who is the widow and heir to the Winchester rifle foundation. When she started building this house, she was guided by good spirits that she spoke with through a medium and she didn't engage an architect, she didn't have any blueprints. Carpenters just worked and worked and worked, and at the end of the day, she had staircases that went to nowhere, secret passages that only a few people knew about, stained glass windows got installed against these interior walls, it was a mess, and it's actually been used as the setting for a couple of horror movies. You may be wondering what that has to do with modernization. Actually, one of our clients used the Winchester mansion to describe their infrastructure and their systems, it's just a mess of old fragile systems layered over with veneers and veneers of services, there's not a lot of architectural planning. It's like having to wander around in a haunted house trying to create some code, so that not only limits the amount of code that you can get to production in a reasonable amount of time, but it really turns away some of your best workers. What they want to work on is the newer stuff, they don't want to stay up until two o'clock in the morning, doing an install, they don't want to go on week long bug hunts. But the fact is that the average age of your COBOL program programmers is 60, so there's this urgency right now to modernize the systems before the workforce that created the last generation retires, so we are seeing modernization really come up as a big trend for attracting high performance employees.

(00:27:09.02)
 
Gretchen:
Yeah, I think part of what's going on there is the desire for what I call shared purpose. Most developers look back and are able to point to things that they have done that have mattered. I'll never forget the time that I got a copy of the first shrink wrap box that my team put together for the dev tools that we were selling, I still have a couple of those shrink wrap boxes somewhere in my basement. Being able to point to that and say, our team built this, was cool, because it was something tangible that we had created the same way that you know, performers seee their music on Spotify, and and they say, Wow, hey, people are streaming my music, this is awesome. And, you know, It reminds me of a commercial that Microsoft planned years and years ago and you know, this developer, this architect, walks into a meeting and they were like, what's the problem, is the datacenter down? Or is the code not working, and it's like, no, everything's working fine. Well, then why are we here, we make shirts, that's what we do, that's our business, and it was about okay, now that everything's working, how can we get even more effective at making shirts, and that's the kind of shared purpose that I find a lot of devs are interested in. They're interested in doing things that make a difference that they can point to and that they can be proud of, and again, that's an example of a heuristic profession. Absolutely, you don't want to wait six months to get something visible in production, getting customer feedback, where you can get Amazon drones delivering something to your door in two hours, so yeah, maybe if I'm lucky, my code will see the light of day sometime.

Jeffrey:
I'll be working on something else by then, so yeah, so the next section that we want to talk about was your way of working, so this is your methodology, how you're asking teams to work to attract the next great talent, and we're going to talk a little bit about a few delivery frameworks, and you have some great data on.

Gretchen:
Yeah, every year, we run a survey where we talk to developers and development managers and VPs, and that sort of thing, and we asked them a bunch of different questions, and one of the questions that we asked them is basically, are you doing Agile, and the answer is yes, a lot of organizations are doing it now. We asked them, “Well, okay, what kind of process are you using?” SCRUM is the number one most frequent response at 24% with extreme programming not too far behind. For those that are doing Agile methods, you still have a bunch of folks out there using the MSF for Agile Microsoft's framework, and then you've got an increasing number of organizations that are adopting safe to scale. Disciplined Agile is out there, nexus from the from SCRUM.org is also out there, and then you've got that that group down at the bottom, the 4% that are some of my favorites that are that are adopting the Spotify style model, and it's something that we've been reading a little bit more at Forrester because of the particular focus on culture and organization that Spotify style models tend to have that we think is helpful. So for those folks who are on the phone right now who are maybe doing waterfall, I'm going to say something a little controversial. There's nothing wrong if waterfall works great for if you have a very simple, very repeatable processes. It's kind of like assembling IKEA furniture, it can be a little tricky, but if you have a mass produced, easy to assemble solution, and you can follow that plan, you're fine. The problem that you run into is change. What if you didn't measure perfectly? What if you forgot to pick up the second box, what if something changed or you have a little room for error, you have to drive all the way back to IKEA. You have to lose another chunk of your weekend, so we're now entering that change order scope creep nightmare, I think we have a nice little framework.

(00:31:02.09)

Jeffrey:
Yeah, you know what Gretchen, I actually agree with you. I am not antipathetic toward Waterfall at all. And I think this is one of the biggest issues that the the strategy number one, the, let's put a process around our developers people do because they try to say, Okay, what is the one process that we can put around all of our projects, or products if they're a little bit more advanced, that that will work no matter the case. I just don't see that as a realistic way to deliver software because we have all sorts of problem domains that we are trying to to solve for when it comes to software development, and it's one of the reasons why I've really become a fan of the ken affine model for thinking about problem domains. If you're not familiar with it, it comes out of the UK, and it articulates the idea that there are four different types of problems that are simple problems, complicated problems, complex problems, and chaotic problems.

Waterfall is actually a pretty reasonable software delivery style, when you have either simple or complicated problems where you know what you have to do, you can establish it, you can use things like checklists as an example, and you can go and execute and get to the end in a fairly straightforward way, so even when you get to some complicated products, complicated problems, that sort of single pass through one time process where you have the the risk, well quantified in the best practices are well established, and can work, but what often happens for us as software developers, especially when we're working with new technologies, or trying to solve new business problems, for the first time, we spend our life on the left hand side dealing with the complex and the chaotic, and to solve complex problems, I don't think there's anything better than methodology, that gives you a probe sense and respond way of working, and fundamentally, most Agile methods come down to enabling probe sense and respond, style thinking. Assuming that you actually sense which we'll talk about when we get to measure. Just probing isn't necessarily going to help you get to the point where you understand the problem. Chaotic domains are even more interesting, because when you probe you, you may not get the same response, even though you probe the same way, and so basically, what you tend to see is that over time, individual domains move from chaotic or complex to complicated, and then maybe eventually simple, and so over time, as a system ages, it may make sense to use a different type of process approach because you now know what the best practices are, the rates of change are going down, you have a firm handle on what your customers want, and so when you're thinking about putting in place, processes, it's actually multiple processes, and the wisdom to know which one is going to work best because you're able to recognize the type of problem that you are trying to solve. So, as a result, what I would encourage you to do is to think about a practice based approach to enabling your teams and adopting the practices that you can measure to know whether or not they are the right practices to apply, so that you can pick from the different methodologies that are out there and take the valuable pieces and make them your own. Absolutely, and if we look at SCRUM in that light, we we see so many companies that go and adopt SCRUM and think that that's the silver bullet, that's the golden ticket, but instead of actual change, they end up with just a kind of an Agile word salad, so you have status reports that are nowadays Stand up, so you have a requirements document that becomes a backlog, managers just become release train engineers and the process is running show they haven't really gotten that spirit of individuals and interactions over processes and tools. We know that Agile is still better for most software projects. 85% of SCRUM team members say that SCRUM has improved their work life balance, but there's still that something missing, and typically, we found what's missing in a lot of processes out there is that focus on the engineering side, continuous integration, delivery, deployment, pair programming, TDD all of these practices, these technical practices that come from extreme programming and bring with it that promise of high quality code delivered with lightning speed. I think you also have a little bit more.

Gretchen:
I love this data, because it's really consistent with the data that we get from our depth surveys. Even though we will have our respondents say 75% of them will say, yes, we are an Agile shop, I always dig underneath that because it's like saying, yeah, I'm in great shape because I go to the gym. Well, okay, how many reps did you do, what machines did you use, how long did you run, you have to dig in and say, okay, well, what are you actually doing? And when we do that, what we find is that 75% of respondents that say, we are an Agile shop, are actually not doing a lot of the practices that I think really have proven to provide a lot of value over time. For example, only 31% say that they're doing continuous integration, only 25% for doing automated builds only 24% of using short development iterations of less than four weeks, only 20% are doing pair programming, only 21% are running retrospectives. Well, you know, if you're not actually doing the practices, just saying that you've got the methodology or that we are in a SCRUM shop or that we're an XP shop or that we're a safe shop doesn't mean anything. So I think the reality in terms of where teams are with respect to their Agile discipline is pretty different from what they tell us, they are at the top line.

Jeffrey:
Absolutely, and you know, even when they do adopt those practices, sometimes there's this all or nothing mentality. We've seen this, when our team started adopting traditional XP, when we got into the modernization space, we have embraced this idea of extreme programming, and for the teams that were working on some of the most strict Extreme Programming engagements, we saw team morale drop, immediately, we saw some brain drain attrition from some of our top performers leaving the company and on the teams that were the most inflexible, we saw NPS actually drop to zero.

Gretchen:
On CMPS?

Jeffrey:
This is the employee and NPS report, yeah.

Gretchen:
Thank you, there we go, so we dug into that a little bit with our team. And we got some feedback, some really strong feedback from them, so some of our teams were pairing six to eight hours a day on everything they did, including documentation and research, I mean, Jeffrey, can you imagine writing every email or slack message with me looking over your shoulder, oh, and when you get up to take a bathroom break, I have to stop work until you get back, I would not last long, I like you a lot. But I would not last long.

(00:38:37.06)

Jeffrey:
Yeah, yeah, and this is what happens when people fall into the trap of process over people, okay, and process over practice because the process becomes the thing that you must have full fidelity on no exceptions. And if an organization is not measuring as the result, it's really easy to lose sight of exactly, what you are trying to do, by scaling Agile, it's like saying that every single actor that we hire also has to have a pitch perfect voice that is a tenor, you know, that's not the way people are made, you know, some people sing bass, other people can't sing at all, but they're really great actors, so you take your talent and you adapt your processes to support that talent as best as you possibly can.

The other thing that we saw when we looked when we asked our engineers was they, because they were in this very rigid style of working, they didn't feel freedom to explore, you know that, when you get in the zone. flow, the time is just flying by you're doing something creative that you love that Tony immerses you, that's what's rewarding for creative people, that's what they need to feel fulfilled in their professions and the process had taken that away.

Gretchen:
So the gong just went off, it's time to go to our stand ups.

Jeffrey:
Exactly, and I'm working in this big open office environment, I never have any privacy unless I put in my headphones and then I'm still surrounded by a lot of visual stimulus, right? Impossible to sustain that below.

Gretchen:
You know what you the the the image that headphones I get is morning calisthenics at the factory, yeah, no, it's like, you know what I might want to work out, but I might want to do before I come to the office where I might want to do it at the end of the day, so let me work out the way that I want to work out, and it is an example of getting caught in the process trap of industrialization.

Jeffrey:
Exactly, so we decided we were going to try to fix it for our teams, and we came up with a new way of working that we're calling FleXP, we're calling it a people centric approach to software delivery. So the basic framework is SCRUM married with XP this is nothing new people do this all the time, the functional framework of SCRUM and the technical practices of XP but the heart and soul of FleXP is really about flexibility, so it's looking good on that dogma of process that rigid implementation and focusing on the people and the principles behind the process,

Gretchen:
It's the first part of the Agile Manifesto, people over process, right?

(00:41:14.00)
 
Jeffrey:
Give teams autonomy to define what works for them, and then get out of the way, because you're gonna see an amazing result from that, so let's look at how that gets applied to pair programming. We talked about this a minute ago, but I'll tell you bad pairing experiences have gotten so pervasive that some very creative folks out there on YouTube actually created a little rap about it, so let's go ahead and get that. So we did get good feedback, and we decided to create a few principles around FleXP so what does XP mean, and pair programming. It means the team determines what stories are good candidates for solo work, there's no requirement that everything has to be a pair program, you're hiring smart people, don't tell them what to do, ask them what they need. So number two is don't ring the gong, allow time for life to occur during the work day, let the individual pairs negotiate their own schedule of work and lunch breaks for when they are pairing. And then number three is when you're pairing, actually really pair. A lot of times when people are mandated to pair for everything, you see people zoning out. checking their phones or doing, you know, some research while their parents are actually writing code, and that's because they're not bought in. They haven't actually agreed that this code is worthwhile pairing on, so really pair. Maybe going down into the details a little bit here in the weeds. Remember these are not rules, they are examples This is one team's agreements on things that they decided were valuable to pair on, when the team is forming when they're onboarding when we're introducing or ramping up new team members. When we're working on complex stuff, or critical path stuff, foundational patterns, implementing a new technology, all of that were opportunities for pair programming, and then working solo made sense for things like spikes, research, configuration changes, defect triage, things that were more simple that were more wrote that you didn't need two sets of eyes on, so remember, everything still goes through code review, everything still gets multiple sets of eyes on it, just not over the shoulder sets of eyes.

I think the important thing here is related to some research that I did almost 10 years ago and best practices of high performance development teams. There were three things that we saw that those teams tended to exhibit in the first one was a high degree of autonomy, this is an example here of where the team themselves has the autonomy to decide how something like pairing a practice, like pairing is going to work for them. Now, when you couple that together with measurement to make sure that you're actually delivering value, you've got a feedback loop that that team can use to decide how to tune the actual things that they are doing to make themselves the most effective, and that's the difference between a people in practice focused approach and a process focused approach.

Gretchen:
So colocation is another thing that we wanted to look out for when we were creating FleXP relationships, so important.

We've got that Agile principle about the efficiency of face to face conversation, building those relationships, you know, going out to have adult beverages together, that's where a team becomes an ensemble, and it's incredibly important for us to be able to have that face time to create those relationships, but we also know that a third of developers would quit their jobs for remote work opportunity. And we knew from our employee feedback that the travel was getting to be pretty draining from team members, I love the research that you all did on this one.

Jeffrey:
Yeah, I mean, the reality is colocation is increasingly a luxury, for most development teams, only one out of four have the luxury of having all their team members in a single location, so whether it's one developer or two, which can actually be worse than the entire team being remote. It's a fact of the way that we work now, we've got to have processes that support creative workers that don't happen to be physically co located with the team.

Gretchen:
Absolutely, we and we have today things like Zoom that you're on right now or WebEx or, you know, Slack.

Jeffrey:
Gretchen, I think it's fair to say that even though we're seven 800 miles apart today for this hour, we are spiritually co located right now, in addition to being temporarily co located, it's an example of what the technology can do.

(00:46:30.09)

Jeffrey:
So we looked at this and we said, okay, how do we balance these two extremes, right, we want to create these relationships, so we came up with a timeline, remember, please, this is not prescriptive, this is our example of how we made this work. So we said, okay, really valuable for us to collect locale as we're forming and to do more pair programming as reforming because, frankly, there are not a whole lot of experienced pair programmers out there in the world. So pairing up the senior folks with folks that are still learning and really helping to quickly level up those skills was very valuable. The first 60 to 90 days we're doing a lot of immersion colocation, pair programming, baseline metrics, leveling up skills, but then after that, 90 to 150 days, we're starting to now transition, we're adding in solo work, we're beginning to work from a preferred location I like. I like that term rather than remote work. You're working from your preferred location that might be the office, and then as you really mature, you're working from the preferred location, the majority of them being together for those key ceremonies, those key demos, planning, whiteboarding sessions and your pairing are so loading totally at the end, the autonomy of the team, so this is how we made it work for us.

Gretchen:
Alright, we are gonna head into our homestretch here, you might be wondering if you're giving the teams all this autonomy, all this flexibility, how do I know as their leader, how they're doing, when they need help, when they're a mature team? Well, we have a little cartoon for you that Jeffrey found.

Jeffrey:
Yeah, and the answer is sense and respond, and it comes down to measurement. Now the problem that I see with most of the enterprises that I deal with, is that we measure the things that are easy to measure. We're like the drunk that's lost their keys. We look at it under the light because that's where the light is, even if that's not the right place that we should be measuring. So one of the things to make strategy number two work is you have to commit to measuring the things that actually matter even though that may be hard to do.

Gretchen:
Absolutely, and we have how your peers are measuring software success, yeah. So you know, there's some good news and bad news here, the good news is people are measuring different types of things that are important pieces of data. They're kind of four domains that we recommend that folks look at. business value to me is the most important one, because if you're not creating business value, then why are you getting paid, okay, so you've got to find some way to tie back to business value. But then in terms of the things that we measure from a development effectiveness perspective, things like how efficient we are with the time that we have and the resources we're given, how much progress we're making, and what the overall quality of what we're doing becomes important, so regardless of whether it's your defect density, as you see is the number one thing up here in terms of quality, or whether it's the number of feature stories or t shirt sizes or you know what you think your business folks think about the software you're delivering the important thing is to take a balanced approach, and start by asking the questions, what are the things that we need to measure because of our dysfunction, and what are the things that we need to measure because it's the behavior that we are trying to incent and the positive value that we want to drive, both of those are fundamentally important.

Jeffrey:
Absolutely, and pulling them all together, you need a good dashboard, if you can't see that data, you can't know what levers to pull to help your teams and the teams need to be able to see that data too, by the way, I'm not talking just to the leadership that's on the call, you need to have some sort of big visible charts or big visible dashboard available so that they can see this so that they feel bought into it too. We've found a few things that have been valuable to measure, the first one I want you to take away from this webinar, please go back and start measuring your team morale. If your morale starts to dip, that is a sign that your delivery is going to dip quickly after that. Your people are canaries in the coal mine for any trouble ahead. If morale is high, you've got a process that's working, that a product they're really proud of and excited about, but as soon as that morale starts to go down, there is definitely trouble ahead, you might need to go fight some giants in your organization. You might need to go talk with the PMO about being more flexible in process or business owners about understanding the value of investing in modernization, but if you listen to your team's morale, you will always understand what needs to change. We actually take a weekly survey of just a one to five rating with one question, what can we do to improve your morale? It gives us a really quick pulse on how folks are feeling.

Gretchen:
Almost have to have something like that to be a servant leader, right?

Jeffrey:
You do, yeah, you absolutely do, you mentioned this earlier to measuring points or velocity, I think there's so much value in that in terms of just planning just knowing how much we can get done in the next time box. But if you're looking at cycle time, that's what's telling you your speed to value. And I feel like a lot of folks are not measuring this and not really looking at start to finish, how long does it take for me to get a feature delivered into production, not just to build it right, not just to build it, we also need to measure how long does it take to define it and prioritize it design it all of the things that are involved because you never know at what point along the way you could run into bottlenecks blockers.

Gretchen:
So I actually like the second row metric here, is it getting better or worse? Yes, that's an awesome predictor of the things that we're trying, are they having any impact at all, are they having negative impact.

(00:52:53.04)

Jeffrey:
Exactly, you never know sometimes, you're doing things with the best of intentions but are actually creating blocks and slowing your team down. Quality, you call out quality for sure, one of the things in quality that folks are often not looking at is speed to fix, so when bugs show up in your production environment, how fast can you fix them? Is it minutes, because we're on a CI CD? Are we continuously deploying, or do you have to wait for another round of manual testing another release window? Or is it such a heavy lift to fix issues in production, that we have so much technical debt that you only fix critical and high defects, I know I'm talking to some of you out there, I feel your pain, but having those issues linger in production really weighs on that engineer's sense of craftsmanship, it lowers morale, it affects their sense of mastery and and that can chase some of your best people.

Gretchen:
Yeah, getting back to the Broadway metaphor, you always know the notes that you missed, even if it was a two hour performance.

Jeffrey:
Absolutely, absolutely. Finally, business success, so, you definitely caught this one out. I've seen so many business in it, or between the customer research team that's getting this rich valuable feedback and insight, but the team that's building the product never gets to hear it, so make sure your team hears those stories, make sure your team is is feeling motivated by that sense of purpose that hey, we're hearing back from our customers we understand that business KPIs that we are affecting

Gretchen:
Yes, and finally, remember that what you're looking at, what you're measuring, is what you get, what you nurture grows. We have this tendency as humans and as leaders to focus on what's not working. That's coming from a good place, we want to improve it. He missed a goal, what happened, how can I help, but if you spend all your attention and energy on what's not working, your teams are never going to feel like they're appreciated for all the great stuff that they do do. So take a ratio, take a five to one ratio of that you're appreciating their team versus focusing on the stuff that's not working, celebrate what is working, create that virtuous cycle that really forms that culture where your star for performers can shine?

Jeffrey:
I think it's one of the biggest differences between creative management and algorithmic management, algorithmic management, we focus on eliminating the defects, Six Sigma, in the creative world, you know, we look for the things that are truly unique and different, and even if it's not perfect, we still celebrate it anyway.