High Performing Software Teams
February 11, 2015 5:58 AM
Awesome software engineering managers, what has made you successful? I am working with a Dev manager and my gut tells me our process is broken and teams are not working to their potential. The current manager is spouting the benefits of Kanban and has removed any of the normal Agile stuff ( storypoints, retros, sprints ). Last quarter they completely missed on the Roadmap and the team seems disengaged. Leadership is scared to lose talent and is coddling our engineering team. Help me instill a lightweight process and culture than gets results and keeps people happy. What is working for you?
Talk to the team. Be honest, "The current process isn't working, last quarter you missed on Roadmap completely. We value you and want you to work at full potential. We need a process. So Agile, Kanban, Waterfall or whatever, what do you think the best way to do this is?"
Be prepared for a bitch session, acknowledge the frustration, and keep bringing it back to process. It doesn't mater which one, what matters is that there IS one, and that folks are using it.
Your Dev manager needs a come to Jesus meeting. If you're equals, then you need a higher level person to deliver the message, which is, "your lack of process is causing problems. The team is disengaged and we're concerned that we're going to lose talent. What you're doing isn't working. Change it."
Because this is a leadership problem, not a process problem.
posted by Ruthless Bunny at 6:31 AM on February 11, 2015
Be prepared for a bitch session, acknowledge the frustration, and keep bringing it back to process. It doesn't mater which one, what matters is that there IS one, and that folks are using it.
Your Dev manager needs a come to Jesus meeting. If you're equals, then you need a higher level person to deliver the message, which is, "your lack of process is causing problems. The team is disengaged and we're concerned that we're going to lose talent. What you're doing isn't working. Change it."
Because this is a leadership problem, not a process problem.
posted by Ruthless Bunny at 6:31 AM on February 11, 2015
What works for me is finding an awesome manager and glomming on to their coattails. Benevolent dictators are where it's at. Processes... not so much. Sounds like you got an effective leadership problem, not a kanban vs scrum problem.
(Quarterly roadmap plus Scrum? You don't see some tension there?)
posted by Leon at 6:39 AM on February 11, 2015
(Quarterly roadmap plus Scrum? You don't see some tension there?)
posted by Leon at 6:39 AM on February 11, 2015
This is a leadership, culture, and/or communication problem, not a process problem. You can scrum until you are blue in the face but if the team does not know the roadmap, works for a failing company, uses antiquated hardware, has a bully, or is not connected to customers, it won't help. You need a solution that matches a problem.
You don't say who you are or what your role is. In my experience, it doesn't matter who you are, you don't change the way the engineering team operates without the development manager's full buy in, cooperation, and approval. You need to get busy fixing your relationship with this person. Simply implementing change is a career limiting move on your part.
posted by crazycanuck at 6:42 AM on February 11, 2015
You don't say who you are or what your role is. In my experience, it doesn't matter who you are, you don't change the way the engineering team operates without the development manager's full buy in, cooperation, and approval. You need to get busy fixing your relationship with this person. Simply implementing change is a career limiting move on your part.
posted by crazycanuck at 6:42 AM on February 11, 2015
nthing Ruthless Bunny.
I've worked with brilliant engineering managers — three of the best managers I've ever had were all at my last company — and I've worked as one myself. The thing I've learned is that ultimately when there's developer disengagement it's not something that can be fixed with a silver bullet of process. The only way you're going to thrash this out is to understand the underlying cause, otherwise you're trying to treat the symptoms, not the illness.
posted by gmb at 7:04 AM on February 11, 2015
I've worked with brilliant engineering managers — three of the best managers I've ever had were all at my last company — and I've worked as one myself. The thing I've learned is that ultimately when there's developer disengagement it's not something that can be fixed with a silver bullet of process. The only way you're going to thrash this out is to understand the underlying cause, otherwise you're trying to treat the symptoms, not the illness.
posted by gmb at 7:04 AM on February 11, 2015
Awesome software engineering managers, what has made you successful?
I'm not an awesome software engineering manager, but I've worked with a few.
The most awesome managers appear to do very little. That's because what they've been doing is finding out what their people are really good at, or potentially really good at, and giving them that to do; and the little they do do mainly involves sheltering their team from the inevitable rain of bullshit from above.
I never once worked with a manager who attempted to impose culture from above and was successful at it.
Awesome managers hire new people on the basis of how well they can work with the people already there, who are all competent because awesome managers do not hire drones; and then they do their level best to get out of the way and let the team do what it does.
New hires are not expected to be competent immediately. Awesome managers understand that this is impossible and that getting up to speed takes time.
Awesome managers make a point of regularly hiring completely green staff with no domain knowledge whatsoever, but when they do that, they hire people who they're pretty sure will benefit from competent mentoring and then they give them that.
Awesome managers' projects do not always come in on time and under budget. But when they don't, it's because the initial time and budget estimates were wildly overoptimistic. And the awesome manager reacts to that not by panicking and hiring sixty-seven more devs and an offshore team, but by pushing back against the estimates and renegotiating them.
posted by flabdablet at 7:21 AM on February 11, 2015
I'm not an awesome software engineering manager, but I've worked with a few.
The most awesome managers appear to do very little. That's because what they've been doing is finding out what their people are really good at, or potentially really good at, and giving them that to do; and the little they do do mainly involves sheltering their team from the inevitable rain of bullshit from above.
I never once worked with a manager who attempted to impose culture from above and was successful at it.
Awesome managers hire new people on the basis of how well they can work with the people already there, who are all competent because awesome managers do not hire drones; and then they do their level best to get out of the way and let the team do what it does.
New hires are not expected to be competent immediately. Awesome managers understand that this is impossible and that getting up to speed takes time.
Awesome managers make a point of regularly hiring completely green staff with no domain knowledge whatsoever, but when they do that, they hire people who they're pretty sure will benefit from competent mentoring and then they give them that.
Awesome managers' projects do not always come in on time and under budget. But when they don't, it's because the initial time and budget estimates were wildly overoptimistic. And the awesome manager reacts to that not by panicking and hiring sixty-seven more devs and an offshore team, but by pushing back against the estimates and renegotiating them.
posted by flabdablet at 7:21 AM on February 11, 2015
Gotta slightly disagree .. If you're on some revolving door of trying to fix [stuff], you get this. Lotsa truth in there.
posted by k5.user at 7:25 AM on February 11, 2015
posted by k5.user at 7:25 AM on February 11, 2015
The thing that process will give you is visibility into what's going on - so if you're going to miss your roadmap, you'll know early enough to (a) give management a heads up and (b) re-align priorities so the most important things get done first. It does not make the team suddenly able to get more done, paradoxically any process adds some overhead which makes the team less efficient, if you measure total output. What it does do is let you apply the effort where it does the most good.
And in my experience, adding process does not help motivate an unmotivated team.
posted by mr vino at 7:28 AM on February 11, 2015
And in my experience, adding process does not help motivate an unmotivated team.
posted by mr vino at 7:28 AM on February 11, 2015
I'm gonna come at this from the other side: I'm a software engineer currently on a very high-performing team, and I've been on some not so high performing teams in the past. It worries me that you make no mention of communicating in any way with your devs or seeking their input at all. What little you do mention your team they come off as an obstacle to be surmounted rather than stakeholders to be worked with, and that kind of outlook will kill you dead. Ruthless Bunny is right, but I'd like to go in to a little more detail as to why:
A. Software engineers tend to hate process. Hate hate hate it. They see it (often unfairly) as "cost of doing business" at best and "worthless, velocity-ruining bullshit managers throw together to feel important" at worst. This is doubly true if their process keeps changing - it fosters resentment, both due to the perceived slowdown that happens since the process stops being something that fades in to the background and becomes a focus itself, and because the fact that one process failed is seen as proof that the whole thing is bullshit.
B. Every team is different and every circumstance is different, and so any process needs to be tailored to fit the particulars of the situation. Good managers will do this, but for every great manager who deeply considered what aspects of Kanban work with his or her team and modified accordingly before implementing it, there are a dozen garbage managers who read the Agile Manifesto, stormed in to an office, and said "This is what we're doing because it's a Best Practice (tm)". This then further exacerbates problem A, since engineers who work on teams where this happens walk away thinking that process is useless trash.
Luckily, there is a solution to both of these: Talk. To. Your. Team. Any single kind of process that you want to implement, you should be making it clear how it benefits your team, what alternatives you're considering, and why you're leaning towards this one (and they should be real reasons appropriate to your situation, not "because this is what the books say will work"). Then you need to be willing to listen to feedback and - and here's the rub - incorporate it. That's not to say that your engineers should be 100% in charge of planning your process (down that route lies madness) but they should be part of the planning and feel like owners. That both ensures you'll overcome problem A and get buy-in and help avoid problem B by making sure your process fits your situation.
To go back to your original question of "what worked", right now my team uses a fairly lightweight system that involves a spreadsheet for task planning that's auto-populated by our bug tracker and maintained with some simple scripts. We love it, but it works well because we were involved in figuring out a system that worked for our team and the work we do, and every single one of us recognizes how and why what we have now works better than any alternative (including, critically, the "no process" alternative).
posted by Itaxpica at 7:36 AM on February 11, 2015
A. Software engineers tend to hate process. Hate hate hate it. They see it (often unfairly) as "cost of doing business" at best and "worthless, velocity-ruining bullshit managers throw together to feel important" at worst. This is doubly true if their process keeps changing - it fosters resentment, both due to the perceived slowdown that happens since the process stops being something that fades in to the background and becomes a focus itself, and because the fact that one process failed is seen as proof that the whole thing is bullshit.
B. Every team is different and every circumstance is different, and so any process needs to be tailored to fit the particulars of the situation. Good managers will do this, but for every great manager who deeply considered what aspects of Kanban work with his or her team and modified accordingly before implementing it, there are a dozen garbage managers who read the Agile Manifesto, stormed in to an office, and said "This is what we're doing because it's a Best Practice (tm)". This then further exacerbates problem A, since engineers who work on teams where this happens walk away thinking that process is useless trash.
Luckily, there is a solution to both of these: Talk. To. Your. Team. Any single kind of process that you want to implement, you should be making it clear how it benefits your team, what alternatives you're considering, and why you're leaning towards this one (and they should be real reasons appropriate to your situation, not "because this is what the books say will work"). Then you need to be willing to listen to feedback and - and here's the rub - incorporate it. That's not to say that your engineers should be 100% in charge of planning your process (down that route lies madness) but they should be part of the planning and feel like owners. That both ensures you'll overcome problem A and get buy-in and help avoid problem B by making sure your process fits your situation.
To go back to your original question of "what worked", right now my team uses a fairly lightweight system that involves a spreadsheet for task planning that's auto-populated by our bug tracker and maintained with some simple scripts. We love it, but it works well because we were involved in figuring out a system that worked for our team and the work we do, and every single one of us recognizes how and why what we have now works better than any alternative (including, critically, the "no process" alternative).
posted by Itaxpica at 7:36 AM on February 11, 2015
As a development manager, Scrum guy, and also as a hands-on developer, I suspect the problem is a combination of the manager and maybe a poor implementation of the old and or new process. You mention him ditching Agile stuff and touting Kanban, but Scrum and Kanban are both under the parent umbrella of "Agile methodologies", as are things like XP practices. Scrum done right is tremendously empowering and fun for the developers. Usually when I hear things like "we did Agile at my last company and everyone hated it" it means there was a haphazard, confused or overly top-down implementation.
I agree with the comment about asking the team what they think is going on. Sprint retrospectives for example are a great place to hear about why things aren't working, so it's suspicious that the manager stopped doing them. Maybe the team was saying things he didn't want to hear.
Not sure on second reading if the old process was Scrum or just some generic "agile" grab-bag, but here are a few simple things I'd ask to check the health of the process:
1) Are people working much more than 45-50 hours a week?
2) Are the rough (story point) and detailed (sprint planning) estimates and commitments being made by the team?
3) Is there a clear product owner who owns the prioritized list of stuff to do? Does that person have good rapport with customers, sales etc.? Does that person respect the team's feedback about difficulty/scoping of items?
4) Is there a scrum master or some other person who is protecting the team from interruptions and "thrashing" type change?
5) Are the people on the team also on other teams, or doing a bunch of other work? Production support is a common one and is a big no-no.
6) Does the team have some good tools in place to help them be agile? Build server, source control, test environment, etc.
7) As mentioned above, is the product road map in alignment with the work queue/backlog, and is it realistic? Does the product owner know how to say no? Once clients start getting new features quickly and regularly, as is possible with agile methods, some of the obsession with unrealistic dates a year in the future tends to go away.
Best of luck! Trust what the team tells you, and don't pull punches with the manager if he's obviously an obstacle.
posted by freecellwizard at 7:48 AM on February 11, 2015
I agree with the comment about asking the team what they think is going on. Sprint retrospectives for example are a great place to hear about why things aren't working, so it's suspicious that the manager stopped doing them. Maybe the team was saying things he didn't want to hear.
Not sure on second reading if the old process was Scrum or just some generic "agile" grab-bag, but here are a few simple things I'd ask to check the health of the process:
1) Are people working much more than 45-50 hours a week?
2) Are the rough (story point) and detailed (sprint planning) estimates and commitments being made by the team?
3) Is there a clear product owner who owns the prioritized list of stuff to do? Does that person have good rapport with customers, sales etc.? Does that person respect the team's feedback about difficulty/scoping of items?
4) Is there a scrum master or some other person who is protecting the team from interruptions and "thrashing" type change?
5) Are the people on the team also on other teams, or doing a bunch of other work? Production support is a common one and is a big no-no.
6) Does the team have some good tools in place to help them be agile? Build server, source control, test environment, etc.
7) As mentioned above, is the product road map in alignment with the work queue/backlog, and is it realistic? Does the product owner know how to say no? Once clients start getting new features quickly and regularly, as is possible with agile methods, some of the obsession with unrealistic dates a year in the future tends to go away.
Best of luck! Trust what the team tells you, and don't pull punches with the manager if he's obviously an obstacle.
posted by freecellwizard at 7:48 AM on February 11, 2015
I'm a software engineer, currently on a horribly under-performing gaggle. It's driving me nuts.
The best team I've ever worked on had once or twice a week meetings in which our manager (who was not our technical lead, and in fact not very technical at all) did the "What are you working on? What are your future tasks? How long do you think it will take to do each of those tasks? How far off your estimate are you on your current task? What are your blockers?" thing.
Our technical lead locked himself in his office and sent out documentation occasionally. This was actually good, because the vision for the overall architecture was very clear (even if in practice the mock-ups we built to test our software were what ended up going into production, rather than the stuff he was supposed to be building).
Our manager was awesome at running interference and keeping the information flowing to keep us from getting blocked. That we knew what we all were working with at least a week down the pike mean that there were no interruptions or unanticipated context switches, and even though she wasn't technical, she could deflect questions.
I've done a more formal Agile-ish thing as well, and it was okay, but having someone who knew the business goals and user stories, who wasn't technical but was an awesome facilitator, was really nice. It's too bad I didn't like the rest of the company direction, because I'd work for her again in a heartbeat.
My current gig has constant interruptions and re-directing, we have no distribution of knowledge, massive legacy systems, and a "fuck it, just ship it" attitude. I'm looking.
posted by straw at 10:18 AM on February 11, 2015
The best team I've ever worked on had once or twice a week meetings in which our manager (who was not our technical lead, and in fact not very technical at all) did the "What are you working on? What are your future tasks? How long do you think it will take to do each of those tasks? How far off your estimate are you on your current task? What are your blockers?" thing.
Our technical lead locked himself in his office and sent out documentation occasionally. This was actually good, because the vision for the overall architecture was very clear (even if in practice the mock-ups we built to test our software were what ended up going into production, rather than the stuff he was supposed to be building).
Our manager was awesome at running interference and keeping the information flowing to keep us from getting blocked. That we knew what we all were working with at least a week down the pike mean that there were no interruptions or unanticipated context switches, and even though she wasn't technical, she could deflect questions.
I've done a more formal Agile-ish thing as well, and it was okay, but having someone who knew the business goals and user stories, who wasn't technical but was an awesome facilitator, was really nice. It's too bad I didn't like the rest of the company direction, because I'd work for her again in a heartbeat.
My current gig has constant interruptions and re-directing, we have no distribution of knowledge, massive legacy systems, and a "fuck it, just ship it" attitude. I'm looking.
posted by straw at 10:18 AM on February 11, 2015
I find it interesting that the only measure of failure that you indicate is missing the roadmap. Is the roadmap mandated from above? Was it collaboratively created by the team? The conclusions to be drawn from this would be on the opposite ends of the spectrum. People withdraw and become apathetic if they know they can't be anywhere close to their targets. However if the team created the roadmap than there may be other factors at play.
posted by aeighty at 10:23 AM on February 11, 2015
posted by aeighty at 10:23 AM on February 11, 2015
The biggest thing you can do to make a programmer effective is to remove the obstacles to performance that the company places in his or her way. Bad lifecycle management is itself an obstacle, and if the developer suffers from micro- or macro-level burnout due to problematic project management, that developer won't be effective. Micro-level burnout would be "I'm tired of working on this module or function because ___" (nobody listens to me, the code is crufty and needs to be refactored, there's too much technical debt, I lost the argument about how to implement this feature, and so on). No amount of standups and coffee is going to resolve micro-level burnout, but addressing the actual issues might. Macro-level burnout would be whiplash from "we were scrum and that didn't work, so now we're kanban, and it still doesn't work." This is especially likely if the developers have been trying to send feedback up the chain and have no evidence their feedback has been both heard and acted on. One common problem is that upper management will acknowledge the complaints of developers but then never follow through ("we hear you but there's no budget," or "we hear you but we still need you to fix these six urgent problems first" would be two examples, but "you're exactly right and we'll work on that problem" followed by crickets is the worst).
If you're missing targets on the roadmap, the first thing is to find out why, and you need to find out at both the micro and macro levels. It is probably a combination of both sorts of problems, and you'd need to address the issues separately. I hesitate to say you should call a meeting (gripe session) but one-on-one feedback is really necessary here to identify problems and target them.
As for the particulars of scrum vs kanban there's no inherent problem with either of them per se when the management overhead isn't too bad, but switching between them indicates that there's a disconnect between what your developers expect to be doing and what your management expects from them. Think less about imposing a methodology and more about listening to the developers to find out what works, what doesn't, and what they've been complaining about that has gone unheard.
posted by fedward at 10:49 AM on February 11, 2015
If you're missing targets on the roadmap, the first thing is to find out why, and you need to find out at both the micro and macro levels. It is probably a combination of both sorts of problems, and you'd need to address the issues separately. I hesitate to say you should call a meeting (gripe session) but one-on-one feedback is really necessary here to identify problems and target them.
As for the particulars of scrum vs kanban there's no inherent problem with either of them per se when the management overhead isn't too bad, but switching between them indicates that there's a disconnect between what your developers expect to be doing and what your management expects from them. Think less about imposing a methodology and more about listening to the developers to find out what works, what doesn't, and what they've been complaining about that has gone unheard.
posted by fedward at 10:49 AM on February 11, 2015
This thread is closed to new comments.
Have they moved from Scrum to Kanban? If so, do you have data on how the sprints were going, and whether they were making good progress but against an unrealistic or unclear roadmap, or if there were signs of problems before (sprints drifting maybe, or unclear sprint goals, no demos, etc)? Are they just changing because the Scrum process was making the actual problems visible, and they want to hide those issues rather than try to work them out?
Or are they coming into Agile cold and going straight to Kanban? Could you sell them on the virtues of Scrum and try to use that to help the team diagnose the problems? No process is a magic bullet, but if the manager and the team use the process to expose problems (which can be "we are being asked to do the impossible and we are disengaged for that reason") rather than fix blame, then it can improve engagement over time as long there's a perception that things are going incrementally in the right direction.
posted by crocomancer at 6:17 AM on February 11, 2015