Skip to content

Instantly share code, notes, and snippets.

@MichaelDimmitt
Last active April 13, 2022 22:50
Show Gist options
  • Save MichaelDimmitt/af51869358313bcaa5ac4272dc64a6a9 to your computer and use it in GitHub Desktop.
Save MichaelDimmitt/af51869358313bcaa5ac4272dc64a6a9 to your computer and use it in GitHub Desktop.
developer-diaries

a good deed counts for much.

a small flaw reveals much.

super is few, repetative flaws lose trust.


Developer Diary, number one:

personal note: (bad estimations are a small flaw of mine repeated for years)

action item: (begin writing post mortems on tickets that exceeded my estimation)

agile violations

  1. the work is the same.
  2. the time is the same.
  3. the estimation could be better.
  4. was motivation a factor in this instance, no. (this must always be asked)

am I a bad developer?

are you a bad developer?

what makes a good developer?

the work is hard.

the work does not change.

quality?

why are some people fast and others slow?

are they working on the same types of tasks?

agile violations

violations happen on both sides

lets take a look at a current team agreement that I am operating within.

"in a kanban style"

assertion:

items in the developer doing column are expected to take 1 day. 3 days tops.

^ where did this number come from ? actual how the team was doing? yearnings to do better?

the trick here is that yearning should come from a real number baseline.

I dont think that happened.

Moving on ...

I have a bad habit, if everything is supposed to take a day

"yeah, this ticket will probably take a day" "or, lot of changes here this will probably take 2 days."

1 week later. "I feel terrible, the team smells a stink"

but it is not just me, others on the team feel they are failing or taking too long.

? what could I do better

is there a problem that I need to solve?

yes. absolutely, but it is not as you think.

lets imagine, I was good at estimating.

a story comes in,

  • immediate rejection from myself
  • build an outline of what steps
  • post how long each step will take
  • force the card to be broken up.

the fear,

  • there is a ticket quota
  • rejecting one ticket is fine
  • rejecting many tickets ... (what could go wrong)

should the dynamics of other team members come into play in agile?

probably, our actions should be a product of the tool we are measured by.

whether it is specific metrics. or certain stakeholder expectations.

once you gather those expectations aim every step to completing a task with that goal.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment