Navigating Agile Transformation: Empowering Teams for Success in a Rapidly Changing Landscape

hey welcome to naked agility I’m gonna be doing my episode 5 leading agile change webcast any questions you have please send them on to me I don’t promise I’ll answer them during this session because I’m going to be busy focusing on this but I have a Q&A session on Tuesday where I will answer any of those questions that I can I want to do a little call out to my professional agile leadership class that is running on Monday this is a virtual live virtual classroom we currently have six people and we’re going to be talking about the movement for management from that management traditional management style over to leadership and what that means today I’m going to talk about a few things in this leadership presentation so I want to talk about what the problem is and where it comes from I want to talk about that the who the what and the how and how we can organize some of those things and get them let’s get started

naked agility is available for DevOps and agile training and consulting contact us for a free consultation

okay so the first thing to talk about a little bit is um what the problem is and really it’s around that idea that things have changed and not just because of the current situation with kovat at 19 this is something that has been happening over the last 15 years the world has been changing very quickly and firms companies have been really struggling to keep up with that floor some of that floor has come from and that idea of the expectation from users if you’re in the commercial world of delivering value to them a little bit more quickly and some of that has come from those users then being in organizations and expecting more from their employer whether that be they want to bring their own device rather than use the corporate device so they want more freedom on the network more freedom to do things inside of the organization to have ideas and move forward that’s that’s really what that difference is companies today need to be able to take advantage of things that change in the market market opportunities or difficulties like the current situation and in months or weeks instead of years and I think that’s something that you’re seeing a lot of companies struggling with now that move to home working where maybe before they were we’re not going to do any sort of home working and then struggling to really get that in working times have changed effectively and they’ve changed very much in the last few weeks at so I’m going to talk more than from kovat perspective this is a presentation that I did at M agile in Africa in 2017 for my good friend Nana and I thought it would be a useful presentation in these in these dire circumstances that we’re in so I’m gonna be focusing on product and I’d like you to think about this let’s say we’ve got two two groups that are building a product one group a group a has a business plan they are well established in the market they’re well funded and they hire the best people okay that’s that’s one group the second group B people are going to be working for free we’re not gonna pay the people that are doing the work they’re gonna do it in their spare time for the goodness of their heart just because they want to so which of these do you think would be more likely to be successful

if you’re an additional mindset you’re gonna be gravitating very hard eh and but II was in fact a large product called in Carta Microsoft Encarta which some of you may remember um and Group B was Wikipedia and the thing that I find that kind of funny is the Wikipedia entry for Microsoft Encarta at Mike’s of Encarta was a digital multimedia encyclopedia they just couldn’t keep up with the change they deployed their application on a disk physical disk that was sent out to your many physical disks as it were and it was just impossible to keep up with the change in the world and Wikipedia and Wikipedia one because they had the most up-to-date data but people give up their time for free I’m wondering if you can think of any other companies that have really struggled and maybe completely gone out of business I was thinking maybe of Bob Buster that’s a very common one it was funny the blockbuster was represented in the and what was the the the movie the Captain Marvel movie you saw Helen didn’t have blockbuster at the start and that’s that’s it’s just it doesn’t exist anymore I think I seem to remember an article where the blockbuster CEO said he didn’t believe that anybody would want to stream movies and that was a couple of years before Netflix came on the scene I was also at Kodak for those that don’t know Kodak is still around and they aren’t doing really photography and stuff anymore they’re doing blockchain because if you can’t figure out what to do and you got to reinvent your business look Jane apparently but Kodak the Kodak invented the digital camera more than 50 years ago they decided that they would bury that technology in order to protect their film business which was the most profitable part of the business so they buried a new innovation but the problem is once something’s discovered it doesn’t go away somebody else is going to discover it again they’re going to go down the same routes and maybe come up with a better product if you don’t get to market with the ideas that you’ve got even if they’re going to disrupt your existing business then you you’re going to run into problems that annoying also really we have this challenge we have a number of a number of challenges that I’m going to talk about and in the what the WHO and the how but we have somebody with an idea who creates who creates an idea I’ve got something I want to go build something problem I want to go solve and we go off when we create a product and release it to customers and then the either like it or they hate it a good example of customers not liking the thing that was delivered was Windows 8 Windows 8 was released and people there was a massive expectations gap between the product and what people perceived that they wanted so max I’ve had to roll back a lot of the changes that they made in Windows 8 and in the UI in order to appease some very unhappy customers and to get higher levels of adoption and that’s unfortunate it was a good product it just had a mismatch between what people want eaten and what they got so they got a lot of negative feedback from customers but you might also get positive feedback so we have a number of variables they want to look at in the what WHO and the how and the first one until the cat is the the challenges in the what space

the idea that we have to decide what we’re going to build in detail up front is definitely an old tailor istic practice you should go read my are sorry watch my video on how to detect a duel and the tyranny of Taylorism but in the what challenges fifty sorry fifty sixty five percent of functionality that you build it will not be used by your customers this is data is based on a report from the Standish group in Boston they collect data on 70 odd thousand projects around the world and the the averages are 65% you might be better than that you might be a lot worse than that but that lack of focus on the the strategy of the product and is what’s causing that rather than building things that are strategically going to achieve pieces of value for your customers a lot of organizations are just building a bunch of stuff without really understanding that relationship between that because we’re used to those long detailed elaborate product backlogs where you you I go into organizations all the time and this I say can you show me your product backlog and they pop up in the product backlog and those 5,000 things in the product backlog there’s no way that a product owner that somebody’s setting strategy and direction can even remotely understand what’s in there which means they then have to have an army of minions to spelunk all of that data and figure out what might be important but those people looking at the the minions are going to be surfacing all the things they think is important which they might not have as much information and as the the product owner or as the the person who is setting that strategic goal so ultimately because we have these big backlogs or a lot of organizations have these big backlogs 35% of your requirements are going to change over the life of your project and that’s just reality 35% is going to change so if 65% is not used 35% is going to change that’s not a really good picture and some of that comes from not really having a good description or definition around the responsibilities of product management what are they actually supposed to do and also whether you have somebody who is has the role of product owner or you have that term in your organization or not you have people in your organization who are fully fiscally accountable for delivering value based on the money spent those folks I would call product owners and but often that accountability is delegated to people who are weak or not authorized to be able to make the decisions that they need to make in order to live for your organization to get a significant amount of value from that and ultimately we have this focus on project rather than product I’m not saying that you can’t have a project you absolutely can but the overall strategic focus should be on delivering value in a product projects are time limited very definition of project and if you are as an individual or accountable for delivering something in a time limited fashion you’re interested in getting that thing done but there might be choices that are made during the life of that project that are detrimental to the overall product and it’s very common for large projects that are going to result in an ongoing product or be added to an existing product to result in significant additional levels of technical debt and additional levels of complexity and really things that don’t need to be there part of that 65% of the functionality not used we delivered that functionality 65% of it wasn’t used so did we look back round figure out which 65% is not used and take those things out and leaving stuff in your product means you’ve got to support it maintain it it’s care and feeding you want to get them out if you can and that idea of those long long cycles many organizations still deliver less than once a year organizations can be 2 or 3 years between releases still for some large organizations but large products but many organizations are moving to quicker delivery quickly delivery does not necessarily mean once a quarter quicker delivery in the the agile space is 30 days or less you should be delivering your product into production at least every 30 days in order to solve some of those problems but that’s not common in the industry yet we’re going to talk about that so then we have some problems around who is doing the work or the the people problems who is going to be doing the work and so having an effective change transition management ie we’ve got a bunch of things we’re doing things change things are different than we expect how is that communicated across the organization how do you make sure that and when the the engineers are actually doing the work can they find out things are a little bit different than they expected to be that’s filtered back to through the layers that you’ve got in your organization to your customer

then and also the resultant information is then transitioned back the other way organizations on average lose 50% of their time for ineffective collaboration and basically the the handoffs being being very inefficient ineffective this idea of servant leadership and I think servant leadership is often misunderstood and it’s not about just getting getting the coffee or doing things for your team it’s about creating an environment within which your team can be as effective and efficient as possible

and that is often very lacking in organizations that’s why an effective servant leadership there might be servant leadership but is it actually effective and then having a misalignment of objectives are we going at all going in the same direction and are we focused on delivering the value that our customers need in our product in order to increase our market share in order to deliver that value and that will give us the thing we need and contributing to that 50% of an effective communication and is unimpaired scrum masters can they can’t they maybe know what they should be doing but they can’t do it those of the organizational bureaucracy that is there maybe they’re ineffective in the first place and a lot of complexity around who makes the decisions how those decisions are made how many stakeholders have their finger in the pie is that where to get things done so that’s a big who challenge losing 50% of our time for for that kind of collaboration problem

the other other big area is how I’m really the biggest issue in the whole world is this thing that we call technical debt technical debt isn’t always the best name to use it depends who you’re talking to and their understanding of the world and of finances I’ve worked with a number of CFO’s who have told me that technical debt it’s not the best thing you can call it because ultimately technical debt is not what sorry that is not all bad we have mortgages we have loans for cars you might take a loan out to get your sofa and paid off over a couple of years those are not necessarily bad debts however all technical debt is bad you’d be better at thinking of it as an unhedged fund for those that are technically monday minded you’ve got an uninsured risk effectively in your product you have risk in know no mitigation and this can technical debt can take lots of different forms and I usually sum it up by saying anything that is difficult or anything that is manual are all of that is technical debt but if you have any manual processes between your your software coder committing code to your repository to getting that item into production then you have technical debt that could be manual testing that could be manual environment provision provisioning manual deployments manual anything anything manual anything that’s difficult if you’re wondering why it takes so long for your engineers get things done when maybe when your product was was new and green it was very easy to get things done it’s because there hasn’t been enough care taken about how things are written how things look and how repeatable things are can I go back and edit and understand this part of the system easily have I made changes to the system to allow that to be easy easy easy to read easy to understand easy to change and the software will call that refactoring refactoring is something that should be going on all the time it should not be an optional thing that somebody decides to do or not it should just be how we work just like if you were going to release our press release you were going to some big announcement for your organization that was maybe a little bit controversial or could be a little bit controversial I’m are you just going to write those things down are you going to write that press release and Shepherd Act you just gonna email it to everybody I would hope not you’re probably going to reread that thing make some changes to make it make more sense you’re maybe going to loop in one of your colleagues and say is this on message is this the thing I’m trying to get across quit this be misunderstood and then you’re gonna go through some more iterations and then maybe you’ll look pen at somebody else in your organization look then somebody from marketing loop in somebody from engineering look and somebody from contracts from legal from sale all of those departments make sure it looks like it says exactly what we want as an organization to present and then we’ll release the press release so there was a lot of refactoring there going back over the things that we had done to make them make them better make them easier to read easier to understand same applies to everything we do

so we talked about a lot of problems and this results in a lot of loss so what what does that look like if you crunch the numbers a little bit

so I again I lasted this presentation in Ghana in Africa and I have Canadian cities as my currency there but you can think of any you can put any currency in in that space and the numbers meet the same so if I have 500 cities pounds dollars at whatever it is and I’m going to invest that in my product I’m gonna get my engineers to build something what does that what does that look like well if I lose thirty five percent for building the right features yeah so I sixty five percent of my features used little effort by my customers and then thirty five percent are the right features so we’ve spent a hundred and seventy five cities pounds dollars on delivering actual value if we lose fifty percent for effective communication and collaboration what does what does that look like well 50% of our 175 that we had at left is eighty seven and a half so we get eighty seven and a half pound cities or dollars and then we spend thirty percent of our time on average building new features there see struggling with technical debt so that’s the complexities of the thing that we’ve written the the difficulty in understanding the thing that we’ve written of the manual error-prone process is that we’ve got results and we are only able to spend about 30 percent of our time adding value to our product certainly percent every time cause just struggling with complexity that’s all we’re left with twenty six and a quarter but 26 and a quarter and out of our 500 so what does that look like on $50,000 that looks like two thousand six hundred and twenty-five dollars and I’m not sure that’s I’ve violated return on investment and anybody’s eyes hopefully in your business it’s not and this is why the business is concerned about the amount of value that they get for their investment in the software world and why the software world is often considered a cost center rather than a profit Center which it should be we need to address some of these things we need to change these numbers in our favor and that can be super difficult so I’ve got some suggestions that are pretty hopefully there they make sense for you the first suggestion is around or suggestions are around the what the value that we delivered the first one is to try and focus a little bit on product rather than project so while you can have a bunch of projects going on inside our product and make sure that decisions are made based on the outcomes and changes in behavior you want your customers to have rather than on delivering on a set of items delivering on a set of items does not necessarily provide value to your customer focus on the value and hopefully you can make some shift shift those percentages so we spend more time delivering the things that we really needed last time working on things that we our customers aren’t going to actually use

have a product owner have somebody with full fiscal accountability or delivering value in your product at the to be accountable for maximizing value there should be solely responsible for the backlog so don’t second-guess them you might not like some of the decisions that they make that’s sometimes just the way it is there they’re thinking about they’re taking a bunch of information in from market competitors what the board wants what stakeholders want they have a lot of information and they’re making a decision holistically for the best result in the product based on that so ultimately you can get an inadequate return on investment maybe you want to stop funding that project if you’re not getting the return on investment that you’re expecting maybe the pro toner needs more teams to work against the product you need a new product owner but they need to be empowered to make decisions about the product and nobody else should be able to tell the development team what to do effectively a product owner hires the development team the development team hires the scrum master and that’s that’s the the chain of hierarchy within the agile world and specifically in scrum now caveat everything I say with it has to work within the context of your organizational constraints you’re going to have you have a unique organization that you work in you’re going to have to decide how you want this to work depending on that organizational constraint might be some things you can’t change but maybe there are things that are inhibiting your team and your organization’s ability to adopt some of these practices and those are maybe things you want to address maybe you need to bring HR into a discussion around what what do we need to do differently maybe you want to bring sales and maybe you want to bring contracts in make sure everybody’s involved in looking the outcomes you’re trying to achieve so don’t think of agility as thing you’re trying to achieve this is you want to get specific strategic outcomes for your business and how are you going to work towards those strategic outcomes and maybe these tools are going to going to help you with that because ultimately we do still have to do planning and it it’s important for the business to understand where we are where we’re going how long we think we’re going to take to get there and that needs to be okay

those are answers that we need to be able to provide for the for the for the business its how business gets done so we have to be able to provide them but we want to change the way we look at those things this is from a complimentary practice from the way Microsoft is currently doing they’re at long-term vision and planning you can use bits of this you could use all of it you could use something else that’s okay this is just an example so here they’ve got three week Sprint’s this is for a particular team there’s your dev ops team like Microsoft they do three week Sprint’s and then they plan over three three Sprint’s so that’s nine weeks planning they understand more or less what it is they’re going to be doing over those nine weeks beyond that they’re not so sure but inside of those nine weeks they have a reasonable understanding and then they have this seasoned model so six months seasoned model you’ll hear Microsoft talking about the the fall and spring updates from any of their products that’s based on this seasoned model so they have a six month what are we trying to achieve in those six months and then they have a 12 to 18 month strategy here are the high level objectives that we’re trying to get to

then they’ll reassess those on a 12 to 18 month basis reassess the features they’re going to deliver towards those strategic objectives in a six month cycle Andrea saw assess the individual things they’re going to add to the product the implementation plan on that three Sprint’s three weeks basis so ultimately in their world the team is responsible for the detail so the the scrum team which includes the product owner for that for that team and are responsible for the Sprint the plan and a good way into the season what are we actually going to do what are we going to implement in the product and what are the the things we’re going to go build but leadership is responsible for setting strategic direction to make sure that we’re all going in the same direction they need to set that and decide what what are we what are we investing in where are we spending our money holistically ultimately we need to shorten as much of our feedback loops as possible and the quicker we know we’re building the wrong thing the quicker we can stop building the wrong thing and build the right thing the worker we can find out that something that we are going to build is right or wrong or needs to go in a different direction the better so we want to be able to get into that loop of delivering as quickly as possible and this particular group this team delivers to production every three weeks so every single sprint goes to production so they’re able to get the output of the work they just did in the current three weeks in front of the customer during those three weeks they actually do continuous delivery and and then get feedback from them right away as soon as users are able to use that so we want to shorten those feedback loops by shortening the time to market in order to really understand how those things are happening you want to be able to get an understanding of what’s going on in these four areas the specific metrics that you measure are going to be up to you but you want to make sure that you’re looking and at what’s your organizational capability and how do we improve that so the first part is time to market obviously how quickly we’re getting our product out to our users and we might have a bunch of metrics that we’re going to monitor those metrics are going to change over time as we get better some metrics become less meaningful if we’re in continuous delivery how quickly we delivered the customers maybe become such a small number that it doesn’t matter anymore we also want to look at our ability to innovate and in our ability to innovate we’re looking at are struggling with complexity there sees new features in production our ability to add stuff to our product baracy struggling with complexity sets our organizational capability and then we also want to look at the the market we want to look at the current value that we’re delivering how do we know that the things that we’re creating are providing value to our customers how do we assess that value and increase work to increase that value that’s one thing

Abaddon’s you’ve also got unrealized value that’s effectively opportunities you either weren’t able to go after or or didn’t didn’t know about didn’t know about one’s a little bit difficult to measure but the unrealized value is important to balance out at that picture of what’s happening in the future

so increasing value and in the what space is all about product not project although projects may be going on and one decision-maker called the product owner you can call them whatever you want the rule is the product owner regular planning and realignment so instead of having a long term plan have much shorter plans usually three to nine weeks and have them cycle through I am most the most common cadence I’ve seen for that realignment of planning is two weeks sprint of two weeks is this is the normal now it used to be 30 days a month us what the scrum guy talks about part of that is because technology has changed over the last 20 years that scrum has been around 20 years ago it was really hard to ship your product to production on a continuous basis today it’s easy to ship your product to production on a continuous basis and I teach a class called the professional scrum foundations class in the professional scrum foundations class and the team’s this class is designed for for everybody in your organization but you need at least one software engineer per team per team of five so one in five people in the class is a software engineer you can do it and and we build software in the class and I have had a team do a 30-minute sprint and at the end of that sprint they’ve set up source control they’ve set up a continuous delivery automated build they’ve got that automated build feed into a deployment pipeline and they’ve got the deployment pipeline deploy the application out to a production place where anybody can access it and and they did that in 30 minutes as well as creating product and that was a team of five think what that team could do in two weeks if they could do that in 30 minutes

so being able to get as early feedback from customers as possible and and measure the value rather than activity so don’t measure how long people spend per day doing the particular tasks it is completely meaningless it’s about the value that you get for your users a good example of that is that same team that I’ve been talking about and this is features delivered per year with the azure DevOps team which was the TFS team at Microsoft and in 2012 they were delivering 22 features to production each year they spent a lot of time reorganizing themselves paying back 10 technical debt moving to a three-week cadence for the dalish to production every three weeks and over the next what’s that in the in the graph six years there they’re still going in that model bits from 2012 to 2017 they ended up moving from 22 features to production each year to 260 plus features to production each year most of that paying back technical debt lack increase collaboration so we remove that 50% and spend time working on the right features rather than the wrong features you can get these optimizations as well if you’re willing to change your organization change the way you do things in order to get there so what about the the who the culture in the organization we need to change a lot of other things to make it work and really it’s that flipping it on its head that you you you hear about a lot rather than customers being at the bottom and the CEO being at the top and you customers are around the outside and you have delivery teams delivering value to those customers on a continuous basis and with CEO online of business leaders setting strategic direction at that level as the modern digital organization is based around that idea of we have a cross-functional delivery teams across our organization continuously delivering value to our users and we’re getting feedback and adapting that idea one thing to note is that is that culture eats your strategy for breakfast whatever whatever that strategy is it is your people and that will both make it happen and get in the way of making it happen so we have to bring bring them along we have to make sure that we cater for the needs of people they are not resources that’s traditional terroristic thinking where most modern management practices were designed around managing factory workers Industrial Revolution and factory workers is a whole different ballgame from knowledge workers so there’s a really good book by a gentleman called Dan pink called drive and it’s about moving away from the carrot and the stick towards something a little bit more modern so carrot and the stick really only talks about extrinsic motivations motivations from the outside so if you as an individual do not have enough money to feed your family you’re struggling to feed your family put a roof over your head the only thing that matters to you is solving those problems and that’s going to be more money however once and I hope all of your knowledge workers are in this category and once you’re not struggling to put food on the table motivation changes to intrinsic motivations and those intrinsic motivations are autonomy mastery and purpose and autonomy is being in charge of your own destiny you decide what you work on when and how mastery is about being good at what you do most people in knowledge working space want to learn more do more be more capable and better over time and have a purpose so they want to feel like the things that they do actually matter but we have to have a balance there and you got a balance autonomy an alignment if you have too much alignment you’re going to stifle the innovation of these smart people that you’ve hired to go do the work if you have too much bureaucracy in your organization then they can’t go solve problems and interesting and innovative ways that will get you to market quicker but if we have too much autonomy then you end up with a bunch of people going in different directions so you need to find that balance inside your organization you need to figure out maybe where you are right now where you would like to be take one step in the direction you would like to go see where you get to and inspect and adapt those changes to your organization as well make a change see if it worked getting those changes in front of people they don’t have to be perfect you just have to try stuff see if it works and we need to try and shift shift the needle from management over to leadership rather than talking about deadlines and timelines and project plans we should be talking about a flow of value getting to our customers because the deadlines don’t really matter you might have deadlines that do matter you might be in a regulated industry you might have to meet legal requirements those are constraints that are out with the bounds of this conversation I can’t help you fix those they were just things that happen you might have FDA regulations you might have whatever but within the bounds of your organizational constraints how far can you go towards folks on product owners on floor and on value how far can you go you want to get as close to that as you can and instead of having providing people with answers again a tailor istic management practice because people don’t need to think if they’re doing monotonous factory work we want to enable our self-organization with our scrum teams so they get that autonomy they feel like they’re in charge of their own destiny so these are some changes that we want to move away from towards those from management towards leadership and in order to do that it’s important to establish Scott strong scrum mastery inside your organization there is I feel that there’s a very tight relationship between a scrum master and a leader inside your organization they have some of the same roles and accountabilities they’re just maybe operating at different levels inside the organization

so a scrum master can the role of scrum master again it’s not the up title the role of scrum master can operate at any level they can be a change agent for your organization they can be a coach to individuals and they it can be a new management role but it should never be a servant or moderator for teams that’s not the role of the scrum master you’re hiring smart clever resourceful people take advantage of that

that’s this that’s really where you want to get to in order to achieve that scrum masters Cana and we talk about in the agile community this is from the agile coaching competency framework that they had your floating Institute and the many stances of a scrum master and so if you’re a lean agile practitioner you understand the foundations of agile you understand the foundations of lean and you figure out how best to use some of those techniques in your organization and you’re going to need certain skills depending on which level you’re focusing at depending on the size your organization as well may be constrained but you need some level of technical mastery so that you can help teams be able to do do this thing this DevOps thing do a continuous delivery do feature flags hiders how do those things work and how do we encourage our teams towards those models how do we encourage them towards doing TDD and having code reviews and doing all the things they need to do we need your masters need some level of business mastery how are they possibly going to be able to help the the product to owner become a better product owner if they don’t have some level of business mastery so you’ll find that many agile leaders have that business mastery already what about organizational transformational mastery if we’re going to make changes to our organization we’re gonna try and get better at delivering remove bureaucracy in order to actually get things done and how do we do that how do we make those changes at the organizational level these are these are all important questions there’s no right answers I would recommend looking at the agile coaching Institute’s classes and courses and seeing what you can do there you can also take the professional scrum master class where we talk about and introduce some of these things or the advanced master class from scrambler dark where we talk about liberating structures and how we can organize people around getting the best most is the wrong word getting getting the most effective outcomes from groups of people facilitating that a much higher level and it’s a very powerful powerful class

so professionalism the how what are we going to talk about here so um there’s an interesting misunderstanding that and everybody on a scrum team has to be cross-functional that’s where this well this is where I believe this magic unicorn of the full stack developer that came from and these people that are cross cross functional but they seem to be a suicide me knife they are actually very rare many people will say they’re a full stack developer and they’re they’re not they’re actually just a generalist they might have deep specialism in one two maybe three areas but they’re a generalist my background and expertise I was a software developer for ten years then I moved into the DevOps space with TFS and as your DevOps and I helped customers optimize their their processes for many years and I moved very quickly towards that process agile scrum lean Kanban all of those things as well that’s my expertise my expertise is not in testing however I have taught testis I have a general enough knowledge in testing on what tests mastery should look like in order to go help and coach a group of people around getting better at testing they are going to be the experts I’m definitely not going to be an expert in that but I can help them move towards getting them also fit so I can be a generalist I can do testing I just am NOT an expert I can do DevOps I am an expert I can do documentation writing oh maybe I’m okay at document writing we all have lots of different skills if you look at a Harvard Business Review article from 1986 called the new new product development game it talks about all of the research that was done to figure out that a team of generalists will almost always outperform individual specialists because that now my dear that somebody smart comes up with yes debunked by somebody else you have somebody to bounce your ideas off you know that thing where you have a problem you can’t figure it out you go talk to somebody who maybe has no idea what your problem is but in talking it through you figure it out they helped you figure it out if you have a bunch of smart people together you can surf ideas you can figure out the nuances of those things bring those different backgrounds together Microsoft I think has done white paper on how much diversity is important and the outcome that I understand is that the more diverse a team the better and that was race religion culture background everything technology the more diverse the people in a team the more are the better the outcomes that the team has so in that vein the old way was that and again this is the tailor istic practice from factory workers we’re gonna have a management team we’re gonna have a development team and we’re gonna have test team and we’re gonna make sure that they don’t talk to each other and that the the you know just send bugs back and forth or instructions that really doesn’t work

so these your DevOps team at Microsoft move very quickly at the start they made a lot of mistakes in this process don’t get me wrong but they got a lot of learnings as well because by making mistakes we learn things and they move to a single engineering in fact they also pulled in other roles as well like service delivery UX UE all of those things coming into at one place and then they created teams our own server or I have delivery teams around people from engineering paired with somebody from program management so that you get that holistic strategic direction plus smart ideas for for doing and delivering on the work so bring them together but you still when you move away from that idea of having M core I’m just looking at test and you move towards having a cross-functional team and you maybe start to lose some of that expertise that testers can share with each other when they’re sitting together in the same department now there are on lots of different teams so the way we tend to handle that is with communities of practice and it’s kind of like a user group you know if you want to meet up you’ll find it by user groups you can go to the Knitting user group how do you make sure that you share knowledge inside your organization run internal user groups on whatever topics make sense I would expect communities of practice around architecture in order to make sure that the the teams are understand why architecture is important rather than telling them how to do their architecture educate them on what good architecture looks like same for security same for tests same for coding that same for any of the practices that need to happen inside and around the team so they can share share that knowledge so for this particular team at Microsoft you might be asking well what changed with just the things that I talked about things that changed or did more things change well really everything changed for this team they moved from delivering software they were actually on a two-year cadence with a service pack halfway for many many years and that built up a lot of technical debt because you generally didn’t go back and change the same thing over and over again on an iterative basis as you learned more from the customer it was more fire-and-forget and lots of bugs I think at one point they had tens of thousands of reported bugs in the system and it got too much they were struggling under the same complexities that everybody else struggles under even though their main business seems like its building software Microsoft’s main business is not building software they do what everybody else does they build software to support their main business productivity tools whatever whatever that that is so in order to move forward you need to create professional teams they need to be empowered delivery teams that are able to take ideas that people have turn them interval into increments of usable software things that people can actually use shorten those feedback loops and reduce the technical debt maintain communities of practice and measure the outcomes don’t just assume that the features you build are going to be useful to your customers make sure they’re going to be useful to your customers so if I was to have some takeaways have product owners with clear ownership that maximize value to your customers and create professional teams that embody technical excellence and I can’t stress at technical excellence more and is really really important and have strong scrum masters that are empowered to be organizational change agents that are not going to accept the status quo that are always going to be pushing on those things that maybe we can’t change right now but we should be changing in the future how do we bring HR into that story how do we how do we do that so I talked about three well really four areas I I described the problem that we have where we’re losing a lot of time where we’re losing a lot of resource where we lose hemorrhaging money all over the place in engineering and software development at the moment and we talked about where those problems are coming from at the who the what and the how and I’m in each of those areas we talked about some of the things you can do to try and reduce the level of waste in those areas and improve the situation even small improvements even if you made a 1% improvement think of the budget in your organization and what does 1% mean to your business even 1% can be important so don’t think about I need to change everything think about what’s the first thing that you need to do to try and improve things do that see how you get on okay so let me see if there are any questions if there wasn’t I don’t see any questions that doesn’t mean there wasn’t any questions I know that there was some questions to my Q&A last time that didn’t pop into my thing uh but please feel free to contact me if you need anything um I’m available on my website

nikki agility comm and KD agility comm there’s my email my phone number and my twitter you can contact me anywhere you would like cool so there we go but the one I want no that’s the one I want so hopefully that was useful and I hope to see some of you at the Q&A on Tuesdays okay thank you very much naked agility is available for DevOps and agile training and consultant contact us for a free consultation