

Ask HN: How do you actually manage a software project? - raphaelb

I&#x27;ve spent almost 10 years doing software development as a dev, and I&#x27;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&#x27;d like to get my head around what software project management is at it&#x27;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&#x27;m trying to get a grasp of.<p>Thanks!
======
swalsh
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.

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...](http://www.amazon.com/How-Win-Friends-Influence-
People/dp/1508569754)

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.

------
officialchicken
If I only had one suggestion it would be:
[http://en.wikipedia.org/wiki/The_Mythical_Man-
Month](http://en.wikipedia.org/wiki/The_Mythical_Man-Month)

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...](http://www.amazon.com/Code-Complete-Practical-Handbook-
Construction/dp/0735619670)

[edit grammer]

------
sjg007
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?

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.

------
brudgers
_Have a clear direction for the team to be moving in, and communicate that
objective to each of the team members clearly_

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](http://en.wikipedia.org/wiki/Tell-
tale_%28automotive%29)

------
ianmcgowan
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.

Google "planning fallacy", or see
[http://lesswrong.com/lw/jg/planning_fallacy/](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://www.amazon.com/The-Principles-Product-Development-Flow/dp/1935401009) * [http://theleanstartup.com/](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.

------
late2part
+1 on officialchicken's recommendation for MTM.

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...](http://www.amazon.com/First-Break-All-The-
Rules/dp/0743510119)

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!

------
blooberr
What problems have you ran into managing software projects? Seems like what
you're doing is good enough. You described your workflow already.

I've never managed to get agile/scrum/waterfall working when followed to the
letter.

------
orbitbot
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.

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](http://www.infoq.com/minibooks/kanban-scrum-minibook) \-- the free
pdf

[http://en.wikipedia.org/wiki/Lean_software_development](http://en.wikipedia.org/wiki/Lean_software_development)

[http://www.leanprimer.com/downloads/lean_primer.pdf](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](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!

