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?
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
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.
Thanks!
That book should be required reading for anyone on either side of the commonly asked question, "How do we build this?"
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: http://www.amazon.com/Code-Complete-Practical-Handbook-Const...
[edit grammer]
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.
To keep things short, just read this (or get the audible book) http://www.amazon.com/How-Win-Friends-Influence-People/dp/15...
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.
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.
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.
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.
Oh and add at least 100-150% to any and all software timeline estimates. Also don't throw more people at a problem.
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.
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.
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.
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.
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.
Good luck.
[1]: http://en.wikipedia.org/wiki/Tell-tale_%28automotive%29
Google "planning fallacy", or see http://lesswrong.com/lw/jg/planning_fallacy/. 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.
These books shifted my thinking on why some projects work out and others are disasters.
* http://www.amazon.com/The-Principles-Product-Development-Flo... * http://theleanstartup.com/
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.
Another great book on management in general is "First, Break All The Rules" by Buckingham et.al. from Gallup - http://www.amazon.com/First-Break-All-The-Rules/dp/074351011...
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.
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.
Good luck!
I've never managed to get agile/scrum/waterfall working when followed to the letter.
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.).
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.
The most difficult part of the above was always to allow people to make mistakes, so they can learn on their own...
So, with all of that in mind, make sure you understand whatever it is you / your team are supposed to achieve, read these:
http://www.infoq.com/minibooks/kanban-scrum-minibook -- the free pdf
http://en.wikipedia.org/wiki/Lean_software_development
http://www.leanprimer.com/downloads/lean_primer.pdf
Learn to recognize as many of these as you can (look at least at the Project management and Organizational section) http://en.wikipedia.org/wiki/Anti-pattern and try to minimize the amount in effect at any point in time.
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 :)
Good luck!
