2009/Project Management Should be Boring!
Many people see project management as the art of trying to please everyone and pleasing no one, while trying not to go too far over deadline and too far over budget. It doesn’t have to be that way. Good project management can be so predictable and reliable that it’s almost boring. Here’s what works in real projects.
Speaker: chromatic x
Return to this session's details
- 1 Contributed notes
- 2 Contributed notes (notbenh)
- 3 success
- 4 boring is good
- 4.1 so how do I make my PM boring
- 4.2 risk
- 4.3 TDD
- 4.4 Deliver software
- 4.5 working on a cycle
- 4.6 risk: customer changes priorities
- 4.7 risk: release now might be unstable
- 4.8 risk: low quality
- 4.9 what if testing takes to long
- 4.10 risk: expectation for deadlines
- 4.11 risk: no one knows the deadline
- 4.12 risk: we keep getting bugs
- 4.13 risk: no one knows what to do with this (this design is unsustainable)
- 4.14 release Tues 945 am
- 4.15 what can you negotiate
- 4.16 how to you improve
- 4.17 QA
Relentlessly destroy order-dependent and/or intermittently failing tests
Hope is the enemy of reliability in open source development.
Bug trackers = Roach motels built around a black hole. Bugs check in but they don't check out.
Contributed notes (notbenh)
first solve your biggest problem, then iterate to solve the rest
boring is good
- having good processes = boring
- not having emergencies = boring
- no crisis mode = boring
- culture of relentless progress = boring
so how do I make my PM boring
Thing of how to make your project a success, then do that.
Theres tech risk (it doesn't work) and scope risk (it takes 3 months to do but it needs to be done next week)
quality risk (it only installs on one box, it fails every Tuesday)
cost risk (good = expensive)
0 write test 1 run test (FAIL) 2 update code 3 run test (goto 0 if SUCCESS else goto 2)
TDD requires discipline and patient but it gives you great gains.
- if you can time box your work then you restrict by time (not features)
- starts to build a cycle
- builds momentum
Thesis: unreleased code does not exist
you release not because the code is good but because you promised to release.
working on a cycle
just like tests you get feedback
if you release every month then you have a space for the customer to give you feedback (like it, hate it, needs this)
Just like testing it makes sure that you stay on task.
This is just applying the scientific method to development, it allows you to validate your theory.
find a way to destroy all sources of uncertainty.
Thesis: many of non-tech problems are rooted in not understanding risk
risk: customer changes priorities
- require customer to stay on task
- stay on point with in the team
!! FAIL you cant predict the future, so why try and restrict?
way to resolve
delay making a decision until the last possible RESPONSIBLE moment.
EX: I'm planning a party in a year, I can't make the menu because I don't know who is going to be here
get really specific when you know everything that you need for a feature, other wise play in broad strokes.
prioritize on broad features (ie we need a shopping cart )
risk: release now might be unstable
common response :
- feature branch
- feature freeze
this only delays the next iteration, you end up in QA for ever, you block everyone, its demoralizing and it inhibits your ability to plan.
best solution: always have a trunk that is releasable
if you cant release now then how do you know if you ever could?
risk: low quality
common response :
- need more QA
- need for really lock feature freeze
problem is that you are not addressing the root cause, its quality not QA.
more tests? exploratory testing (LOOK IT UP)? if quality is low then why is it bad?
are you really done done? is it schedule pressure? is it skill level?
is the reason because you do not get any feedback.
what if testing takes to long
common response :
- branch early branch often
every time you have a long lived branch you double your burden.
you need to parallelize QA.
create a way to get as much feedback in to the cycle.
there good as long as its a feature that you plan on merging back soon, not in months.
trunk has to be stable and releasable
risk: expectation for deadlines
- gantt chart
- plan an entire release
um, were all optimists, stop trying, break things down in to things that can be estimated.
burn up chart: graph to project based on tasks velocity, but this only works when you know how long a task is and you can project
risk: no one knows the deadline
- make a deadline to blow
remove the uncertainty by having a steady release, on a cycle, you no longer have to make the decision on when to release.
all that is left is asking if trunk is releasable? and is this feature going to be in the next release?
if you release on an interval then it really doen't matter if a feature is going to miss the deadline because it will be picked up next time.
again it forced more feedback
risk: we keep getting bugs
unhappy users you've found documentation issues
- better but triage (relies on hope, and hope is not repeatable)
your not preventing bugs, your not proactive only reactive.
if its an issue that takes you less then 2 minutes, then just do it now.
if it takes more then 2 minutes and its something that needs to be solved then it's really a feature request, add it to the project feature list.
if its not worth doing then skip it
risk: no one knows what to do with this (this design is unsustainable)
you have built barriers to allow your customer solver there problems
- grand re-factor
no one is every going to just rewrite everything, theres no need for your employer to spend time to stay in the same place.
theres a three step re-factor process
- clean your code while you see it
- take some time, say 2 hours on Friday, clean up stuff gunky bits if you have all your other tasks done.
- every release spend some time and do a post mort to build out features for your self, (ie I keep mistyping this method because its a plural)
in short every commit should make the code better and easier every time.
have a deprecation policy, stick to it.
release Tues 945 am
its the most boring time
what can you negotiate
- you can talk about scope
- you can not talk quality
- NEVER talk about time estimates
how to you improve
ask your self 'why' 5 times and don't repeat your answers. where you end up is probably a good place to start fixing things.
why did we miss the deadline. we didn't run the tests why didn't you run the tests. they take to long. why do they take so long? because we run on the entire customer data set...
how do you deal with expensive releases
if it takes 8 hours to install an upgrade is a weekly cycle good? - you'll have to optimize the upgrade, point out the bottlenecks as features'
how does this work with large systems?
ie if I have a small project, and then we find out that we need a big DB, now we need a schema design....
- when you know that you have more needs then you can start to plan, you can still address it incrementally.
- also if you can encapsulate, then do it, you will reduce the risk as you have limited the stuff that will change.