Get things done : pragmatic project management

get things done (not tm) (not that thing)!

Stan Carrico Web Engineer

A pragmatic approach to project management

DisclaimerDisclaimer

– google definition

pragmatism : an approach that assesses the truth of meaning of theories or beliefs in terms of the success of their practical application

Challenges

Stakeholders

Management

Teammates

Timelines

FUD

How can I learn other than by experience?

How to pick up project management basics

READ (see some ideas at end of preso)

Organize a small open source project

Volunteer to help with project communication.

Learn to manage yourself effectively.

Put yourself in others shoes and ask what you would need to know if you had to report to the investor.

what if you’re in the fire already?

COMMUNICATE

Most instances of PM status meeting thrashing can be solved through consistent communication.

If you haven’t planned out what you’re working on, take the time to do it, even if the project has already “started”

The sooner you can flag potential problems the better.

Make sure you answer people’s questions, try to understand their concerns, and always offer a solution.

How to relay things clearly.. Know what you want to say.

Know your audience.

What do you want then to learn

What is their interest in what you've got to say

How sophisticated are they

How much detail do they value

Whom do you want to own the information

How can you motivate them to listen to you.

Hunt, Andrew; Thomas, David (1999-10-20). The Pragmatic Programmer: From Journeyman to Master

Don’t forget the little things

Choose your moment.

Choose a style.

Make it look good.

Involve your audience.

Be a listener.

Get back to people

Hunt, Andrew; Thomas, David (1999-10-20). The Pragmatic Programmer: From Journeyman to Master

Roleplay

Why are these conversations different?

A : PM is not given enough information to do their job.

B : PM was given information they can relay to their stakeholders

stakeholder could choose to course correct but is assured that progress is being made.

offer of demo gives credibility to status update

Phrases to avoid“I’ll try.

I should be able to do that.

Let’s hope for the best.

I’ll just do….

We’ll have to make do.

I’ll multitask.Johanna Rothman, Esther Derby. “Behind Closed Doors”

“We can’t do this impossible thing, but we’ll try it anyway. We’ll suck up the risk and

postpone a painful discussion until later.”

Instead try…

“I don’t know how to do that.

I won’t promise something I know I cannot deliver. Here’s what I believe we can deliver.

I will work with my team to see what we can achieve.”

“We’ll work on the most important features first and show you each month what we’ve completed.”

Johanna Rothman, Esther Derby. “Behind Closed Doors”

Avoid this kind of conversation entirely

Organize your workDo not start on a project without a basic plan. Make one and share it with your teammates and with anyone responsible for your success.

Schedule demos of functionality to get better interim gauge of progress.

Communicate proactively on a schedule that people can anticipate.

Take control by providing information frequently on a schedule that works for you.

If you are already providing an answer, and people can easily find it, they will not have to come ask you.

Learn to effectively analyze stories / bugs

Break bug / story into chewable pieces.

try for a day or two of effort

this is essential so that features can be triaged when requirements change

if a bug is going to take more than two weeks to fix, it needs to be flagged and escalated to the overall project plan.

Sanity check your analysis with a peer before you embark on the solution.

Take control of your assignments

Treat each assignment as its own mini project

Take the time to outline the requirements for yourself

This will help you identify holes in them

ASK IMMEDIATELY for any missing information, but to not refuse to begin if you can do so without every detail.

Be your own boss

YOU are ultimately responsible for your success.

Each person taking ownership will ensure the larger project succeeds.

Do not compromise on minimum planning, but do not spend more time doing it than you would spend on a simple prototype.

Use tools to your advantage

Agile Ceremonies

Planning software

Ticketing systems

Workflow process

Tools can be helpful if they are used judiciously and applied to solve specific problems encountered in your project.

Every project needs some version of these tools

If you do not understand a tool, learn about it before you suggest it *

*this especially goes for specific development ceremonies

Agile Ceremonies

Daily Stand-Up

Sprint / Iteration Planning

Retrospectives

Planning softwareLet’s look at OmniPlan

How can this thing help?

List your chewable features

hook up dependencies

Classify into reasonable buckets

go and adjust your calendar impacts (vacation, efficiency, etc)

get some high level milestones to put on the quarterly plan

adjust it weekly as things change

Ticketing systemsnot everything, sadly is a new project

warranty and maintenance can be killer for status and communication

ticketing systems give everyone the same view on progress and status

half an hour a day working your tickets can save hours of wasted status meetings later

any project without a ticketing system needs one, stat. Never agree to use email or spreadsheets (static documents) in place of some form of live ticketing system

Workflow processesEstablish a culture for code deployment and release management by documenting how this will work and sticking to it on a daily basis

Ensure there are automated ways to perform tasks that need to be completed consistently by multiple parties

project compilation / build

test execution

code deployment

environment health checks

Workflow cont’dconsider a peer code review process

if you are not working alone (it is always better if you can find at least one partner) ask a peer to both spot check your code commits, and sanity check your solutions *before* that code gets into a release.

nobody is beyond the need for peer review

foster a culture of constructive criticism. focus on the code, not on the person.

ask your reviewer to execute your solution and spot check whether it is meeting the requirements.

plan for time your schedule to allow code review to be completed by all parties participating in the development process

Fear, Uncertainty, Doubt

some common sources of FUD

analysis paralysis

incompetent team members

ignorant management

lack of momentum

Slay the FUD dragon

Agile your way through analysis paralysis

“Accepting the first truth means you are not afraid to begin your journey without knowing everything up front. You understand that requirements are meant to be discovered and that not proceeding until all are gathered would mean never starting.”

“Accepting the second means you no longer fear or avoid change. You know it is coming. You accept it for what it is. You adapt your plan when necessary and move on.”

“By accepting the third, you no longer get stressed when your to-do list exceeds your time and resources to deliver. This is the normal state for any interesting project. You do the only thing you can—you set some priorities, get the most important stuff done first, and save the least important for last.”

Excerpt From: Jonathan Rasmusson. “The Agile Samurai”

–The Pragmatic Programmer

“Some things are better done than described.”

Prototypes are your friend

Lots of hypothetical concerns can be deflated with a working prototype

Instead of a 3 hour fight, that same 3 hours into a prototype can answer questions for days or weeks, and can remind you a month later how the problem was approached initially

Most “concerns” about whether something will work or solve the problem can be proven or disproven.

Lack of Momentum….Stop, re-evaluate your initial plan

If you are way off, re-analyze the problem based on the information you have gathered and determine what assumptions were inaccurate.

adjust and reproduce your plan, share it with the team, and validate the parts with the parties producing them. if possible, do not communicate estimates that has not been vetted by the developer(s) who will be doing the work.

share a new plan, but do not promise large items. start by promising attainable, small goals, and build trust before taking a shot at a big deliverable again.

DONE! (js)