Help me be a good team lead / manager
September 14, 2010 9:30 AM Subscribe
I may be accepting a tech lead/manager role, managing a software team which is not yet really Agile. Please recommend books and resources on managing Agile development, and team leadership/management in general. Please give your advice on how I can do this well.
Here is my recommendations, as a 12 year technical project manager/architect who has run all sorts of styles of processes and methodologies. (I've put my 10,000 hours in.)
First, read the Agile Manifesto, so you get a context of what Agile was about, before it became a buzzword.
Then, read through the OpenUP. Study it for a few days, get familiar with the basic concepts. It has pretty much everything essential to run a software project, especially a relatively small team.
That will get you 80% there. Then plan for the next 20% (the details) to take up 80% of your time .
posted by TheOtherSide at 10:26 AM on September 14, 2010 [2 favorites]
First, read the Agile Manifesto, so you get a context of what Agile was about, before it became a buzzword.
Then, read through the OpenUP. Study it for a few days, get familiar with the basic concepts. It has pretty much everything essential to run a software project, especially a relatively small team.
That will get you 80% there. Then plan for the next 20% (the details) to take up 80% of your time .
posted by TheOtherSide at 10:26 AM on September 14, 2010 [2 favorites]
Golden words from mcstayinskool. Don't be that guy who comes into a company fresh and all "OK everybody, things are gonna CHANGE." If you want to make a non-Agile team Agile, spend like 6-12mos doing it. It may take even longer. Point is, your job will be to get the best work out of your people, not to implement whatever you think is the best way to produce software. I guess my question back to you would be, "why do they need to be Agile?"
posted by rhizome at 10:44 AM on September 14, 2010
posted by rhizome at 10:44 AM on September 14, 2010
Get a scrum master certification. It only takes a day or two, and is pretty cheap last time I checked. It covers most of the details on how to get started.
posted by blue_beetle at 11:18 AM on September 14, 2010
posted by blue_beetle at 11:18 AM on September 14, 2010
My 2 cents: As an in-house developer on a small, 3 person team that that operates within a larger IT department, I gotta say that Agile is a pretty damn good system when everyone is on board.
At first I was very distrusting of the Agile process, due to it's glossy sheen of micromanagement. However, I quickly began to see the benefits of this as a process, and have now come full circle and will gladly admit that this is much better than our old way of doing things, which was waterfall + a couple of clumsy layers of micromanagement. Our team is more productive, our management more informed, and our software is better; win, win, win.
In our case, I think the key points that lead to a successful adoption of the Agile process were these:
1. Management was entirely on board.
2. We invested in software to help us implement/manage the Agile system (e.g., Target Process.) This has helped a lot. It was tempting to roll our own management software, but using TP really allowed us to get up to speed with the Agile system a lot faster.
3. As an in-house team we have a backlog of large and small projects, which allows us to put together some very reasonable sprints with good value for our users.
I don't know if the above is helpful from a management perspective, but as a developer my takeaway is this: I've worked in the software industry in a variety of jobs since 1995, and Agile is one of the few management systems I've seen that seems to live up to its hype. It is not a panacea, but when it is implemented properly it really does work better than the alternatives.
posted by mosk at 11:19 AM on September 14, 2010
At first I was very distrusting of the Agile process, due to it's glossy sheen of micromanagement. However, I quickly began to see the benefits of this as a process, and have now come full circle and will gladly admit that this is much better than our old way of doing things, which was waterfall + a couple of clumsy layers of micromanagement. Our team is more productive, our management more informed, and our software is better; win, win, win.
In our case, I think the key points that lead to a successful adoption of the Agile process were these:
1. Management was entirely on board.
2. We invested in software to help us implement/manage the Agile system (e.g., Target Process.) This has helped a lot. It was tempting to roll our own management software, but using TP really allowed us to get up to speed with the Agile system a lot faster.
3. As an in-house team we have a backlog of large and small projects, which allows us to put together some very reasonable sprints with good value for our users.
I don't know if the above is helpful from a management perspective, but as a developer my takeaway is this: I've worked in the software industry in a variety of jobs since 1995, and Agile is one of the few management systems I've seen that seems to live up to its hype. It is not a panacea, but when it is implemented properly it really does work better than the alternatives.
posted by mosk at 11:19 AM on September 14, 2010
I think you should prove yourself before implementing anything. SCRUM is difficult to introduce at the best of times and with lots of trust between people, I think it will be very painful if you just jump in and SCRUM them. Things that you can work on that will help your team: getting a good overview on everything so you have the big picture, helping fend off unnecessary distractions and randomization so they can get lots of work done, listening when they want to tell you things, collecting status often but not too often (don't micromanage and ask for status daily/hourly!), thinking of small improvements that could help them, fighting for a reasonable budget for your team and organizing some small stress-relieving events during working hours (a lunch, a movie etc), keeping them well-informed of any deadlines, and letting them know well in advance when there is something they need to improve. You can also take on some of their tasks when they have too many, and help them with complex tasks <- many bad managers do not do this, and have no idea how to do anything anyone of their team does.
posted by meepmeow at 11:54 AM on September 14, 2010
posted by meepmeow at 11:54 AM on September 14, 2010
Response by poster: I guess my question back to you would be, "why do they need to be Agile?"
They are nominally Agile now, but in a patchwork manner and possibly without (full) buy-in from the team.
I don't want to top-down demand process changes (and I don't think doing so would be effective). I do want to convince the team of Agile's pragmatic usefulness, probably by example, and hope to get buy-in based on that.
And frankly, I don't care if we follow the full Agile process, as long as we can develop a process that fits the team and produces results; I'm no evangelist for any methodology.
But I do see an advantage to Agile, and if the team is going to call itself Agile, I'd like that to as true as practicable. I don't want to do half-Agile and then have the team say "well, this demonstrates that Agile doesn't work for us."
posted by orthogonality at 11:58 AM on September 14, 2010
They are nominally Agile now, but in a patchwork manner and possibly without (full) buy-in from the team.
I don't want to top-down demand process changes (and I don't think doing so would be effective). I do want to convince the team of Agile's pragmatic usefulness, probably by example, and hope to get buy-in based on that.
And frankly, I don't care if we follow the full Agile process, as long as we can develop a process that fits the team and produces results; I'm no evangelist for any methodology.
But I do see an advantage to Agile, and if the team is going to call itself Agile, I'd like that to as true as practicable. I don't want to do half-Agile and then have the team say "well, this demonstrates that Agile doesn't work for us."
posted by orthogonality at 11:58 AM on September 14, 2010
Hmm...transforming an "agile" team into an actually agile team. It's a challenge, but a fun one, I think. As others have mentioned, the big warning when you talk about agile is keeping true to the philosophy, instead of the buzzword. But also, general management warning: pay attention to your people and how they react, and do these things to solve problems. So, if semi-agile is working out, then that's good. But if you think adding in some new practices can help improve quality, or release things on time, or make it all more fun, then you can find a use for it. Don't force agile practices on them just because they're calling themselves agile.
In terms of books and resources, I'm still torn on what the best agile-overview book is, so I'll give you an overview of some of the "classics" that I've read (in the order I read them)
1. Kent Beck's Extreme Programming Explained is a great for the mindset. XP is pretty cool as well, but don't focus on processes too much. Mindset! Beck is an awesome writer, and I love the examples in the book as well the explanation of how each piece fits in the whole, and how it helps make things happen in a way ad-hoc can't, but without the oppressiveness of "the items on the right"
2. Schwaber and Beedle's Software Development with Scrum is probably the best one on the management mindset. The idea of this scrum master who fields for the team is great, and describes someone I'd love to have as my manager. One of the annoying things about the book is that they try to portray Scrum as "The One True Software Project Management Way," and disprove all other ways - don't be completely taken in. Everything has its place.
3. Poppendiek and Poppendieck's Lean Software Development: An Agile Toolkit presents a bunch of ideas largely derived from lean manufacturing methods. You can choose what's applicable yourself. There isn't the focus on meshing it all into a cohesive whole that XP Explained has, and there's even more "This Is How It Should Be Done" than the Scrum book. Again, take it with a grain of salt (and remember that Toyota is not perfect). I found it good food for thought, though.
From my own experience, some more advice: the team needs to own the process. You can ask people to go by-the-book for a while, and it's often useful to understand how it works when you're starting, but the team needs to be able to change things to make it work for them. This is one of the big lessons of the Lean book I mentioned above: the people on the front lines know the best about how to improve their work - leverage that! And also, do retrospectives. This is a great way to feed into improving your own process: at the end of the iteration, make sure you go over how it went. Did people like it? What worked? What can we do better next time? How's the team working together? There's a few resources online for this, but I don't know any well enough to point you to them.
For general management resources, my manager swears by Manager Tools, a weekly podcast about management, with a focus on giving you something you can take to work and use in the next week. I'm not sure how it is picking up in the middle (I'm starting at the beginning). They are big fans of weekly one-on-ones with each of your reports, and I have to agree: it's amazing, and one of the things I look for from a good manager.
The OpenUP documentation TheOtherSide linked to is a goldmine of software engineering knowledge. I personally found it hard to grok it all and see the exact methodology that they advocate (I did a small project with OpenUP, and in the end, my team had a radically different process than each of two other teams that were also "doing OpenUP") It's a wonderful resource, though, and worth reading.
posted by ADoubtfulTrout at 9:00 PM on September 14, 2010 [1 favorite]
In terms of books and resources, I'm still torn on what the best agile-overview book is, so I'll give you an overview of some of the "classics" that I've read (in the order I read them)
1. Kent Beck's Extreme Programming Explained is a great for the mindset. XP is pretty cool as well, but don't focus on processes too much. Mindset! Beck is an awesome writer, and I love the examples in the book as well the explanation of how each piece fits in the whole, and how it helps make things happen in a way ad-hoc can't, but without the oppressiveness of "the items on the right"
2. Schwaber and Beedle's Software Development with Scrum is probably the best one on the management mindset. The idea of this scrum master who fields for the team is great, and describes someone I'd love to have as my manager. One of the annoying things about the book is that they try to portray Scrum as "The One True Software Project Management Way," and disprove all other ways - don't be completely taken in. Everything has its place.
3. Poppendiek and Poppendieck's Lean Software Development: An Agile Toolkit presents a bunch of ideas largely derived from lean manufacturing methods. You can choose what's applicable yourself. There isn't the focus on meshing it all into a cohesive whole that XP Explained has, and there's even more "This Is How It Should Be Done" than the Scrum book. Again, take it with a grain of salt (and remember that Toyota is not perfect). I found it good food for thought, though.
From my own experience, some more advice: the team needs to own the process. You can ask people to go by-the-book for a while, and it's often useful to understand how it works when you're starting, but the team needs to be able to change things to make it work for them. This is one of the big lessons of the Lean book I mentioned above: the people on the front lines know the best about how to improve their work - leverage that! And also, do retrospectives. This is a great way to feed into improving your own process: at the end of the iteration, make sure you go over how it went. Did people like it? What worked? What can we do better next time? How's the team working together? There's a few resources online for this, but I don't know any well enough to point you to them.
For general management resources, my manager swears by Manager Tools, a weekly podcast about management, with a focus on giving you something you can take to work and use in the next week. I'm not sure how it is picking up in the middle (I'm starting at the beginning). They are big fans of weekly one-on-ones with each of your reports, and I have to agree: it's amazing, and one of the things I look for from a good manager.
The OpenUP documentation TheOtherSide linked to is a goldmine of software engineering knowledge. I personally found it hard to grok it all and see the exact methodology that they advocate (I did a small project with OpenUP, and in the end, my team had a radically different process than each of two other teams that were also "doing OpenUP") It's a wonderful resource, though, and worth reading.
posted by ADoubtfulTrout at 9:00 PM on September 14, 2010 [1 favorite]
This thread is closed to new comments.
Agile has lots of great things going for it, and certainly the waterfall approach seems like a dinosaur next to it, but stand up meetings and scrums and sprints will feel like different ways of accomplishing employee micro management to workers new to this.
posted by mcstayinskool at 10:15 AM on September 14, 2010