I've spent almost 10 years doing software development as a dev, and I've had a mix of good management and bad management, and I have the opportunity to begin growing my team and adding additional developers.<p>I'd like to get my head around what software project management is at it's most basic level. Are there any recommended books on the subject or articles that have a good 101 kind of explanation?<p>Based on what I understand from my own experience, this is roughly the process:
- Have a clear direction for the team to be moving in, and communicate that objective to each of the team members clearly
- Provide the team with the tools and resources they need to do their jobs
- Provide feedback to the team members periodically if we are going in the right direction<p>I know all about agile and scrum, waterfall, etc. But those things seem to be a little further down the line than what I'm trying to get a grasp of.<p>Thanks!
If I only had one suggestion it would be:
<a href="http://en.wikipedia.org/wiki/The_Mythical_Man-Month" rel="nofollow">http://en.wikipedia.org/wiki/The_Mythical_Man-Month</a><p>That book should be required reading for anyone on either side of the commonly asked question, "How do we build this?"<p>Maybe a second - it's a bit old (and almost 1000 pages) - but much of McConnell's CodeComplete2 still applies and has lots of great insights for software PM's: <a href="http://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670" rel="nofollow">http://www.amazon.com/Code-Complete-Practical-Handbook-Const...</a><p>[edit grammer]
Everyone is going to give you a bunch of tips on software processes. If you've been doing this for 10 years, you know all of it already. You've been around the block, you've seen what works, and what doesn't.<p>The real new thing here, is you're now going from a position of independence to interdependence. That's a step up in responsibility, but its difficult. The thing to master are your "people" skills. The hardest thing for me to master the first time I made the step was that different people do things differently... and that's okay.<p>To keep things short, just read this (or get the audible book) <a href="http://www.amazon.com/How-Win-Friends-Influence-People/dp/1508569754" rel="nofollow">http://www.amazon.com/How-Win-Friends-Influence-People/dp/15...</a><p>Seriously, it makes such a huge deal, knowing how to work with people properly will multiply your skills far better than any other "process hack". I've worked in waterfall teams, and i've worked on agile teams (every team does agile differently). Their productivity rarely came down to the process. It mattered more how much the person leading the team could find what motivated his team, and encouraged it, and how well the team worked together.
What are the traits of the good managers you experienced? And what are the traits of the bad ones? And what about the respective projects themselves: did they have good management vs bad management aspects?<p>Good project management is about communication. For all the respective participants, stakeholders, everyone has to be on the same definition of success. If not, you have to manage those expectations. In a bad project, different stake holders have completely different and sometimes unrealistic expectations.<p>I found that good managers rely heavily on experience or some form of "knowledge" to anticipate future problems and head them off. This could be technical, personality, business requirements, business externalities etc... A good manager also buffers, insulates and frees up the time of their engineers so they can do the technical work itself with little distraction. Above and beyond protect your people.<p>Personally I've found that people who are project managers who don't have any technical experience in the domain tend to be worse than those that do have technical experience since they don't fundamentally understand the work. However, there are exceptions.<p>Oh and add at least 100-150% to any and all software timeline estimates. Also don't throw more people at a problem.
<i>Have a clear direction for the team to be moving in, and communicate that objective to each of the team members clearly</i><p>That doesn't really get at the heart of modern project management thinking in the software industry because it is as applicable to waterfall as Extreme Programming. The key is how long the team can move in a direction without course correction.<p>Contemporary thinking boils down to the team and each individual can continue moving in a particular direction until the first sign that something isn't adding value for the customer or is reducing velocity. Then direction must be changed immediately.<p>The better the instrumentation of the development process the closer immediately gets to instantaneously. Continuous integration means that broken builds bubble up to the team in a matter of minutes rather than days or weeks and that regressions can be fixed as they are introduced. Short iteration cycles mean that the customer is actively engaged with the state of the project and has responsibility for prioritizing features. This whole customer thing means that management is not just downward it's upward toward the VP and sidewise toward customers and vendors.<p>The biggest mistake new managers make is to confuse management with supervision. Good managers are like ASE certified mechanics, they don't come out to your house to top off the oil. They identify and triage and possibly fix the leak when the car comes into the shop for scheduled maintenance.<p>Scrum/agile/extreme are ways to make sure that the oil gets changed regularly and avoid leaks via maintenance. It's not waiting for the "idiot light" [1] to come on. These things are not down the road. The techniques help a manager avoid their fallibilities and frailties and foibles when it comes to human interaction. They're there for the same reasons Ruby on Rails is there...they provide a framework that avoids having to write an MVC application in C.<p>Good luck.<p>[1]: <a href="http://en.wikipedia.org/wiki/Tell-tale_%28automotive%29" rel="nofollow">http://en.wikipedia.org/wiki/Tell-tale_%28automotive%29</a>
You may not have control over things like scope, timeframe, budget, "resources" (how I hate that word), but be expected to meet an arbitrary deadline. Get used to that. As sjg007 says, double any estimates you get, and don't confuse effort with duration. A task may require 4 hours of effort, but take 2 weeks to complete.<p>Google "planning fallacy", or see <a href="http://lesswrong.com/lw/jg/planning_fallacy/" rel="nofollow">http://lesswrong.com/lw/jg/planning_fallacy/</a>. In general getting a list of tasks together and thinking you have a handle on what it will take is a delusion. Trust your gut.<p>These books shifted my thinking on why some projects work out and others are disasters.<p>* <a href="http://www.amazon.com/The-Principles-Product-Development-Flow/dp/1935401009" rel="nofollow">http://www.amazon.com/The-Principles-Product-Development-Flo...</a>
* <a href="http://theleanstartup.com/" rel="nofollow">http://theleanstartup.com/</a><p>You could go the PMP route, I suppose. And get used to MS Project, which is a tool of the devil, but a necessary evil.
+1 on officialchicken's recommendation for MTM.<p>Another great book on management in general is "First, Break All The Rules" by Buckingham et.al. from Gallup - <a href="http://www.amazon.com/First-Break-All-The-Rules/dp/0743510119" rel="nofollow">http://www.amazon.com/First-Break-All-The-Rules/dp/074351011...</a><p>The important thing is not to dance a prescribed routine, but to be effective with the human individuals. Use known patterns as starts, and adjust as needed.<p>I think the first thing to do is discuss the business or user need. Then scope out phases or milestones. Then assign leaders to each area and give them time to think. Scope out timelines and get started - but adjust frequently and sync up on progress.<p>Good luck!
What problems have you ran into managing software projects? Seems like what you're doing is good enough. You described your workflow already.<p>I've never managed to get agile/scrum/waterfall working when followed to the letter.
My usual approach (coaching/mentoring agile teams for a few years) was to teach people how to fish, and try to become useless as a manager/coach/mentor on an everyday basis as soon as possible. If you have experience with software development processes, then you probably have an idea of how to run some/all of the required activities.<p>It really depends on your situation, but to me the game was always to get people to take initiative themselves, then get out of the way, and to let the process develop itself (start with a loosely defined one, and see how much you can live without!). Communicating the high level goals and making sure everyone understands the reasoning behind choices, so they can make the correct decisions or raise the relevant questions when they are unsure of how to proceed (policies, breaking changes etc.).<p>Everything was based around a basic Kanban approach with some Scrum-ish practices built in. Also process retrospectives at least bi-weekly, to improve the activities and discuss meta-level stuff. You're not really trying to improve unless you make bad choices some times.<p>The most difficult part of the above was always to allow people to make mistakes, so they can learn on their own...<p>So, with all of that in mind, make sure you understand whatever it is you / your team are supposed to achieve, read these:<p><a href="http://www.infoq.com/minibooks/kanban-scrum-minibook" rel="nofollow">http://www.infoq.com/minibooks/kanban-scrum-minibook</a> -- the free pdf<p><a href="http://en.wikipedia.org/wiki/Lean_software_development" rel="nofollow">http://en.wikipedia.org/wiki/Lean_software_development</a><p><a href="http://www.leanprimer.com/downloads/lean_primer.pdf" rel="nofollow">http://www.leanprimer.com/downloads/lean_primer.pdf</a><p>Learn to recognize as many of these as you can (look at least at the Project management and Organizational section) <a href="http://en.wikipedia.org/wiki/Anti-pattern" rel="nofollow">http://en.wikipedia.org/wiki/Anti-pattern</a> and try to minimize the amount in effect at any point in time.<p>Optimize over time. Some things take a while to take root, and may require a lot of talking to be accepted. You might also be wrong :)<p>Good luck!