How to effectively communicate to Developers/PMs - A guide for developers and project managers

is how to talk to developers back to

project managers

it has some kind of guy

[Music]

I've almost figured out this configure

than made

Oh

hey hey hey well hold your end

you mean the ticket I was just working

on it's a doubt it are you close

you gave me Eloise 16 hours and it's

been 15 and a half hours what are you

five times

how can I help Jean what resources do we

need to rebuild this printers I've not

had a full 15 I wanna support various

activities particularly on YouTube great

boss they saw us I have to tell my

stakeholders something so it's all sober

after my epic Pokemon great battle

if I started working on TTIP entry point

if I put a capital way with Cpl

community so initial process

improvements like you know how we can

write better to take heads and

gathering process so I'm not really far

at all with that tape but the good news

is and you discover a different method

no to just take a lot longer can you

give me a quick update on tickets 56:23

three two I didn't see any updates 6:23

is not completely defined yet have

opinion question and your work can start

that's my question is answer here

I know that this in PR 20 ticket 14 is

in PR 190 in my updates for ticket 1530

for $90 oh I forgot to tell you that we

had a meeting with the stakeholders and

Edwards we're gonna have it on 56 I

already started working on this ending

that describe everything I've done it

starting square one great

right but in order to account or

whatever the new changes is I'll have to

refactor my current work but you know

before I start with the refactoring I

need to pre factor to its twenty thirty

six or twenty thirty seven and and you

know happy puppy the ticket you know

you're probably workflow factor all the

submit your Republican without all that

best practices okay well that sounds

like we're going to do some significant

risk of being them and we should brought

this up in the quarterly meeting I'll go

ahead and schedule retro scopes to talk

I love the face to face those Marion

towers already got to let's get that

dress

so we get to that we all done okay here

so you guys gonna do the skip he's

actually a project manager my name is

Manny Peterson I'm actually a developer

we are banding so our mission at the AMA

were premiere national innovation which

looks to be the voice of positions

resonance and to medical students our

triple team we have three project

managers we have one premise analyst

room if three well

next in two weeks we will have three

full-time Drupal developers and creating

front-end developers and then we also

have supplemented

what we do it drupal right now is we

have two sites to separate these seven

sites for our corporate website images

are going to go to every family and then

we have wire which is our blog where we

miss stuff and then we just launch that

the topics hub which allows our content

editors to bring in content from all the

different directions and we're gonna be

building on that in the next year to

where these are one platform which will

be a big multi-site will be watching

this new project anyone will combine to

incorporate and wire and the topic

changes because it's a multi-site we'll

also have some web sites ethics and

maybe read extort richer but that's

pretty much their big project for this

game it's very exciting

yeah so some of the tools that we use we

are we probably use JIRA as our tracker

on the devil's use github Travis and

Talia as

cinnabar for our conventional

methodology we use agile and then it's a

kind of test-driven development

methodology oh I wouldn't ask you how

many project managers are here okay so

and then how many developers so one if I

go through some of the myths that folks

may have about developers and project

managers that's you anything they make

meetings for everything I didn't think

that's refactor everything fancy ramen

with don't pour p.m. Forex developers

interfaces and they can play about hold

requirements process devs are awesome

but there is some truth versus

perception so this is where we're going

to get into the stuff that we think

about each other which is actually so my

complaints about this you guys have

unclear or always changing estimates

state it should state not become 12 or

with tasks we've asked you to do one

thing yes just just stick that one thing

which brings my next point of gold plate

this is for those who don't know that

the idea of having smoke and then adding

on top of the stove even though the

workin stove is not done yet they are

segregated one-off issues that we're

going to have there in projects when

these happened what I hear is like we

were immediate and major process changes

we not the case all the time and then of

course whenever I'm trying to find

updates they're nowhere to be found in

these infinity plus meetings there's so

many meetings of meetings they're always

asking for estimates when you're in the

middle of trying to figure out how long

something is gonna take and you don't

always know like you're making sense

that have not been done before always

asking first status and always

interrupting and it's really hard to do

context context switching then it's like

deadly to a developer to have people

interrupting them okay they don't always

understand technical debt or what the

consequences are taking shortcuts to

meet delivery deadlines are they I think

sometimes they're lightly focused on

done they just want done and out the

door down you delivered and nothing is

ever done because we're always the wet

and it changes all the time and changing

and scope creep is something that drives

us nuts and over policy stakeholders

switch direction

so let's take a look at the reality so

instead of looking at the scene what we

actually do which will help us to make

it better

so what PMS actually do is we manage the

project schedule we are the safeguard of

the project so the only ones that we

regard the project scope we are the ones

that manage the budgets we make sure

that our party that starts at twenty

thousand dollars at in at twenty

thousand dollars invested over three

hundred horrible live longer and the

most difficult in my mind is we manage

our very ambitious stakeholders with

regard to that scope we are using we're

the first line of defense and the last

line to ensure that folks will come back

and say well originally I told you I

want you to build a bicycle but now I'd

like little mercedes-benz we damage

those things or expectations so when

they do come back and say be watching

focus where they spent really wants to

tell them that's going to cost a lot

more money and that's going to take a

lot of time this thing we think it's

common sense but it's not a lot of the

stakeholder will simply think yes we can

add in that one picture and it should

still be completed in the same amount of

time same amount of storage we've done

any sale cost as actually medicine

expectation and we act as a filter which

being are very curious stakeholders and

are antisocial developers can say every

when you get done with some of our

stakeholders you may turn out to be

so what if that's really do well we

built that's our basic job

we do provide estimates on work that

we've never done before which is

probably why most of us hate giving that

Bourget anything we read code and

documentation that's readable

maintainable by ourselves and others at

least on our team this is a huge part of

everything we do we can keep up with

best practices whatever that means and

we try trying to do better ways to make

things better for our users which are

both right how about content editors in

which I visit the website and we are the

ones that make cams look good or bad

like so this is what that's need from

PMS and stuff your PMS listen carefully

meet time space very quiet to work and

you know I'll be buff there's a little

difference but for most developers I

think would agree that interruptions are

criminals like it sometimes if there's

you know a hot finisher if something is

on fire

we should obviously yeah it's good to

interrupt a burning building but

otherwise it's good to every day or part

of your name where people

copy complete requirements in one place

on our team ideally that's an edger

ticket once we started giving that

letter that's been pretty helpful to us

we need you to shield us from the

stakeholders requesting questions we

don't want people coming and talking to

us directly because we're solutioning

nurse and so if somebody comes and says

hey can you do this I'm gonna say yes

and that's why they come to me so I need

them come to Robert so they can say no

she's already doing something so I need

him took me that filter and we need

positive feedback because we're we're

all human and we they hear from the

stakeholders hey this was awesome

and we often only hear the bad things so

it's really nicely

you pass along those in your feedback

and we always post next we should have

straight out of here

keeper this awesome for our spirit ropes

two weeks ago it's in Wikipedia and

Google cookie and it is a prototype that

he had made into a cookie cake versus

fantastic so that's a good thing that

project managers that's what Stephen

said I will say I think the positive x

is extremely important that she's

writing the devs sometimes don't you

very moralizing just here basis this it

more consistent to get a confidence

definitely show

all right so here's things that PM's

name we we are updates in the stated

location so in our case is here with

proper status needs new regulation

we enough information to give our

stakeholders our stakeholders are

providing us with questions and

expectations and glares every single day

and so we need to have as much

information as ammunition to make sure

that they they're satisfied we need

accurate ticket estimates this is huge

for us this is terminal that's human

accurately estimated to tailor to

directs me or her that been saying that

pace will be done in four hours and it

takes four days and then we need you

guys to understanding with refactoring

it's necessary versus when it's going to

affect what we promised our stakeholder

and maybe we should go ahead and roll

off and refactor before the rebels

so these are just a couple of things

that what works for us as a team what

we're supposed to include all

stakeholders and developers in the

discovery so at the beginning of the

project make sure that the developers

are in there so we know who we're

building plans for it and why - suppose

we have also good ideas on things that

we can make better and just it's good to

have that connections and then at the

end of a sprint or at the end of a

project make sure you include that all

the stakeholders and that as well we do

we have set developers all demo the work

that they get during a sprint to the

business people at the AMA and business

a chance to show off a little bit and

maybe put up sausages made and they

Sebastian see

yes we should also decide on

communication channels so you need to be

clear to say if your updates are going

to be in zero make that know if your

updates going to be in slacking in that

phone etc um we don't always understand

the text speak some of us do some of us

don't so when you speak to us talking

human please it's okay to have private

spaces so long as there's not more

pathetic p.m. should be aware of but

that's okay if they are up on certain

things okay this would be a good idea as

a matter of fact in this one point I'm

and allows or this would be a good

format that we should kind of a loved

one but really it this is what works for

us when we do take some time really

establishes and we probably never figure

out what was different but it's

important that you guys figure out

what's going to work for your your sons

and your swimmers and be willing to

change that to your vision that will

work for us for awhile then we get an

entire something doesn't work for

someone so we're we're revisiting it

refactoring our process of coming

together all the time trying to make it

better

successfully making it better yeah this

works this is the International notes at

home for developers and we have

headphones on do not bother them that's

just I

just a Robert on top who doesn't

so that's a test that is a thing that

works so uh and what it gets want and it

turns out all these product and

different one time in that in Visio are

signals and users you want to get that

so it's amazing we do have a few

vacancies and we're on the same team

teaser craters

I stay close your ass into sass again

amia talk with fanny wait let me check

the ticket status first to see if

there's an update oh yeah looks like

Ella we change from eight to twelve but

will still be on schedule this is good

I have information I can tell my

stakeholders to walk over via and more

girls but our topics waiting ages and

this kind of talks about the process we

do you want to know right my awesome bug

what does your mom say I can't see where

it says developers peers sort of

mentioned that you tried different inks

at work

to talk about that do work for you yeah

so I'll repeat the question because they

asked about so we have tried different

things and have found that this works

for us some things that we tried that

didn't work were people interrupting us

all the time and so we do straight

retros where we say what went well what

went wrong and those are brutally honest

we're we're like ego free so like we all

want the process to be better so when

something doesn't work we think about it

but it's just at the end of the Sprint

so that it's not hurting the whole two

weeks or three weeks in our case be

honest a lot of the process change that

we've done or are smaller or and they've

have in the past and we do them so

frequently that I can't pull up just one

change I'll give you one example though

the chamber just made we started off

this year having full all-day backlog

grooming sessions so there are debts

hate them because they're all day kind

of you have our stakeholders and they're

all day as well and we got to the retros

we try them twice and actually said you

know what we're not really using the

stakeholders time and so we're actually

gonna reduce the need to the stapler to

be there so they're only

today but again we've gone through so

many iterations of our process through

the rentals I can't just hold one out

one other thing that we have tried is

that let's say let's not do that again

is fighting on slack about technical

tents the bar up are about like things

that are going wrong so if if I'm doing

like I'm not being heard or something we

we get in a room and we talk and this

thing that's nice about the MA is it's

on site which is very old-fashioned and

square but it's also nice to get in a

room and see people's faces and

whiteboard and do that kind of thing so

we're not wherever people that are

people are humans are not just words

eNOS screaming this this might be more

of a comment than a question but wait

wait I'm I mean one of the areas of

tension and mismatch obviously is around

estimates turning out not to be

realistic and they I think you know like

I mean there a couple of reasons why

that happens

but I think in a lot of cases you ought

to be really blaming the sales or

management parts of your organization

for a lot of those cases at least not

that's what I've experienced a lot of

cases that if someone's trying to make

it a sale they want they want an

estimate at that point and there's

always pressure to make the estimate

something that lets them make them make

a bid that they know that they have a

stream that they feel confident well

when the the deal yeah and it's like and

and they're always and so there's this

pressure to but the other factors you

know as a developer you you know what

you know and you don't know what you

don't know and and so you're in the

middle of climates or Foe requirement

you've made a certain estimate and you

discover that there's a bug you didn't

anticipate that there's a problem that

you didn't know about because you like

you said you're doing up for the first

time right and my rule of thumb

was getting estimates from developers

was always to take their number and

triple it just for that reason

you know that's a really good talking

about what it's like if you have people

over promising for you well that's just

bad and there's pretty much nothing that

the cans are there gasps so you're both

at the mercy of other forces that are

that is exactly a team effort because

it's when one perspective is is the

pianie not the management's job to set

realistic expectations for the

stakeholders many of those acquisitions

of 9/11 folks once a year it is also a

team effort from the devs be as

transparent as possible because we are

asking you to estimate something she's

never done in here right and so the

second you realize oh crud it's not

enough yet the let us know as soon as

possible but again it's our job to say

to realize the arrest finding things

that they know done their life we're not

gonna tell the stick for repeat we're

gonna say it's 12 and we're gonna build

in all risk and assumptions for that as

well I think that's fair to do because

even if something ends up taking two

hours then this is also different

because we're not an agency when I was

selling work business this is our

internal process that people who are

claiming here we're keeping track you

finally buzzer yeah then we have to pay

the vendor developers thank you that's

what I wasn't so so on our team if we

find a bug in core or we find something

it's really important to me for the

developer to take the time to contribute

that back to core which takes time and

we have the luxury of having a pretty

awesome team who's very smart and knows

how to contribute back to core so that

if we have extra time then we can read

you are about documentation or we can

rebuild something so like hey hey like

that's found time we probably over

promised how long or overestimate how

long things are gonna take but then we

fill up that time with other goodness

that's right make your legs appear like

it's not like it's setting a very clear

buying you propositions of safe homes we

will deliver but we are not going to

promise you two weeks we're gonna

promise you a month and a half but we

will deliver in that month mad and we

are we feel yes we do it just right

our team looks really good at that okay

sometimes when he spends on this is good

to get a month and a half I'm like they

could do that in a week and he's like no

pictures why I don't do estimates and I

never got to stakeholders it might take

a week and a half but yeah well run into

things that you don't have it I'm just

really got it I know some really really

good developers who just always

eventually underestimate because they're

thinking about how they'll solve it not

about the problems that run into when

they yeah that's really good so again

we're in steering yes so you

underestimated the beverage

it's like yeah so I can say probably

that our team has delivered four year

solid multiple projects all one time to

scope and budget but this took a lot of

work and it was a full team effort on

everyone's part but we did that

primarily by setting clear expectations

with the stakeholders that again you're

not going to get something in two weeks

you can get something in five weeks

here's the amount of time my team needs

to do this correctly and to a standard

of quality here make sure it's tested

and everything but our devs do their

part by estimating the best our ability

and being as transparent as it possibly

can

yeah it's the other thing it's like all

the time it happens that's what he's

communicating to the outside world but

all the times as a developer you know

I'll say something's going to take four

hours and then I open it up and I'm like

god I'm just going to take 32 hours I

mean this is or I'm gonna need to sit

down with somebody and get some help on

this because there's no way I can do

this the important part of that is to

tell him and to not like struggle by

myself and and also not to just struggle

nobody should like on our team I want to

make sure that nobody struggles by

themselves for more than they should so

we make it a point to prepare program

like or even you know call it people or

get resources to help try to solve a

problem because like it's that's not

good for anybody to be spinning into it

deeper and deeper hole but it happens so

but yeah we underestimate things all the

time stuff so that's why that's why

there stuff like a buffer

that's what if your developers never

take off their top so this is our

process this is why we establish them

and we need our Commons and

what-have-you enduro and so we've

reached a happy medium which took us up

a lot of months to get to because first

it was then let's have everything into

your up and we tried that for fit and

everyone struggle with that RBA Dave's

rpms even the dev struggle to keep all

was yours fully update then it was like

alright let's have a medium let's make

sure things are document your let's

start conversations and our

communication tools slack and so now

we've kind of reached a medium where if

I have a question for dev I won't go and

just interrupt them because the issue

with that is that they are in a little

plot and you bet thought believe it or

not can take them another 15-20 minutes

to read 332 so I was sending them a

slack and said I have a question let me

know when you're free and then I'll

usually get it and use it for a couple

minutes so say hey I'm free now I'll

just walk by ask my question because to

your point yes most of them will first

have their headphones on just a little

bit of years developer when you're doing

that work you put your slack

notifications off because you know if

somebody really needs something they're

gonna tear up you but yeah they never

take their headphones off then you might

have to plan like checkpoints during a

day do stand-ups any other questions yes

the question was how do you like that

changing require interesting it happens

the way the way I've found is to again

it's it's that part where I mentioned

magic and secular expectation so the

requirements are changing something

about the scope or the time the cost is

also changing it's also communicating

that change with your dev so what we try

to avoid is saying their apartments a

change but the amount of time you have

to be work it's not but we try to come

back with is the requirements of change

and the amount of time you got to the

work is increased or we're adding

resources that that is usually the best

way even that is can you guys do that

when we had a big thing that got changed

and he said I think back to them said if

you want that change that's many others

another six weeks it'll be another two

sprints and so then they say okay look

if you want that change it's really

important so we had that that luxury but

yeah I think I think if you come to them

and say this has changed but I'm not

expecting you to work on the weekend or

overtime or whatever I understand that

this is new work that was not planned

for so we won't put something else in

the backlog just just to be realistic

about that that we're not like perpetual

working machines

oh yes yes you mentioned the key partner

with volunteer those projects he speaks

I like how you integrated them into your

culture or in process in terms of this

communication yeah that's a so the

question was how will we in it great

then their developers into our internal

team and that's a really great question

and it's something that we have worked

on a lot how much here because they have

done a lot of work like this had a lot

of ideas about it

meg Plunkett gave a presentation I think

here last year about how to integrate

external teams into an internal team and

from Western used to watch it because of

this - first she had a lot of epiphanies

to say about that

we're lucky that we have pilot areas

local to Chicago so we have them come

into the office a couple days a week and

I mean really just like these are our

processes and you follow them and we

give them like we have so much

documentation in the conference we're

just useful when you're setting up or

when you're doing tickets and this is

how you do your tickets and this is how

we do test fitting and this is what we

expect in a pull request review and they

have everyone review everyone's code so

everyone does pro review and I think

what also let me try to get together

sometimes too as humans yeah I think

would also lend it to this is where

we're following this form process we

have the West

our vendors in all of those tunnels so

you're in the daily sprouts here in the

backlog we which are also in a rush

where you can make recommendations we

try to set it up we're aiming when it

works with us apart the team they're not

just as off this vendor we just use for

work your car the team and so you our

engines actually matter and I think that

did help a lot for sure they're also

super smart and like we've had a really

good working relationship with and in a

healthy idea that's part of our life no

no ego on the team this week we will

have fights about things but like if

nobody gets mad and we can pick

different ways to do things come to our

session tomorrow and we'll talk more

about that