Okay welcome everyone! My name is Philipp Dressler, I'm a technical agile coach and a Scrum master at MIC. And today I want to present or guide you through seven powerful questions that you could ask your development teams, and that might help... maybe, I hope.
Okay, so first of all, don't be afraid this is not the first question but just a few words about my employer at MIC; what is our vision? So we want to run the best cloud platforming customs, global customs and trade compliance. If you are interested, please visit us, everything is there on the homepage. Just go there and check us out, we'd be very happy.
And the word "best" is kind of powerful, so I want to show you a few things that I think helps us to accomplish this vision or reach this vision – okay, first of all; do you develop yourself? In software development we talk a lot about developing software. But I see teams that don't have a lot of time to develop themselves rather than software, so to say.
Okay so, teams usually need a place to practice their skills and we at MIC found technical agile enabling as a good solution to this. What is it exactly? By the way there is a great talk from Pia on TechTalks. So, check it out if you want to know details, but just in general; we as technical agile enablers or technical agile coaches work together with development teams over a defined period of time – let's say 3 months or so – and then we switch to another team and we try to enable their technical skills. We want to improve the way – together with the team – how they write code. There is another way to do this, which doesn't work really good, which is individual trainings – they are not as sustainable usually as collaborating continuously, in these technical skills at least. Of course this costs something. You need to slow down to speed up in the future. You need to invest in your current skills in order to get better in the future. And we already see this paying off in quite a few teams.
Yes okay, second question; can you show me how your users work? Okay, try to ask yourself or your developers, can you handle your software just like your users do? Obvious answer would be yes, sometimes it's not as easy. We've just seen this, we have seen it to be very beneficial to get the developers as close to the users as possible. They really need to get in a mindset of the users in order to deliver great software. Also features, a lot of features out there – not only at MIC, but also in the whole industry – are built and rarely ever used. This is quite a big issue I think. So, think about; can you measure how much your features are used? If you cannot measure it, ask your users. They will answer probably... hopefully. And really try to not build something just in case you might need it somewhere in the future. This will save you a lot of time, and you can concentrate on the stuff that's important. Also, we tend to build the thing right – we tend to test a lot and do all the technical stuff, but we also try to challenge ourself; are you building the right thing?
Alright, next question; can you give me an example? I think that's the most powerful question you can have in software development. The human brain works in a way, or it has way more problems in understanding abstract concepts, rather than concrete examples. So I brought up this little example here, if you read through those blue cards – I mean, this is an easy example I know – it will be kind of harder to understand the concept behind this. Blue cards would be acceptance criteria in our case. Then having those green cards as an explanation for them. Okay so, if you see the group that you're in lost in an abstract discussion – and this happens all the time right, we all know this – ask somebody to bring up an example, it will usually get you to the target way faster.
By the way, examples make great test cases. If you write them down, automate them or test them manually, whatever helps.
Alright, next one; we at MIC like to do domain driven design, we think there are few great concepts or a few great methods in this whole cloud of domain driven design. The most important one is probably in my opinion the domain language. Finding a common language that you can talk effectively on and also write code effectively. Sometimes it's hard to find the right words, so you need to learn how to talk business. And some times those words can be found in the past. Especially in enterprise applications like we have to deal with at MIC, the customs domain is something that's been there forever. Things have been shipped over borders longer than software exists. And sometimes it's just easier to think a hundred years back and say "okay, how did people call this and that back then," and you might come up with a great domain concept doing this experiment. So yeah, try to ask yourself. "The stagecoach", "Postkutsche" in german – okay, don't worry, we didn't make the stagecoach a domain concept in our code, but this helped us to to kind of sketch down our process and understand them and find the right words. So, this was kind of a, I don't know, kind of a god will known for some reason this stagecoach. And I think it's a great painting as well!
Okay, topic rework. If you ask your teams wether you have to deal a lot with rework – which usually happens, it's just part of the game – you could challenge when they test their code, the point in time when they test their code. Usually a symptom for this is when you see a JIRA ping pong, which we also know; so a ticket goes from developer to tester and then back to developer, maybe even back to product owner, this usually takes forever. Now, here are three quick wins that you could try out; first of all is discovery meeting or requirements workshops. What is this? Before you start pulling a ticket into your sprint, talk it through in detail. Try to find examples for the feature that you are about to develop. What you are doing there is you test the requirement before you've written a line of code and that's the cheapest way to test something. It works great for us.
Test driven development, I'm a big fan of this, I mean obviously it brings a lot of great test coverage – I don't have to say this probably – but also what's more important is, it will lead you to great decouple design and sustainable design. So, I think it's a great method to just try out if it works for you. And pair-/ mob-programming, I absolutely love this! It's so easy to apply. You just need to learn the basics and then get into it a little bit. The power of this is you will have instant feedback. The shortest possible feedback cycle on the code you write. So you won't have to do any reviews or ideally not even too much testing, so this will all happen together in the team and everybody will feel responsible for the code. So, those three things, maybe try them out if you haven't already.
Okay, big topic, technical debt! Ask your teams, is it easy for you to modify your or extend your existing software. Yes, so how do you deal with technical debt? Technical debt will accumulate, it will make you slower, it will happen. You can't really do anything against it. Unless you only... I don't know, produce software for the paper bin, which I hope you don't. But it's really interesting actually, there are studies that evaluate the productivity loss of development teams of 23%. Now, usually when people hear that, they say: "okay, this is not too high, it feels like we have more." There are other studies which say it's 42%, which I think is more realistic in our case at least. And this is totally normal right, this is not a bad thing, it happens to everyone. The question is how do you deal with this situation? I'll start with the negative of this; you could try to just add more people to a team, because it takes longer. This usually doesn't really help. I really like this saying: you can't give birth to a baby in one month with nine mothers – this concept kind of applies here too. It's usually not very sustainable. You could also keep paying off the debt, you could invest in your software and just run it the same speed you've always done, this will usually lead you to the teams breaking down to a halt and small changes that will take you forever. This is usually also not the thing you want. Nobody wants to work long hours, working long hours is 1990s, right? We're over this.
So, how could you approach it in a better way? Apply good technical practices! Again, this is what we do, or what we try to enable our teams in technical agile enabling. Refactoring, good design and so on. Okay, really try to focus on this. I really like the boyscout rule, concerning code: "always leave the place nicer than you found it."
Okay so, always do some refactoring, always try to make it a little better. And sustainable software development. To me, what this means is: automated testing and good design principles. Okay, this will be sustainable and easier to adapt in the future.
Last but not least: ask your teams whether they are happy. And this is more a question to, maybe to you as a leader. Nicole Forsgren does a lot of great research in the HR community basically, and she found that satisfaction and wellbeing correlate with productivity. This might not be surprising to anyone, still it's a fact. So, what could you do? Create an inspiring working environment! Whatever this means to you and your company.
I hope I could give you at least some thoughts to it. Thank you very much!