Upload
stan-carrico
View
200
Download
1
Embed Size (px)
DESCRIPTION
Bitovi summer training camp presentation on communication and project / task management. Roleplay dialog: Version 1 (not the best) PM : How is this new chart progressing? You have been working on it for two weeks and it needs to be complete by end of week. Dev round A: I'm working as fast as I can! I'm trying to get it done by the end of the week. PM : Well, I'll check in with you again in a few hours. Dev round A : I need more time than that, why don't you give me a day and then try me again? PM : I need this to be done by Friday and it's already Thursday. How much longer do you need? Dev round A : I don't know, but longer than a few hours.. __ Version 2 (better) PM : How is this new chart progressing? You have been working on it for two weeks and it needs to be complete by end of week. Dev round B : The chart consists of the plot, the axes and the css styles we're applying from the design mockup. I have completed the plot, and I estimate that the axis and applying styles will each take about 6 hours to complete. The plot took me longer than I expected. I think we should plan to demo the full chart on Monday. PM : Can you update me when the axis and styles are done? Dev round B : Sure. Does the business need to give us feedback on the plot, axis or styles? We can demo the plot now, the axis will be ready in the morning, and the styles will be applied and ready to demo on Monday morning. PM : No, I think we need the complete product. I'll verify the don't need to give feedback on the pieces. Dev round B : Ok, I'll send you a note when they are finished tomorrow evening, or I will update you before that if I run into any blockers. References The Pragmatic Programmer 1999 By Andrew Hunt and Dave Thomas Team Geek 2012 By Brian W. Fitzpatrick, Ben Collins-Sussman Head First Object-Oriented Analysis and Design 2006 By Brett McLaughlin, Gary Pollice, David West The Agile Samurai 2014 Jonathan Rasmusson Behind Closed Doors 2014 By Johanna Rothman, Esther Derby.
Citation preview
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)