We are once again offering the Technical Excellence Workshop as an open-enrollment experience this October.
It's an 8-week experience where we spend a few hours a week together, and we explore technical skills, perspectives, safety, behavioral skills, & leadership.
There is access to expert eLearning and there are exercises to perform during the week (some canned exercises, some live exploration) that will change how you look at your work and your organization.
Students from prior iterations have said that they had better interactions with their teams in the first week. Some claim that it made them better programmers. They have been able to initiate continuous improvement in their organizations.
Others learned to explain and teach.
Because it's only 6-8 hours a week, many organizations are able to afford the time compared to having one or more solid weeks of work stoppage.
What does software development look like from the outside?
I request N things. A few of them come out months later.
Hence: these programmers need to work faster.
1/
however, each of the N things really only took about 4 days to complete on average. Working 2x as fast (a dubious prospect) would carve off only 2 days from delivery time.
2/
What you don't see is that the work was delayed, prioritized, queued up behind dozens or hundreds of other bits of work, rejected and reworked, queued up some more, approved, and then batched up with a bunch of other work while it waited for a few more things to finish.
3/
Test first - red.
Oh, I don't like the way that message reads.
Ah, better.
Code - not green?
Quick, most obvious solution.
Still not green.
Oh, why didn't that work?
Was it the test or the new code?
AH! It's the new code. Okay...
Green.
Refactor: I don't like how I structured that test.
Still Green.
The code has some funny names in it. Rename.
Still Green.
Oh, crud, there's a library function for that.
Revise.
Still Green.
Okay.
A: Why do you use a ticket tracker?
B: We have thousands of backlog entries.
A: wait... what? Why? How does that help?
B: If we don't store them, we may forget.
A: if you have a list of thousands, you'll remember them all?
B: No, but if we review it we can see that we stored them and might pull them into the sprint.
A: How often do you do that?
B: We don't, there's always too much new work.
A: Okay, so you store them in case you ever run out of new work to do and need to pull something old and forgotten into the sprint.
B: Well, yes, and so we can tell people it's in the backlog.
Sometimes you cannot plan. This is either because of the prevailing circumstances (chaos, complexity, extreme complication, dependency) or because you just don't know how.
In those cases, you set an intention and take advantage of opportunities.
At the end of the road, looking back, an excellent opportunist or an exquisite planner will not only have the same results, but their paths are indistinguishable.
Everyone thinks people reach their goals through exquisite planning and flawless execution, but (truth be told) it was largely intention & exploited opportunity.
“How long does a 2-point story usually take?”
“We peg story points to half-days so 2 points is one day.”
“Yes, how long does a 2-point story usually take?”
“One day.”
“Historically, or ideally?”
“One day.”
“Most of the features you released are over 40 days old.”
“But, um….”
“So 40 days is more than one day, right?”
“Yeah, but the coding part only takes one day.”
“Are you sure. Did you check the actuals on that?”
“No, but they are estimated for one day, so it’s got to be pretty close.”
“But is it?”
“Now that you mention it, no.”
“So how do you know?”
“Well, we always fail our sprints by coming in short. We need the developers to work faster.”
“Work faster so that the estimates become true?”