We're AGILE Developers! (And What That ACTUALLY Means)

Transcript is auto-generated and may contain errors.

what is up it is Monday evening I got to get home CU I got to do a live stream soon um and I don't want to miss that cuz it's scheduled um did a couple topics today that were submitted I think there's a third one but it's on my whiteboard and I am not at home to look at my whiteboard I basically remember two that I wanted to go through and I did them both this morning morning but the third one I can't recall um so I was thinking about talking like just doing a stream of Consciousness around like what it means to I'm already nervous about saying this word what it means to be agile I can visualize the clickbait title right now right um CU everyone is up in arms about agile and agile's never worked and I mean whatever uh but I

wanted to talk through this um kind of share my thoughts around like being my experience at least in a startup and what that looked like again to be air quotes I'm going to be using going to be saying air quotes agile a lot it's dark in here so you probably can't see um but I want to talk about that I want to talk about how that started to change as the company grew and then I want to talk about like what my observations are in big Tech so far um obviously your mileage will vary with all of this and kind of compare and contrast things because I think there's I don't know I think it's very interesting when we start thinking about scaling things up and like how do we maintain it's a triggering word I know but how do we maintain agility um it's

funny when I started at Microsoft I was hired onto a team that was called deployment agility right so um it's always about agility but if you have um questions and stuff you want me to go over add them in the comments I will review them uh and then try to get something put out for folks uh and if you want it to be anonymous just send me a DM on social media find me as a Dev leader uh basically on any platform just say hey was watching Code commute and was wondering if you could talk about whatever your scenario is the more detail you add uh the more effectively I can try to respond um and of course I'll keep it anonymous because it doesn't benefit me in any way to to not do that so with that said um agility uh I'm not strictly

talking about um the capital A agile here um I think in theory capital A agile is supposed to contribute towards that but I realize in practice uh especially from hearing from many people that's not actually been uh the case that they've experienced right in fact a lot of people in the last whatever you know that I've observed at least in the last 10 years have been saying like no agile is not um this is the worst thing that's ever happened it's just it's just processes but like it's kind of ironic because like by definition it's not supposed to be so it's kind of funny to me but this this is uh the worst I've ever seen this spot of the highway what's going on here let's get out of there real quick um so when we're thinking about agility I I'm going to keep saying

the word agile and Agility and I don't want you to think scrum to think can ban because I think for at least a lot of people they're here hearing that word and they're going well no when people were talking about agile um it's only been this bad negative experience people were putting processes in place there's you know we're doing Sprint planning with the cards and the story points and like this is the opposite of being agile and like yeah I get it I get it man like totally and when we were doing that stuff at the startup that I was at like over time my team stopped doing that because we said this is ridiculous at least for us we're spending way more time doing dumb with cards versus just building software so what we would end up doing is we start we had a

baseline to start with these things okay so um it's not that we did literally no type of process or ceremony and it was just like you know you come in every day and hope that you're working on the right stuff and cross your Fingers um there was more structure to it but it took a couple of years of like trying to be a startup trying to like make things work and going okay well everyone's saying that we need sticky notes on a board and we' got to digitize it and like we got to do story points like we had to try this stuff out and then we were like this feels terrible now that's not to say that it doesn't work so I'm not here to say that like agile in that sense doesn't work but it didn't work for us uh in particular the

teams that I was running it just was awful um and what would happen is like when we were pulled into other teams to work with them and they still were using story points you could feel like from my experience you could feel how much less effective uh it was to go try and do that because we'd be like why are we why are we debating a three versus a five or a one versus a three on these story points when like you could have been halfway done the work so what we found was valuable to be honest was not a story Point debate but what was interesting is those story Point debates would would trigger conversations and what we found was valuable was the conversations around like when someone says we got to do X work like what things are involved with that right and

we would have conversations about these types of things like our understanding and what was interesting is that we would try not to go completely off the rails and like implement it but it was good to get a high level understanding think about some technical challenges that could come come up in general right and just like having a conversation about these types of things was really useful now we also had a very technical uh product owner which is great at a different point in time our product owner switched out we had a less technical product owner but he ramped up in the domain quite effectively and he had a lot of trust with us and that worked really well for us because we could find ways to explain things and maybe ditch some of the technical Concepts and because he trusted us a lot um we

could we could kind of arrive at like if we needed to push back um like I said there was trust so that he's not like are these guys just being lazy like we would be like no man like there are some challenges with this so like if you want us to do X like we can do it but realize there's going to be a cost associated with why over here and like kind of like give him the options to pick and choose um but it was all based on the fact that we had a good trust relationship oh my God come on people one more Lane let's go now we're cooking there's like no traffic today I say that and then I'm looking at my Google Map and it's like stalled vehicle ahead and there it's just solid red um we'll see um so where

did I I got distracted that's the it's me merging onto the highway um come on Nick get your head on it's talking about teams talking about being agile we got past the store points you can tell it's Monday my brain's just like not it's not on um oh the conversations about like um I talking about product owners okay we're back on track welcome back folks um so for us it was like this core concept where we like I said we started with some type of process because we had to start somewhere and starting with process like was that a good idea maybe not um there was a bit of a reset point for us where one of my core teams um we basically started a product from scratch and when we were building this thing like we did start with zero process okay so I

I should clarify that we started with zero on this one product uh and formed a team around it so in this particular case um this was a project that we kicked off to try and see if we could build something inhouse so for context for folks that aren't aware when I worked at a digital forensics company I spent a lot of time doing prototypes uh and then scaling out the products afterwards um so I had built a lot of the sort of initial product offerings uh when I say initial product offerings I mean not the original product that's not my concept but I mean uh a a lot of the teams that were formed uh stemmed from prototypes that that we would go build and then they would uh kind of scal them out so on this one team and I think this is where

like this actually worked really well for us we we basically said we're going to see if we can build this in house we built um a prototype that focused on like a technical challenge so terrible user experience you could never it wasn't an M VP in the sense that you could give it to someone to use but we wanted to prove technical feasibility of something because we said if we know if we can prove that this works this guy's flying behind me holy crap um who said if we can prove this works we know we can build a product around it the business is already decided we want this product but we can build it inhouse if we can get past this technical hurdle um and the reason we knew that is because we had already started Outsourcing some of the development and they were

trying to make progress on the front end of it and not even succeeding at that so we said we know we can do that but the technical part no one has the yeah I guess the technical part no one's proven proven if it's feasible to do so we basically kicked that off proved the initial prototype and then it was Go Time so we essentially locked ourselves in a room at the office and started building this thing out and there was no process and I can remember so there was two of us we brought in a um like our test strategist so it was like it was one of technically he was a product owner but he's one of the technical product owners very uh you know has a engineering background software development so we were coding this we had our test strategist come in to

kind of be our our user proxy helping us think through how we would address certain things and we started building this thing out and I kind of remember getting to two interesting inflection points one was when we said okay this thing is real like we're we're doing it and we already have a product Suite that exists with branding with how like it's a real product that people are buying so we said wait if we're making this real like we should probably start bring in our ux designer to like help us navigate this so this was an interesting point in the development process where like that was changing things like we're starting to add a little bit more structure like should we go build things to the ux spec versus just drop a button in here get it going and let's keep moving on so there

was that moment and then there was also this point where we were saying and it was so funny we were like do we need to start making we used jira at the time so like do we need to start making jira items for this like do we have to start keeping track of some of this stuff we're doing and it was a natural thing for us because we started to realize there were too many like conversations we should do this we should do that oh remember there's a bug here we should go back and fix that we basically started like stumbling a little bit because we were trying to do too many things at once so a very interesting situation where instead of being forced to use a tool we were in a position that was like number one the ux designer like starting to

introduce a process have the ux designer sit down with us go through things and try to build a UI out that was one part and the second part was using a tool not being forced to use it but trying to look for a tool that's going to fit one of our needs because we need to like we're losing sight of what needs to be done um so both of these were natural progression and um I mean from there we started to evolve other things over time but we always kept things pretty pretty slim um eventually we would move on to do uh Sprints and that was I don't know when that came to be honest but we did Sprints mostly because we wanted to um number one align to some of the release Cadence for some of the other teams doing like monthly releases so

I wanted to align to that U by the way this is a like desktop base software in case you're wondering uh for context so aligning to that but also because we wanted to do retrospectives and this is a big thing for us because uh remember I I just said said like we wanted to like try using jira right like this is like may not seem like it but it's like one of our first experiments as a team right we're basically saying we think we think that we have something we want to try to improve things we should we should try it and see how it goes that's an experiment but how do you know if the experiment works and what if it doesn't work what if you very like you know very well it's not working um or how much time do you give something

to try it out so we said like we should have Sprints and we should do retrospective to talk about these things and really when it came down to it planning planning for us uh came sort of at like a a regular interval not not a regular interval irregular interval um came at an a regular interval came at an irregular interval yeah words so what I mean by that is we didn't say okay every quarter we're doing we're making our planner we're doing yearly planning or we have like seme like a six month planning kind of thing it would be like we generally have an idea of the direction we're going in we would use our Sprints to kind of iterate on that stuff and then periodically we would say okay like we as a team with our product owner we're starting to feel defocused right

we're starting to go ah is this really the right thing and then we would use that as a point to say you know what we got to sit down and have a conversation and just get on the same page realign our values uh make sure we're focused on the right stuff and that work in my opinion that worked so well because we didn't have um like wasteful planning like hey go plan for the next 6 months to a year and the only thing you know for sure is you're not going to do over half of what you said um so like it wasn't wasteful and our product owner had the Insight that he needed right like he had the the runway to have a rough idea what was coming he could plan around that so it worked well for us so when I say that

we were an agile team I mean like we had a lot of agility we could pivot uh our processes were extremely light we did use Sprints we did have retrospectives those things are air quotes agile the capital a um but that's how we did things now I think that just really allowed us to focus on the right stuff we didn't have getting in the way of what we were doing we could focus on what was a priority and if we felt like we were getting misaligned we would use that as a feedback mechanism to get ourselves aligned so I that worked well it let us move very fast because we could pivot as necessary so I think that worked out really well um what else by the way it's not obvious as I'm telling this that um that product that I'm describing that we were

building at one point we had to pause development on it and we started helping with other things and we ended up continuing to prototype a bunch of other stuff and then we came back to this product to kind of have like a full-time team around it so just as a heads up like what I'm just describing was useful and the progression of not only how we approached this product but how we approached operating as a team so we actually had the core of our team kind of move around to different areas and and focus on this stuff so um I think that's something else to be said is like we were kind of like a unit that moved around and that meant that we understood how each of us worked uh periodically we would have interns and stuff actually a lot of interns on my

teams for the years and uh you know so that would be a new dynamic or a new team member something would come in but for the most part pretty consistent team okay so when I I realized I focus on maybe a little bit of a different aspect than I wanted to initially go down but that's what happens when uh you're driving a car and stream of Consciousness ranting about software so if I shift gears and I start looking at like how some of the stuff works in Big Tech uh some of it feels like it feels bad to me maybe I'll put it that way um I'm not saying it is bad but I'm saying some of it feels bad and it feels bad because I'm used to personally when I'm running teams doing it a lot more lean and I realize lean is probably

also a loaded word too um I can't pick any words these days um lightweight I guess like there's not a ton of process we're kind of doing things as needed now I've noticed and I'm my you know my exposure has been to Microsoft on a couple of different teams but I've noticed that there's a little bit more maybe a lot of it more like process some place for the most part is maybe how I'd frame it but it's weird because I don't necessarily think like it's wrong I'm I was trying to be careful when I say like it feels bad but I don't necessarily think it's wrong and I think one of the challenging things here is like the scale that we're talking about not only from like a you know an impact perspective on like Services across the world but what I mean is

like the scale of teams that have to interact so for example the startup that I was at um there might be situations where a different product team is like Hey we're going to have a dependency on you for this right like we would have to uh our mobile acquisition tool is going to have to feed into a command line tool um or there's going to be a you know a workflow revamp in one of the main products that we fit into so like how are we planning to do that so this this stuff would come up it wasn't zero um but at Microsoft it's like especially as a platform team there is a lot more interaction with other groups a lot more dependencies um like it's nuts in comparison so I I part of me gets it right where we have to make sure that

we're communicating these things like uh making plans so that people know we're going to stick to them so they can expect when things are going to be delivered so I like I get it but the reason I'm saying it feels bad is because the same reality happens which is priorities change so if you make commitments about delivering stuff those that team that you're delivering for they might have shifting priorities you might have to end up dropping it because you have something else that's come up that's Mission critical um like things change so while I understand that some of the planning is beneficial in the sense that people need to know their dependencies what's coming up plan for it understand how they can deliver on timelines I get it but like I said what's not changing is the fact that there is uncertainty and things do

change in terms of like what has to get focused on so let me see if this guy's going to let me pass nice there's two there's only one lane here but basically everyone leaves the right side open so we can fly past except this idiot at the front um at least he moved over enough this person is driving at a really awkward speed like they're trying to move in this Lane but not we'll go past them um so yeah part of it feels kind of bad cuz we're going slow and the there's like more overhead but like I I think I can rationalize why it happens now what I find really fascinating is like it appears to me like that's the steady state of doing things okay so the steady state of doing things feels on the surface like it's much slower because there's more

overhead now what's the fascinating part to me is that there are situations where if we really need to focus and drive progress on something that um that sort of startup feel comes back even though it's a huge company you know on a team that's like interacting with tons of other teams if we say like like this stuff's got to get done this is urgent if it's a live site issue whatever it happens to be right when there's something where it's like we need the team to Rally it's so interesting to me that all of the the process it's like they're I don't know a good way to say this cuz it's going to sound weird when I say we can bypass the process it's almost like we we prove to ourselves we can get done without the heavy process right it's it's almost like we

snap out of it and we're like boom like here's efficiency to the Max and then we get through something and it's like okay back to steady state where steady state is this more heavy-handed approach so I find it I find it very interesting to be honest um and you know I have my bias that I I prefer like the startup kind of feel of just like be as lightweight as Nimble as possible some would call that agile um it's like I have a bias for that but at the same time I can totally get that um like more structure can be helpful in a larger organization so I think I would if I could like I don't know influence more areas at Microsoft I guess or and this would apply to not just Microsoft I work at Microsoft so this is my bias to be

able to talk about this it would be trying to remind especially other engineering managers like we I don't think anyone in leadership would complain about this is what like how I'll preface this but finding ways to be more like nimble in our approach I don't think that anyone in leadership is going to complain about that so if you're following processes that don't make sense like we should be speaking up about about these things if you're like yeah I know this is what it's been recommended this is what we always have done like I I feel like it's easier to be complacent with that stuff at a bigger company and it's potentially because it's harder to to drive that kind of change perhaps but I feel like I don't know like within a team we should have that autonomy to be able to to do that

now if we have to have planning and stuff reported up to leadership or something like okay like that's a requirement on your team and plan for that do that work you might you might decide like hey we did this and maybe maybe it didn't feel effective for you or something just as an example like maybe that's an opportunity to talk to someone in leadership and say hey like you know we went through this process here's you know here's the value that we feel we're getting out of it given all this work and like is this actually that much value for you because if it's not we should change this I personally don't know like certainly for me as an individual like as a engineering manager sort of at the first level of management um I don't know that I see a lot of that happening

and I'm not saying that it doesn't but like I number one I don't feel like I'm driving that at all and number two I don't know if other people are but that's something that like I would like to see more of uh maybe I should uh lead by my own example and and say more of this I think I started to do this on the previous team I was on where I was making a little bit more noise saying like I hear the process you're talking about but that doesn't feel like that's an effective use of time kind of thing so I started to do that a little bit more um so just a thought right like I think we can always improve I think we should always be trying to improve and that means that we have to challenge how we're doing things always

right we should be questioning these things we should be understanding because it might be a rock solid option today and we try it out and we go hell yeah this is helping us so much and we stick to it but if we never go back and revisit these things and question them like we stagnate and some of those things that may have been super awesome to try and do now become a hindrance they're the things that slow us down but we go we've just kind of always done it this way right so why would we change so I think it's very important to be constantly curious question stuff like this and I feel like that's what drives the continuous Improvement might mean some uncomfortable conversations right like we're going to we're we don't think that this is valuable like who wants to hear that right

um um but if it's not valuable like what's what is the goal that we're trying to accomplish with whatever process or whatever is being discussed what's the goal of that because if we're not finding what we're doing valuable maybe it's still the right goal but maybe the way we're doing it is wrong or maybe the goal itself is like it's no longer needed and we should rethink things so yeah that's kind of my thoughts for engineering teams uh trying to remain agile I think it requires that you are constantly questioning stuff um I don't think oh this guy's not driving you're missing your advaned silly you don't need to be practicing like agile with a capital a um I'm also not saying that agile with a capital A doesn't work uh briefly I ran another team in in parallel to one of mine that was

oh this car has Christmas lights on it holy you see that I don't know if you can see through the window but that's that's a distraction if I ever seen one that's for sure um I ran a team in parallel to one of mine so I at one point in time I had two teams towards the end of my time at the that forensit company and the second team was literally stood up to be um an efficiency thing where we took something that we could carve out from another team and said there's this type of work that seems very repetitive very structured not repetitive in the sense that the individuals are doing repetitive work but the structure is super repetitive and we said we really think that we can make something out of this that will go much faster if we only focus on this

type of stuff on this team and we Prov the experiment I can't remember the productivity increase but it was nuts and it's because we scoped out this particular type of work but we literally did Canan and it worked well and I'm not here to tell you this is mural crappy I'm not here to tell you like I'm a I love cand it's the only way to go or I love scrum it's the only way to go no these are just tools for this team it worked really well and because we had everything already done for us in a way that was very repetitive in my opinion it made it ideal for being like how do we want to tweak this process like do we change our whip limit do we change these other things so that we can try to optimize measure and learn um

but I thought that was a really cool uh team that we spun up I love that it was like an experiment to try out we said we'll try it we'll see if it's effective and like really good results from it no idea if they continued that after I left um but uh I think that we were proving the the value so there's different ways to do stuff and I think that at the end of the day if you are on a software development team I mean if you're not the one managing it I would still strongly encourage you to think about what are ways that we could work more effectively as a as a team and that can take many different shapes uh but I think it requires conversation so that's all I got so hopefully that was uh not too ranty and rambly but

you know what to expect by now so thanks so much I will see you in a couple days soz I'm not going to the office every day this week take care