In today’s episode of Agile Coaches’ Corner, host Dan Neumann joins Eric Landes —a colleague of Dan’s and a Scrum.org certified professional Scrum trainer—to talk all about full-cycle development.
Landes, who comes from a DevOps background, originally started out as a developer. Currently, he serves as a Senior DevOps Consultant, ALM Director, and Solutions Architect. In his roles, he helps clients deliver value to customers in their software delivery pipeline, and has extensive experience in leading organizations in adopting agile and lean frameworks, like Scrum and Kanban.
In this episode, Eric explains what a full cycle developer is, what a full cycle development team looks like, who this model is designed for, how to take steps towards this model and improve your team, and where to get started. He also gives a ton of recommendations, valuable resources, and actionable tips and tricks you can begin using today.
- What is a full-cycle developer?
- Your development team has all the skills needed to build, deploy, etc.
- Responsible for the full software lifecycle
- Your team owns it from beginning to end
- What to keep in mind when transitioning to agile or full-cycle development:
- The journey takes a long time and the company needs to support the workers through structure and community
- A good leader is crucial
- Who does full-cycle development work for?
- It depends on the context — experiment to find out what works for your team
- Not everybody; different models for different organizations
- Identifying the problem you’re trying to solve can indicate which model you should use
- Steps to take towards improving your DevOps team:
- Measure to help drive improvement
- Monitor things in production so you can give feedback to the team on what’s working and what’s not
- Implement hypothesis-driven development
- Where to get started on your full-cycle development journey:
- Start with Agile and XP principles if you haven’t already
- Check out the Netflix Tech Blog
- Understand the principles and practices of DevOps
- Be sure to experiment, experiment, experiment
Mentioned in this Episode:
- DevOps Enterprise Summit
- Eric Landes’ LinkedIn
- Full Cycle Developers (Netflix Model)
- Woody Zuill’s LinkedIn
- “7 Habits of Successful DevOps” (with Sam Guckenheimer)
- Implementing Hypothesis-Driven Development
- XP Principles
- Netflix Tech Blog
- (Eric’s Book Pick) Turn the Ship Around! A True Story of Turning Followers into Leaders, by L. David Marquet
- (Eric’s Book Pick) Training from the Back of the Room! by Sharon L. Bowman
Like what you heard? Check out our podcast page for more episodes full of interesting discussions, agile insights, and helpful resources.
Introduction: [00:00:03] Welcome to agile Coaches Corner by agile thought. The podcast for practitioners and leaders seeking advice to refine the way they work and pave the path to better outcomes. Now here’s your host coach and agile expert Dan Neumann.
Dan Neumann: [00:00:20] Welcome to this podcast on full cycle developer. With me today is Eric Landes. Eric’s a scrum.org Certified Professional scrum trainer, a colleague of mine and all around good guy. And so we’re gonna be exploring full cycle developers today. Thanks for joining Eric.
Eric Landes: [00:00:34] Awesome thanks Dan. Nice to talk with you.
Dan Neumann: [00:00:38] I gotta be honest full cycle developer is a fairly new topic at least as I understand it. I’m just a full stack developer so where’d that come from what got you exploring the topic of full cycle developer?
Eric Landes: [00:00:52] Good question Dan. So I really come from DevOps background. I started out as a developer when we first started down the agile path we got a team together. It was bringing you know software developers and testers together and working within a sprint. As you know and that really resonated well with me as I moved on into my career you know the idea of hey we have to have a potentially shippable product so as you know and scrum at the end of the sprint you’re supposed to have a potentially ship of all product. So what does that mean. And to me that meant we should actually be able to put that in production and in a lot of enterprises there’s a lot of mismatch there right. I can’t typically push my completed software increment out to production easily. And one of the things I had been getting into was ALM and then DevOps and DevOps really answered that. And so as I began the DevOps journey I read this blog about a full cycle developer and the idea was our development teams should really have all the skills we need to build it and actually I was just at the DevOps Enterprise Summit this past week. And you know one of the things they said was you know you build it you deploy it or you build it you know you secure it. So that’s kind of the concept that’s coming from and there’s a bunch of different models. But this Netflix model is really our team owns it from the beginning to the end. Into production even to support so kind of a long winded explanation but it kind of resonated with me. Now what do you think you think that’s possible to do with the teams you’ve worked with?
Dan Neumann: [00:03:04] Is it possible. Sure. Is it where they are right now. Almost to a team I could say not at all. And it makes you think of some of the challenges they would have. So we’re used to developers who say things like well I can’t test my own code. Bogus. No that’s just bogus. Do you want an outside eye. Yes. Are you capable of testing your own thing? You can, you just don’t want to a lot of times. That’s my humble opinion. Very humble. What about you?
Eric Landes: [00:03:36] Yeah I agree with what you’re saying there. It’s a total change for a lot of developers a lot of testers. So another example talking to some guys from Microsoft. So say back 2010 if you were to talk to the Microsoft folks or if you’re applying for a job or whatever there, they’d have a you know developer and QA folks and you know the QA folks were trying to beat the crap out of the code and the developers. You know we’re developing features. Well if you talk to them today they consider everybody on the team as a tester. Everybody is a coder. So they don’t really have people who are considered manual testers. They’ve shifted that focus. So and I believe that if you’re going to be a digital transformation type company you’re really going to have to get there too. And I think full cycle is beyond that too. So now our testers who are operations we have to have the full skill set we need on our teams to get to the customer. Really.
Dan Neumann: [00:04:53] Yes. That’s interesting to think about there’s the mindset of individuals. You know do they view their role as a specialist in one facet of it. And then there’s the legitimate challenges of do we have the skill set to actually do that. And I’m curious the difference between do we have the skills on the team versus does Eric as a developer on the team have the capability to do all the parts the build the test the deploy et cetera. And is that where we’re going with this?
Eric Landes: [00:05:29] Yes. So I think if you look at the Netflix model, they’re advocating that all developers have the full skill set. I’m gonna say I’m a little different. I don’t totally buy into that. I at least with the clients that I have I would much rather have people have the skill set on the team and maybe we’ll have people who are much better at coding tests, other people better at coding infrastructure and understanding infrastructure. And you know you ex folks but we should all feel comfortable jumping into a different role to help the team out and that’s where I think there’s a mind shift. I think you actually alluded to that earlier you said: Oh I can’t test my own code. Well why not. Let’s explore that and let’s see if that’s really true and let’s see if we can remove impediments. So we really have to start thinking about that in my opinion. What about you Dan? Have you encountered any kind of ways that people can test? Have you seen that positively work? We’ve talked about the negative.
Dan Neumann: [00:06:44] When people are willing to do it, yes I think of a place I was at where we had a person whose specialty was validation QA. But she also learned to automate the tests, right. The code to do it so she went outside of the the manual testing role so that’s that’s a start. I think one of the things that jumped out to me, and we’ll link to that to the Netflix blog post that you are alluding to, one of the things that jumped out to me though is the duration of time it takes whether we’re talking about an agile transformation or whether we’re talking about a team of specialists moving to a team of specializing generalists. That journey takes a very long time and I think that’s something that is underappreciated and where it’s like people think oh I have to be a full stack developer today or tomorrow. It’s a very long journey.
Eric Landes: [00:07:44] Oh yeah. That I totally agree with. And where organizations can help out with that is to understand it’s a long journey. And I put some structure in there to help their teams get there. So you know at AgileThought, one of the things we do is is community practice. So maybe you can start a community of practice around DevOps or community practice around testing and help with some education. People can start learning these new ways of doing things so that they can help get to that end state and again I think the organization needs to probably make clear what that end state is if we want to do full cycle developer, here’s the end state. We need people with a skill set and here’s how we’re gonna help you get there. So if you’re a leader you want to show that way and really help out with these kinds of structures that can help your teams out. So that’s really some of the things I’ve seen. Especially on the testing side. You know we haven’t you know getting full cycle developer, that’s a pretty new concept from my perspective. So seeing teams get to that is gonna be exciting to me to see them do that.
Dan Neumann: [00:09:11] Yeah I want to amplify a couple of things you touched on. What is leadership’s role in this making the desired end state known or that vision. It’s important. Again agile journey or a journey with a team. And then you alluded to communities of practice which will link back to the previous episode. We talked with Quincy Jordan one of our colleagues about communities of practice and the value there. And one of the misnomers can be that if it’s a DevOps community a practice that only DevOps people should go, it’s really for anybody interested in DevOps. Similar if it’s about testing or deployment or if you’re doing coding or intentional practice, that’s for anybody interested.
Eric Landes: [00:09:57] Yeah absolutely.
Dan Neumann: [00:09:59] Yeah setting up those structures and then there’s the long journey part. The other thing that comes to mind is you know what diesel has been doing a lot of talk on the conference circuit about mob programming really moving beyond individuals or pairs to a whole team doing some programming activities and I could see that being critical.
Eric Landes: [00:10:21] That’s interesting. I’ve read about that we have not tried that anywhere. Have you tried that at home in any success?
Dan Neumann: [00:10:31] My challenge with that concept is as much as pair programming makes people’s heads explode if they’re used to an efficiency mindset. The thought of having an entire team and one keyboard is just been a non-starter. Yet because you’ve got these people that their perspective is well shoot what’s everybody going to do. You know it’s like they need to be swinging a hammer if they’re going to be doing something productive as opposed to it’s knowledge work. We have a complicated problem. Most of the efforts in thinking not just pounding out lines of code with keyboards…
Eric Landes: [00:11:09] Paying these people big bucks and wanted to sit there and watch you program. I mean I get that it’s a bit of a stretch. Yeah and I’m paying you how much as a consultant right. I mean and you suggested this.
Dan Neumann: [00:11:25] It takes a very special culture I think to make that work and some organizations are there, others aren’t. And some may never get there.
Eric Landes: [00:11:35] Right, now I will circle back. You know I just was playing the part of the skeptical leader. But to answer that you know one of the things I come back to is on pair programming. There are demonstrated effectiveness there. It’s actually you know I think there’s a University of Michigan study which I know that pains you for me to say that. As a Michigan state alumn, but it’s still valid. They came back and talked about how there was a lot less rework with poor programming. There’s actually a lot more work going on because I have somebody sitting beside me and they can’t see me going to Facebook you know I’m not going to go to Facebook or whatever. You know I might let my mind wander whatever happens while I’m coding on my own. A lot more focus I guess is what happens in there. And I think what you’re advocating is not that we only code in a mob sense but it would be a great way to learn something like DevOps. So, oh hey, we’re gonna code infrastructure. I’ve never done that. Let’s do a mob programming session and let’s see how that works. And now we have some knowledge transfer doing something that’s actually valuable and while we’re doing that the coder actually gets some feedback on: hey he didn’t do that right. And they may catch issues before we actually are testing it in an environment or whatever. So I think there’s a lot of benefit to it. It’s just like he’s at heart so.
Dan Neumann: [00:13:34] Yes. And just thinking through it. We could let the team self organize around that if there is a team that thinks doing a mob for an hour a week is demonstrating value. That’s cool. There’s a team that can demonstrate value by doing it all the time. Party on, good for them. You know it’s I think we get into these, not you and me, but organizationally or as a technology industry, we get into this what’s the best practice is mobbing the best or not you know mobbing by the awesome for one group and it might be horrible for another one. It depends so much on the context and that actually makes me wonder does full cycle developer make sense in some contexts and not others.
Eric Landes: [00:14:18] Great. Great point, Dan. Actually at the conference I was just at, that was one of the points to make and is hey we’ve got multiple teams and I’m forgetting who the other one is. I think it’s maybe Target and they were saying Target doesn’t use full cycle developers and Netflix does and that works awesome for them all right. Their culture supports it. Target has a little bit more of a, and I think its Target I could be saying the wrong team so I apologize if that’s the wrong company, but this company is very successful and they have more of a shared services model and so you know we would have and I’m not a big fan of a DevOps team but they maybe have a team of networking experts and they will come on to a feature team when needed as needed and that kind of thing. So they’re setting in structures but I think one of the takeaways I get from this is you need teams. You need some ways to support the developers. So even in full cycle developer there’s actually platform teams. So on Netflix they needed a better release tool and so they built it. They had a platform team they invested in. They build it. That team disbanded but it was actually like a feature team. They’re just building an internal tool and of course Netflix open sourced to them. But you know the idea is there are lots of different models and even within Netflix while they have full cycle developer that doesn’t mean everybody is working on features constantly. Right. So yes this a long way to say, yeah, definitely different models for different organizations whatever works but to me the big thing is experiment, right. Experiment with what works with measure.
Dan Neumann: [00:16:15] One way to start is what’s the problem you’re trying to solve. So if it is responsiveness I’ve seen places where there’s been a DevOps team that’s separate from the developers and they’ve really struggled to be responsive. So the DevOps team isn’t able to do a deployment rapidly. So in that situation it makes sense to find a way to move that ability to deploy back down into the team because the responsiveness is missing. If they can have a DevOps organization that is super responsive and turning stuff around and trouble shoots together then maybe there’s less motivation to move that internal to the team.
Eric Landes: [00:17:00] Yeah and I would even say let’s talk about what you’re measuring right. So what’s your value. What are you measuring. And let’s use that to help drive improvement. So if I’m measuring how fast I get out to the customer let’s measure those metrics let’s try some experiments and let’s get that out that learning to the teams and let’s adjust when we need to. You know one of the things this is a little different but if you look up DevOps habits and practices Sam Guggenheimer from Microsoft he lays out some habits. One of them I really like which is are you hypothesis driven development. And are you monitoring that and production so bringing it back in the full cycle developer, you need to make sure you’re monitoring things in production so you can give feedback to the team of what’s working what’s not. You know certainly we’re monitoring for errors and those kinds of things but we’re also giving feedback to product owners and those types of folks to say hey these features are working. Customers like them. So that’s one thing I think this full cycle developer brings to the table is now we can give you some real feedback on who’s using what. And you know the data’s always good right.
Dan Neumann: [00:18:35] Definitely. Yeah. We’ve got Adam Ulery, he’s going to be recording a podcast in the very near future with me about an experimental mindset. And so this hypothesis driven development which we’ll link to that as well for this show that ties in really well. So many organizations are just doing opinion driven development. You’ve got a product owner or Big Boss and they decide this is what we’re going to do. Well a lot of times there isn’t the data to back up why they want to do that and even less frequently is there actually a measurement of did they get the result they want? So instead of having it’s good or it’s bad if you get the result having a hypothesis that you can either validate or invalidate either way you learn something and there’s some value there. Definitely like that hypothesis driven development mindset or the experimental mindset that we’ll dive deeper into on a different episode.
Eric Landes: [00:19:32] Yeah. Just to echo on that I’m not advocating that we just blindly follow numbers. You know I don’t think Steve Jobs would have ever created you know the iPod and all that fun stuff if you he had done that. But what I am advocating is let’s not blindly do these things let’s do it with some actual data because too many times we’re just saying yes the customer wants that. Oh well how do you know that. And so this is a way to bring that into the development cycle.
Dan Neumann: [00:20:05] Agreed agreed. So we’ve touched on the fact that there’s definitely a mindset component, a pretty significant mindset component to approaching full cycle developer. There are lots of skills that will need to be built over time and measuring the impact of heading down these roads for folks looking to get started on this full cycle developer journey, Eric, where would you see the most value in starting.
Eric Landes: [00:20:36] Sure. Well I’m assuming they will be doing Agile if you’re not doing that, we want to start with agile principles. Certainly XP principles if you’ve not looked at what our XP there’s 12 practices in XP you certainly want to look at that because to become a full cycle developer we want to be coding well and we want to do that in the rest of our code. So we want to start from you know everything’s code now, in my opinion it’s moving that way and that’s what full cycle developers about. Obviously the Netflix blog you’ll want to read that and see how they’re doing that. I would recommend you know any of the DevOps practices if you’re looking to understand DevOps practices for your full cycle developer. There’s some good edx courses that you could take. And again communities of practice are a good thing to start in your company to help people understand that. Dan you mentioned coding katas. I think those are something you’re committed practice could do and we can put some links to some of these resources in there and all those things are good things to do. And again experiment, you know and see if it works for you is my biggest admonition or what I would say I hopefully you can take away from that.
Dan Neumann: [00:22:12] Definitely. And I like that you started with the principles because one can put in a bunch of practices and if you don’t have the mindset and you don’t really embrace the principles you can do the activities all day long and not get any results from them.
Eric Landes: [00:22:29] And that’s where we see lot of you know we get the scrum movement right. Yes we’re doing stand ups and all that stuff. Well understand the principles. Agile has some principles and there are some reasons behind that.
Dan Neumann: [00:22:42] Definitely. Well that’ll be a fun topic perhaps for another day. So with the principle of continuous learning in mind, what are you reading these days or what have you read recently that’s kind of impacted how you see things or do things.
Eric Landes: [00:22:55] So I’ve read the book Turn the Ship Around by David Marquet recently. Anyway I got a lot of good leadership information out of that. I mean when I think about it, the book is about how he turned a U.S. It’s a nuclear sub, so I mean it’s it’s a military book for sure but it’s not really about the military it’s about how you turn a large organization and make it more responsive. And as someone who’s more of a mid-level manager I would say then he was not the admiral at that point. I think it was like a captain and very interesting how he learned and how it affected the Navy overall. You know years after. I mean just some amazing stuff there. So if you’re looking to be transformational I think there’s some really good lessons there. The other book I’m reading, Have you read that book by the way?
Dan Neumann: [00:24:03] I did read turn the ship around and I think the one practice that has had a pretty significant impact at AgileThought with the transformed practice has been the intention based leadership. And I know that it’s good that our leader has embraced that because now it’s if we as a practice know what the goal is we can say hey I intend to do you know this and maybe the precautions we’ve taken to make sure it’s not a bad idea. And then you know there’s a chance that the boss will say oh no don’t do that for X Y or Z. But it’s so much easier to get things approved and make decisions make a purchase take an action with that intention based leadership. So I love that part for sure out of that book that became really sticky for us.
Eric Landes: [00:24:51] I agree that’s a great lesson.
Dan Neumann: [00:24:53] Yeah. And then you said there’s something else you are reading too.
Eric Landes: [00:24:57] So I’m reading a two-fer. I’m reading Train From the Back of the Room and I’m forgetting the author. But it’s a great lesson on how training you know we’re now moving from training models and learning models that are an instructor at the front of the room you know espousing knowledge and we’re writing it down and we’re taking that knowledge in. There’s a lot of evidence that that’s not as effective as other methods and Train From the Back of the Room tries to help you engage your classroom so you can use it for classes you could even use it if you’re in, I would say meetings and you want to get engagement. Its ideas around how we engage people in the learning experience so learning happens. So it just does some good stuff there. I would highly recommend it especially if you’re doing any kind of training. It’s good stuff.
Dan Neumann: [00:25:56] I’ll have to add that one to my reading backlog. That’s not one that I’ve consumed. And I do training so always looking for opportunities to continue to increase that. So. Well hey thanks Eric, I appreciate you taking some time out of the regular client stuff today to share some ideas on full cycle developer.
Eric Landes: [00:26:14] Absolutely and thank you Dan. I enjoyed the talk.
Dan Neumann: [00:26:18] Until next time.
Outro: [00:26:20] This has been the Agile Coach’s Corner podcast brought to you by AgileThought. Get the show notes and other helpful tips from this episode and other episodes at agilethought.com/podcast.