26 Heuristics For Effective Software Development – Allen Holub

[Applause] let's go straight ready to rock yeah let's just do it yes boom good luck good luck so you can hide hide me uh valerian [Music] remove me from the stream but welcome Alan uh thank you for adjusting and uh the stage is yours please uh share your thoughts and wisdom about how to achieve effective software development so uh first of all we've been having technical issues so I had all these great slides prepared and you can't see them so the slides were just kind of boring slides with text on them so it's not that big a deal um but you won't be able to see my email address and that kind of stuff which is how I like to field um uh questions and stuff after afterwards so um let me just say it and then I can then I can move on is the my my main address is my name it's Alan holdup.com h-o-l-u-b.com and on Twitter I'm Alan Holub and on Mastodon I'm I am Alan Holub at mstdn.social so um hopefully that didn't go by so fast that you didn't see them but um there we are as a technical diff there's always technical difficulties and this is proof so um what I want to talk about uh this morning for me or whatever time it is wherever you are is um a set of heuristics that I put on my website oh probably six eight months ago now about effective ways to do software development now I I am deliberately ignoring the word agile when I say this because agile has turned into this perverted morass of horrible stuff that doesn't work and as as Andy Andy Hunt once said agile has become do half of scrum badly and use jira and of course none of those things have to do with agile so I'm kind of giving up on the word it's a it's just it brings too many kind of bad connotations with it so um what I did is I I then in my own history said okay let's go back and look at the agile Manifesto but I'm finding that people don't understand the agile Manifesto either it's too brief and a lot of people deliberately interpret it in negative ways in order to discredit agile and so it's not working anymore either unfortunately is that it's a it's a great document I recommend that you pay attention to it but um it's just not working out anymore so I came up with these heuristics they're on if you want to if you want to look at them um they're on holub.com h-e-u uh but I'm so I'm going to go through them um we're not going to be able to do all of them in in an hour or 50 minutes uh so I'm gonna I've changed the order around a little bit to put what I think as the most critical things first and then we can go through as many as we can go through so um let's start the the first uh thing on that web page is not actually a heuristic it's a copy of a tweet that I um gave a long time ago that is summarizing agile in three sentences work small talk to each other and make people's lives better and that's really the core of doing things in effective ways is that by working small what I mean is that you develop very very very small bits at a time now I work from user Stories the word user story is another term that's gotten perverted into something that has no relationship to what it originally was a user story really the actual definition is a user story is telling the user's story in other words it's not a it's not a code word for some task that you have to do the user story describes your users work not yours so it's describing a user's problem and it does that as a couple sentences at first and you flush it out right before you develop but the point is is that you don't know what the solution is going to be until you actually start developing the software so part of that process is to make these stories as small as possible you want to reduce scope one of the good ways to describe that is with something called workflow analysis and with workflow analysis what you do is map out the whole workflow to the whole story and then pick one path through that work story and that's a smaller story the other way you could look at it is that if there are if statements in the work story every branch is a separate story there's a switch statement in every case is a separate story so you make the stories as small as possible and once you do that you then start implementing now talk to each other is the next stage there so what that means is you're having continuous conversations with the other developers with people in the company the business people and of course with the users and that's something that a lot of people leave out and something that a lot of fake agile companies who don't allow you to do it's impossible but since you don't have a solution when you start working you have to develop that solution collaboratively as your work in the planning stage if you're doing Sprint and Sprint planning you come up with enough details that you can start not finish and then you implement that and then you get some feedback from your users and then you change it and add more details and so forth until you eventually get done so it's a continuous conversation you're talking to everybody all the time the last piece then is to make people's lives better and that's what the story is All About that's what we're working for Sprint has this notion of a Sprint goal and a lot of people misinterpret it or scrum rather has a notion of a Sprint goal and a lot of people interpret that as um finish these five stories and that's not it at all is that if you actually read the scrum guide which I recommend that you do um a Sprint goal is a strategic goal basically it's make the user's life better in this area in this subject area in this part of the system and again it doesn't describe the system it describes your users problems and how to make things better for them so the entire Focus then of this approach is on users not on Tech is that the user stories describe the user's work they're small you can continuously talk to them you talk to each other too of course you talk to people on your team you talk to other teams you do whatever talking you need to make the work work and then you um are doing it in order to make everybody's lives better and that's not just the customer that's also you so if you can't go to work every day rested and relaxed and with a smile on your face and able to do the best work something is wrong there if your process doesn't allow you to be happy if you're not smiling there's something really wrong with uh with what you're doing so um don't do that right just think about yourself so Next Issue moving into the heuristics itself the first one says without psychological safety respect and Trust you can't do anything so let's talk about those three issues again core things that have to happen in order to Be an Effective software developer psychological safety was developed by a woman named Amy Edmondson who's written a few great books one's called teaming and one is what's the second one called I've spaced out I'll go I'll tell it to you when I come in but her name is Edmondson Edmund m o n d s o n I believe or Ian but um Amy was working in hospitals and the problem that she uncovered was that a lot of good advice was being ignored because of the power structure within the hospital and nurses for example were really unwilling to speak up during meetings where they were talking about improving process and we all see that right it's people not really willing to speak up because of the power structures within the organization so what psychological safety is is that it's not safety in the current um sort of woo-woo sense right it doesn't mean you go into a room with people that you that have to follow certain rules in order to be able to interact and that one of those rules is almost always um don't have real discussions right don't don't get so upset about something that you you raise your voice right all of that stuff psychological safety has nothing to do with that psychological safety is an environment in which you can speak without fear no matter what you have to say so if you need to criticize the process maybe even if you need to criticize people that of course that's got to be done carefully just from a social point of view but it shouldn't nobody should ever feel that they can't say something so psychological psychological safety is not in other words about eliminating discussion it's about improving discussion about increasing the level of discussion that happens making the discussion more lively and getting work done so um the there are some side effects to that is that one of the things that you see in the in the quote safety movement is people say you should never interrupt anybody and that's not strictly true is that the if you're going to have a lively discussion it's going to be a certain amount of what Tim ottiger calls collaborative overlap in the in talking right so people have to be very much aware that that's going to happen if people are excited and that's fine and everybody can do it so if somebody is feeling that they can't get a word in edgewise then they should speak up in a safe environment and um and people should then pay attention in a safe environment and and deal with it so that's the first thing psychological safety respect is the next one is that if you respect the people that you work with then a safe environment becomes much easier it's uh the way I think about this is give people the benefit of the doubt so if somebody's stepping on the ends of your sentences all the time and they're doing it because they're excited rather than because they're doing some kind of power thing and they're wanting to Discount you then where respect goes is is in the direction of of um giving them the benefit of the doubt respect also has huge effects on management in an effective system the people in management respect the people that are doing the work there's an important lean principle that I think applies to all of this which is that the person that's doing the work makes the decisions so uh that's a misunderstood concept unfortunately and it should be it's essential so you don't have a situation where data flows up to some manager and then decisions flow back down because by the time you've made that Loop the decision is not valid anymore things on the ground have changed and more to the point if you're going up through multiple layers you're playing a game of telephone or what they call Chinese Whispers in the UK where you have a bunch of kids in a circle and each of them Whispers a message to the kids that are around them and then when it gets to the who gets all the way around the circle it's been distorted into something awful the the problem with that is that um people have studied this game and what they find is that the kids uh deliberately change the message a little bit in order to make it funnier so you know that's a benign thing to do but what happens when you do that up the hierarchy down the hierarchy thing is that every stage you go through people start changing it for political reasons and they start changing it because they don't understand something so they they change it into something that they think is better but it's actually wrong so that just doesn't work that system does not work and all of the things that surround it uh the surveillance that happens inside of jira I'm constantly uh collecting ridiculous metrics that have no real impact on anything but they're used to punish people um none of that is good so the solution to that where respect gets us is that you respect that the people who are doing the work can actually make the decisions so if a team is talking to a customer and they need to change something they just change it they don't ask for permission from anybody they don't um they don't go to some product owner and ask permission there the product managers ideally would be working with the teams on a day-to-day basis so the product manager would be right there in the room when the decision is being made and they could Supply their input but um I don't believe in the scrum product owner notion is that it's too it's too much a single point of failure and I'm from my point of view these things all should be done collaboratively like by the team which means that everybody again has to respect everybody and trust everybody so that's the third thing trust is you have to trust the people who are doing the work to make decent decisions you've got to trust the people around you to contribute um everything is based on those three principles so moving on um the next principle is that everything that we do is part of a system part of a larger system and if you focus on local optimization that typically does not improve the behavior of the system at all there's a lot wrong with bad software development that has to do with looking at individual people individual performance reviews for example or looking at the effectiveness of a team and that kind of focus hardly ever helps is that the only time the the individual never matters what matters is the team and it's of course in a trusting environment uh the team will help the people that are slowing them down in order to make them not slow them down so there's a mentoring relationship there's uh training going on if there's a trust relationship if a team needs training they just go get it they don't ask anybody they don't get permission they just go get it and the the um the team itself then is responsible for improving itself now whether an individual team will have an impact on the whole system depends um entirely on whether they're what's called a bottleneck or not so if a lot of people depend on one team and that one team becomes the bottleneck that all work has to flow through that one team before it can distribute back out again then optimizing that team will help um it's better though if you distribute the load that that team is shouldering by not having a single bottleneck by having multiple teams and the best situation is to not have teams dependent on each other at all so the notion of a database team and a ux UI team and a development team and a product team those kind of silos are working against you so if you're trying to do things in an effective way it's essential that all the teams be able to do all the work they call this cross-functional in the agile world so the notion is that a team should be able to take an idea and get it into the customer's hands and in order to make that effective you need things like devops but devops is not operations it's developers using automated tooling to do things like deployment so that it won't take a lot of time right because they're responsible for getting it into the customer's hands not not delivering it to some Ops organization that will deploy it in a month or two months they're they're responsible for getting it into the customer's hands and the reason they're doing that is they need feedback so the the there's another point that I'll come to in a moment but the idea of feedback is essential to all of this if you're working very small the reason you're working very small is so you can get what you're working on into people's hands so you can get feedback so you can improve it now that doesn't mean you have to get it in everybody's hands right if you're doing a release you don't have to release to a hundred thousand people you could release the 10. and get their feedback and adjust and then when they're happy you can then release it to 100 and get their feedback and adjust and if they're happy you can release it to a few thousand and just roll it out in stages like that but the point of working small is that you get feedback faster and you can't get feedback faster if there's that hierarchy of permissions and you can't get feedback faster if you're working too big and you can't get feedback faster if some Ops department is sitting on what you did and refusing to actually release it to people so at the center of all this notion is that is we have a we have a whole system that is important and in most situations though the teams are not dependent on each other so the speed at which a team Works kind of doesn't matter because nobody's depending on them finishing before they can do what they're doing is the if you if you read about user Stories the the basic idea of a user story is that um um the let's see let me think about how to say this in a room there there's a set of criteria that bill wake came up with called the invest criteria and the first the i in invest stands for independent and what he means by that is that it shouldn't matter what order the stories are implemented and if there's a dependency between two stories it's probably not two stories there's probably one larger story um it's possible to make that larger story smaller but the story has to cover everything end to end it has to cover everything from the start of the work to the user getting into a state where they're they're happy they've delivered something that you've or they've built something that is a um important outcome in the domain so if your stories are not independent you can't work in the way I was just describing where a whole single team gets a story and works at whatever Pace makes sense for them for that particular story so speed is not an issue is there's a myth about agile that it's about building things faster and that's just complete nonsense is the the construction part of an agile team is typically not a whole lot faster than any other kind of construction there are things that agile teams do like Ensemble or mob programming that do speed you up is that when you're working together as an ensemble where you've got say six brains all working on the same problem at once you're going to move faster so generally speaking Ensemble programming is going to speed the team up a bit um the more important things that Ensemble programming do is that they it increases quality without diminishing speed and it increases the quality in every sense right the the user experience will be better the implementation will be better you'll have no bugs right because the code is being reviewed as you're working which means that you don't have to have do code reviews and that speeds you up so the there are there are things that agile in the lowercase sense of the word teams do that will make them go a little bit faster but it's we're talking 10 20 not not 100 or a thousand percent like the scrum stands what have you believe so why is agile faster agile is faster because you don't waste time building things that nobody wants or needs if you define the work as a big chunk hidden inside that chunk is going to be a bunch of little chunks that are irrelevant that nobody cares about and if you are then tasking yourself with building the big chunk as a big chunk you're going to be wasting a huge amount of time building the things that nobody cares about because you're not getting feedback fast so that's again another systemic issue right is the teams have to be independent or you can't work as a as a full system the other part of working in a system which is equally important is that the entire organization forms a single system what I'm talking about is not something that you can just do in engineering or just do on the team the whole organization has to do it because the organization has to support the things that you're doing as a team and the organization has to support the things that you're doing as a as an entire engineering department or as an individual and if that support is not happening or if as is often the case the organization is fighting against you it's preventing you from being flexible and doing your best work then you're not going to get anything done so the idea of agile is something we do in the engineering department that's nonsensical um because if you have a overriding culture based on mistrust and almost all big corporations their culture is based on mistrust if you have to get permission to do something necessary then you are not being trusted nobody trusts you if you are not trusted to get a pencil out of the supply cabinet you're not trusted and it's kind of an odd Collision here right because the the um the basic notion of let's put it this way they trust you to build software that will kill the company if you don't do a good job and that's pretty substantial so if they're trusting you to not kill the company why don't they trust you to know that you need a class on in some subjects and just take it right is why mitt forced you to go up through this chain of command to get two or three or four permissions to take a class um leaving aside the fact that that whole process of getting permission might cost more than the class does the the in a trusting organization you don't have that problem but again we're talking about the system here is that if the surrounding system requires that kind of nonsense then the subsystem of of engineering won't be able to do its work effectively is that everything counts and everything has to work together as a single system and as soon as you start not doing that you can't work again so the other kind of principle here is that um since everything is a connected system you can't change anything without tweaking everything if engineering starts doing things in a slightly different way you have to make sure that they're getting supported by the larger organization so a lot of the fake agile systems like safe right safe is kind of an Abomination I don't know anybody who actually really understands agile ways of working that thinks that thinks anything good about safe there's nothing good there um big corporations like it though because they can keep existing bureaucratic Management Systems in place and existing control hierarchies in place and call themselves agile and that's not the way it works because you have a big system is that if you're going to work in a natural way that control hierarchy has got to go because you're moving decisions down to the people who are doing the work so you're not controlling anymore the hierarchy will be much flatter because the teams are working at the best Pace they can to implement the story that's in place but this whole notion of being on schedule is not really relevant now that doesn't mean you don't have deadlines of course is that if you have a deadline scope has to change so if you have to get this out by Christmas or if you have to get this out by tax time then you start off by saying okay what do we really need to do to satisfy that who was a tax problem you say well by tax time it must be possible for people to or to collect let's put it the other way it must be possible to collect the information that you need to file your taxes and it must be possible to file so that's the key thing to get that done all of the bells and whistles fancy uis and that kind of stuff you can do that later so the idea of working in a natural way is that you work in very small chunks and the first chunks you work on are the most important the most valuable and then if there's still time left to the deadline then you can fill that in making it better so doing the critical stuff for us first is an important part of this but it also has to do with this notion of if you change something little you've got to change everything to provide the support so you can't improve an overall system just by tinkering with the parts if you think of a car as a system the point of which is to transport you from point A to point B car has a lot of subsystems in it it's got engines it's got wheels it's got Transmissions so let's say you need to get to from point A to point B faster so you say okay we'll put a bigger engine in it horsepower will solve all problems but if you put a bigger engine in now you've got to change the engine mounts you've got to change the strength of the drivetrain you've got to change the suspension to handle the weight you've got to change the the brakes right because if you're moving faster you've got to still brake effectively and by the time you're done when you drop that better engine in you will have change pretty much everything in the entire system in order to accommodate the new variable and work developing software follows exactly those same rules um the final thing I'll say about this before I move on to another point is that um a 10x programmer right the hero that comes in and Saves the Day is exactly this has exactly the same problem as that engine is that if you drop one of those people into the organization but you don't change everything to make it work then um it won't work there's no benefit um by the same token that one hero right the 110x programmer rapidly becomes a bottleneck we talked about bottlenecks a moment ago so what that means is that if you have one person who's the expert what happens is the people tend to then funnel most of their work through the expert and then they sit around playing Canasta or something until the expert finishes which slows the entire system to become a bottleneck so that gets us back to Notions of trust and that could suspect the Notions of talking to each other and of cooperation of collaboration is that the most valuable use of that expert programmer is for that person to teach everybody else how to get as good as they are that's by far the most valuable thing for them to do not doing the work itself is that's not particularly useful because of all the things we were just talking about is that the important thing is that um they help the entire system move faster so everything is system is systemic um I I if you want to follow up on this I have a reading list on my website it's holub.com reading and uh there's a section up towards the top of that reading list that has a bunch of references books and so forth on systems thinking so um it's worth reading those Peter senja's book um the um is probably the the place to start it's the most accessible of it there's a lot of systems thinking books are pretty pretty turgid so you might not want to want to start with the actual systems thinking books I'm sorry I'm looking over here I have to I have to look at the version of the slide so it works on my machine in order to know what to talk about next um the next issue is that processes exist in order for people to be able to be effective and happy so if the process dominates then it's impossible to do any of the things I was just talking about there is zero value in getting better at scrum because what you're doing there is elevating the process over the people there's a lot of value and getting better at delivering value to your customers whether scrum is the best way to do that or not is we can argue about that but a lot of people do some period of scrum mostly they're not actually doing scrum they're doing some weird thing that they've invented but um if you're doing scrum properly and by properly I'm what I mean here is kind of you're in agreement with the people who are actually experts largely the scrum training community and I would argue even further that the scrum.org people Ken schwaber's company understands the issues much better than the than the scrum Inc and the and the scrum Alliance people who are on Jeff Sutherland's side of the equation um because the scrum.org people focus on agility and they focus on doing things in the spirit of the scrum guide rather than chapter and verse do it by the letter but putting that aside the point is is that um if the focus is on doing scrum better rather than focusing on the people and the people who are doing the work and the customers then you're going to fail it's not about process one of the big problems with things like safe is that it's this huge complicated bureaucratic process that people spend Millions putting in place and they're not thinking at people you look at that horrific diagram that's on the on the safe website that shows all of the block diagram of what safe is and I challenge you to find people on that driver that diagram is almost entirely about process and management which is part of the process and there's no cut their customer is this tiny little thing in one corner and it isn't even present on some of those diagrams and the people doing the work are a tiny little statement in another corner and they're not even given names right they're just sort of saying it says workers or something in that diagram but the people are more important those two things the people who are doing the work and the people that you are selling to are more important than any kind of process and if whatever process you have is not elevating the needs of those people dump it it's not doing anything useful you know and people complain about well the process requires that we enter a ticket right an item comes in that's going to take five minutes to fix and instead of just fixing it you have to put a ticket in jira and then sort it into the backlog and that you know get it done in certain you know a certain amount of time and yet again that's putting process over people the people in question here are your users and if there's a problem that takes five minutes to fix just fix it is don't let process dominate the work so that's the next equation here is that processes are not important is that a good agile in the lowercase sense organization will not be following a process if everybody in your company is doing exactly the same thing if every team in your company is doing scrum you're not paying attention to this principle because the teams themselves get to decide how they're going to work and if the team says this isn't working for us they get to work in some other way if they want to do scrum fine but if they don't that's equally fine and if they want to modify scrum into something that works for them but doesn't adhere to the scrum guide that's fine provided that you keep all of these other principles in mind so um the the people have to come first in this world next thing the best ways to work are collaborative I talked about Ensemble programming a moment ago and that's one example of that so collaboration infuses everything you are collaborating with your customers to come up with the best solution for them which is to say you're you're delivering frequently so that they can see something concrete and then you sit down and collaborate you have a discussion about what's right and what's wrong and what's best to improve it um you have you spend time learning how the customers work is I I did a job for a Investment Bank decades ago now um but the first thing that I did as part of that job is that I spent two weeks going through the the new hire training program for the for the stock brokers just so I could really understand how their work worked and so I could have a conversation with them I could speak the same language I knew what was important to them and what was not important to them and so on and so forth and that made me much more effective at developing software for those people to use so when you're working collaboratively you have to first learn about the people that you're working with so that you can communicate effectively and then you make decisions together so people talk about customer driven design that doesn't mean that the customer tells you what to do what that means is that the needs of the customer are driving things in order to understand those needs you have to be able to have a conversation with so collaboration is at the center of that but collaboration also has a lot of issues in other places is that um you don't somewhere in the scrum guide it says you negotiate with the PO if you need to make changes within the scrum and negotiation is not collaboration so whenever you see that word negotiate that means that a collaborative relationship doesn't exist and the the um the the goal is to not necessarily agree the goal is to come to not consensus but consent and what consent is is people saying well I don't honestly know if this is work it's going to work I I personally think this thing is better but I'm being overruled here or we just can't tell we don't know so if you really have two options and you neither but it can prove that the other one is better than the other which is usually the case just flip a coin doesn't matter right it's collaborative process so you flip a coin and you build one and if it doesn't work you throw it out and build something else right that's how that's that's the agility in this system so that's part of collaboration though right is that if you're collaborating with somebody and nobody knows you don't argue you don't negotiate you run an experiment and find out it's part of the collaborative process um so you don't collaborate you don't negotiate with management you don't negotiate with product people you don't negotiate salaries salaries are determined collaboratively in an organization like this everybody is paid fairly everybody is paid well all the all the salaries for the whole organization are transparent which gives the management a little bit of motivation to pay women the same as men for example or or just even things out collaboratively I know of one case where you had a typical organization where everybody's salaries were Secret um there was a big bonus at the end of the year and the manager uh this was Ryan Ripley who was a great scrum coach if you want to learn scrum but um uh what Ryan did is he got everybody in a room with a whiteboard and he said here's the total amount of bonus that I've been given to distribute and I'm not going to distribute it you are so he wrote the number up on the board and left the room and at that point the team looked at that and they first thing they asked is what's your salary everybody put their salary up and then they distributed the bonus in such a way that it compensated for the people who were getting paid too little to bring their salary up to low to level and the people that were at the top didn't take any bonus at all so everything leveled out and basically they were making the same amount of money every year that's collaboration and when you have negotiation in salaries you don't have that you get a lot of imbalance in the teams and that imbalance impacts the work right bonuses impact the work in a negative way is that they pit people against each other it's people with they withhold information they hoard knowledge because that gives them an edge that makes them better than the rest of the team so they get a higher bonus you don't want that it's not effective so collaboration is important throughout this process collaboration with the customers collaboration with each other collaboration with the business but not negotiating negotiating does not help at all um the next point is that well actually it's one that I made earlier so I don't know that I this is the issue with not having the slides in front of me as I'm talking I kind of go off and talk about things for the next slides but um again we're talking well I wouldn't even talk about this one this is this one was about feedback and short cycles and I think we've discussed that enough um next order of business the most effective organizations are learning organizations learning is the work learning is not something that you do in order to do the work learning is the work itself so when we release small and collaborate with our customers to find out what's wrong and what's right and then improve things we're learning way to think about this is that everything we do from releasing a story to learning the stuff that we need in order to build a story that's all learning everything's learning if when we release a story that's an experiment and the point of an experiment is to learn something so we release release the story and get feedback in order to learn whether that story was the right approach or not you cannot fail in a release it's not possible to fail because you always succeed in learning something and it is our goal to learn things of course if you're a learning organization there's also traditional learning to think about and that's incorporated into the organization itself the last time I was a principal architect somewhere I set up a a regular bi-weekly University where people came and learned something this was not a lunch and learn I do not believe that you should take away people's lunch time in order to have them work that's just that's just 19th century thinking right is forced people to work every minute of the day it's not it's not good it doesn't work well so the basic idea then is that um if if what you're doing is um learning all the time then learning is part of your normal day it's just something you do 100 100 Industries which is one of the better more agile shops that I know about Hunter is the place where woody Zool uh worked and um his team invented mob slash Ensemble programming in Hunter and they are doing mobbing 100 of the time um in this case you're doing 100 remotely too which is a good thing there's mobbing it works remotely just fine but the the point here is that um every day they have a learning hour they start the day with a learning hour and this is not extra activity this is the first hour of the normal work day and basically somebody on the team teaches the rest of the team something useful and that might be associated with a worker might not be might be the discussion of architecture just you know something that um just learning more about the profession that's a perfectly legitimate topic there so they spend um every an hour every morning learning some organizations take it even further than that they'll they'll add they'll take an entire day out of the week and um spend that on personal projects which can be anything right the point of it is that by building these personal projects you learn stuff and that's eventually going to help the company and that's true it works works well so learning is at the center of pretty much everything that we do um the final thing since we're running out of time is that the notion of welcoming change is also essential to working effectively so if something needs to change you just change it and that rule applies not only to the work not only to the stories that you're working on but it also applies to the organization itself and the processes that you do and the products that you make a lot of people talk about road maps a tactical road map that says we have plotted out the work that we're going to do for the next three months right tactics we're going to build this then we're going to build that then we're going to build this other thing there is no scope for change in that it's a completely failed business strategy instead what you want to do is again focus on change so a road map in an effective organization is entirely strategic we need to move into this business area this part of the system is making our customers unhappy and we have to make them happier in that region in that area um it doesn't tell you exactly what you have to accomplish as that's up to the teams so the Strategic Direction says we need to move into this business area that we're not in and then it's the team's responsibility to figure out how right the the I know people who are ex-military and they say well if you're a squad in the field they don't tell you how to get to a destination they say we need you to be over here figure out how to get there and that's exactly the way things are working in the in a effective organization is that you are constantly um things are constantly changing and if things are constantly changing you can't do things that don't allow for change hold on for just one second my dog just stole something being like leave it sorry this is the one disadvantage of doing this at home is that I have to deal with this Menagerie that I have living with me but um the the basic idea here though is the um the planning that you do the process that you have and the nature of the work what you're building all has to be able to change in order to accommodate learning in order to accommodate learning so learning and changing are really uh two sides of the same coin and this applies again to everything is that um certainly applies to road maps that applies to organizational structure it applies to pretty much everything you're doing is that change is welcoming change is essential and you do that by learning things as you're working so um that's as many of the points we could get through it's the most important ones uh the if you want to follow up on this uh the I don't want to do too much Shameless self-promotion here but I'm going to be doing a full day class on this subject that you could follow in fact the fraternity asked me to do that but when they did I didn't have the class together yet so it wasn't really a possibility but if you sign up for my mailing list it's holub.com subscribe you'll get a note when the when I finally schedule the class right now I'm thinking of scheduling one in February and um the the SE these points are essential and the reason I titled this talk effective software development not rather than agile is because I want to think people to start thinking about what's effective not does it fit into some digital so um the basic I'll finish I guess with that notion is that in order to be effective you have to be developing your own ways of working based on a set of core principles and the point of these heuristics is to establish what those core principles are so that you yourself can come up with the details of working in a in a way that's going to be effective overall so we are at the end of our time here and um thank you all for attending especially since I'm competing with Kent is that is that if you I really appreciate the fact that you're listening to me instead of getting back because Kent is definitely worth listening to as well good uh thank you and I have to share that everyone was so happy to see you without the slides and experience oh good you know more and more I've been doing that it's not not having slides seems to work better it's kind of what's the point but there we are absolutely and uh and there was many notes like ah this is so true this is so true and and one of the things maybe but we can end of uh the the day overall of course some people wonder are there actually the companies that are making all this happen and following the principles and like what to do if I'm a part of our of our organization that is preaching safe yeah like can you encourage us and also give some advice of what to do when you are locked in um sure I'm still alive right is that I'm talking to people yes yes oh okay great um yes there are companies that do all this so you look at Hunter Industries you look at um much larger companies right Netflix um the the um sales force right I'm just trying to think of these off the top of my head so I'm not gonna have a big list but there there are lots of companies in all sizes that do this now I have to say that if your existing company is huge and not doing things well changing the way they do things is really hard um it's much easier to do this with a small organization with a large one but there are some pretty big organizations that have done the flip and some really huge organizations that are trying really hard to do this Microsoft uh comes to mind immediately so um yes it's possible as for making changes making the changes I'm absolutely that's possible but I know from working as a consultant which is a consultant one of the things I do a lot is I come into a company and I kind of assess it I just sort of walk around virtually and see how everybody's working and then I'll sit down with the CEO and make suggestions about how to fix things and um the there are a couple of issues there one is that I determine what's keeping the CEO up at night what what their problems are and then I don't say we're going to transform to Agile I think that's nonsensical I say well you know here's a way to solve that problem and of course me being me it's all going to be kind of lean agile ways of looking at things but we focus on the actual business problems which is something that the CEOs can understand and I say so you've got to provide this support the teams have to change the way they work in this way in order to pull it off it's an experiment let's not move this entire huge organization over there let's just take a couple of teams have them do them for a month and see what happens and all the stuff I was just talking about in other words and that could work right it was moving incrementally like that the the only downside I'll say about an incremental change like that is that if you if the increments are too long if you change too slowly the inertia of the larger organization is going to pull you back into the older way of working so incremental changes can work very effectively in large organizations provided that they're happening fast enough if it takes more than a year or two to do an entire transition you're moving too slowly and I've I've seen many companies that have spent three or four years doing a quote agile transition and I I have watched them systematically replace better ways of doing things with worse ways of doing things because that's what they used to do so um the sea levels got to have to be involved and you have to do it fast enough and you have to focus on solving problems not on installing some process yeah the process kind of doesn't matter yeah when installing described process is so much easier but uh yeah well it's it's mindless yes I don't know that it's easy right installing safe is not easy it costs a fortune it costs millions of dollars and then but it's mindless you don't have to think about it somebody else is telling you what to do yes and as long as you like read through this giant Tome and do everything on these thousand pages of directions you will somehow be successful and most you wouldn't get this from looking at the safe website but as far as I can tell at least half probably more of the organizations that move to Safe have abandoned it within a couple years because it doesn't work the problem there is that they then say this agile stuff doesn't work they don't know that what they were doing was not actual right so there we are right so that makes it even harder to transition moving forward because they've they have in their brains this agile stuff doesn't work so you can't use the word the dreaded a words just don't use it just talk about being effective just do this better it describes so well the pains and everything that is happening that I really wish like everyone could start to work in our industry they just watch you read your book suggestion and then start to organize yeah the reading list is pretty pretty good right and it's it's just basic stuff it's kind of a daunting list there's probably 20 essential books on it yes and and then a lot of other books that fill in the gaps but um learning this stuff is not trivial it's you know it's a it's a curriculum and the you have to it's a lot to learn yes taking classes can be faster if you take glasses from good people um that's often faster than doing the reading certainly going to conferences like The Eternity is a great way to kind of learn right and the the uh and again that can be faster you you probably if you're take going that route you probably need some coaching also because you know if they're looking at the eternity here we have this day that's packed with stuff and your brain gets full and you just forget things right and then then there's all the sessions you couldn't go to because you were doing something else I would have loved to have gone to Kent's session but but I'm busy doing something else during this hour so I I couldn't so um having a coach around to keep you on track and sort of identify things that could use some improvement and and then pointing you at resources that will help you improve that's that's a it's a good thing to have around when you're trying to do this yes yeah I will just in the end quote one of the person saying your talk was amazing Helen every minute was a pure gold so big big thank you uh great uh holiday season and a very good start of the new year you do you too brother thanks a lot bye-bye

Channel: DevTernity Conference

Views: 5,123

Keywords:

Id: ZrluwfgUQk8

Length: 52min 42sec (3162 seconds)

Published: Wed Dec 06 2023