Let’s talk a little bit about showing your working code to your product person.
A basic recommendation, which will seem strange and likely freak you out the first time you hear it.
Look to show your new stuff every day or two.
I want to address here both the how and the why.
The why has three parts: 1) just-in-time tuning, 2) food-pellets. 3) cross-specialty connection.
Just-in-time tuning is just feedback. But I used an odd word, as i’m wont to, to keep you from instantly symbolizing the idea into something you think you already get. One of the myths of software development is the idea that written requirements can or should fully specify what a program does. The trade is gradually backing away from this myth, but its shadow lingers on.
There’s a trivial disproof: if you’re a geek, your entire job is the translation of human language, which is neither precise nor complete, into computer language, which is both. Doing this takes considerable human judgment. That’s why they pay you for it.
Written requirements can’t specify an actual program because they can never be made as precise or complete as a program has to be to run. If they were that precise and complete, they would be a program, and we would be already done. Because requirements are imprecise and incomplete — by definition, not failure of will or technique — we want to operate around them with a continuous flow of conversation about variation, exempla, exception.
We need to be tuning our code and our understanding of what is wanted. We need to do that with a product person for the simple reason that they are experts in what is wanted. (aside: product people aren’t bosses, they’re experts. Working w/o one is like writing a gigantic web app w/o someone who is an network infrastructure expert. It’s slow, dumb, and very very risky.) The second why: food pellets. This angle on feedback never gets any press, i’m not sure why, except maybe people are taught to be blind to themselves.
Didja ever have your product person go, "oh! Cool." or even "yes, YES. That’s it exactly."?
How did that make you feel?
I’m gonna go out on a limb and predict it made you feel pretty damned good. I’ll go out even further, and predict that it made you, for a short period after, more effective, more efficient, more energized, in short, a greater producer of value.
Rats press levers to get food pellets. That’s not cuz they’re primitive. We all press levers to get food pellets — or anything else that makes us feel good. Don’t hate that about yourself. use it.
Another stock myth for geeks: product people only care about big steps. This one I think comes from disregarding their human-ness, further muddied by the weird shaping pressure of stupid and irrelevant deadlines that they live under. But your product person is a person, and she’s creating a product through you. When you get something right, even something little, she’s seeing her vision come true, even a little.
Guess what: pellets.
Yep. Makes her feel good. Increases her effectiveness, efficiency, and energy for a short time.
That "short time" thing is important. Bigger steps don’t make correspondingly longer-lasting highs. It’s another myth. Understand the risk of binge/starve mechanics. So pellets is about getting your team — including your product person — a steady incremental supply of "feeling pretty damned good".
The third why I called cross-specialty connection, but it’s really "teaming". Teams have insides and outsides and borders, possibly gray slippery ones.
One of the easiest ways to form a team is to declare that everyone with attribute X is in the team, and everyone else is out of the team. Easy, but not useful.
Modern software takes lots of specialties. Modern lots of things do. I like the example of making movies. Think of your favorite movie. Do you know how many specialists collaborated to make that movie?
The precise number: scads and scads.
Aside: geeks know this on one level but ignore it on others. I know of few teams that don’t have "go to" people for the tricky specializations in their code. "go to sherry, she knows about how the threading works," for instance.
Where do you want your product person to be? inside the team or outside the team?
I know where I want mine.
Showing my code every day or two is a way of telling a shared story. Shared stories are the next easiest way to make teams. And unlike team-by-attribute, team-by-narrative is actually useful.
So now we know why we want to share every day or two: 1) tuning, 2) pellets, 3) teaming.
But how should we go about it? Once again I might surprise you.
In the strongest possible terms I urge you not to schedule a recurring meeting.
1) Use haykumeer protocol. 2) Use any large screen in the workroom not a meeting room. 3) If you must be reminded, do it with a "days since" counter.
Haykumeer protocol: "Hey, come here. I want to show you something." It’s that simple. (I realize that some orgs make this very hard to do. We’ll come back to that. In the meantime, just go with me.)
Any big screen will do. Grab one, plug it in, and show stuff. These sessions are short. We don’t need chairs and tables and webex. We need engagement around what is on the screen. We need interaction. (again, some orgs make this hard. Go with me, problem-solving is next.) days since: how can you know when you should use the protocol and show stuff? First of all, that’s just an "in the beginning problem".
Once you start living this way, believe me, you’ll know. Why? Cuz pellets. 🙂
But if you feel you must have a reminder, put a number up on the whiteboard: "hours since we showed stuff [ ]". Increment it every morning at standup. What you’re after here is a sense of rising tension, not a sense of impending deadline.
(aside: it’s like TDD and CI once you get them going. There’s no schedule to push. You just feel increasing tension and desire to push as the time stretches on.) so there ya go.
Why: 1) tuning, 2) pellets, 3) teaming.
How: 1) haykumeer, 2) workroom big-screen, 3) days-since.
I’d like to walk away, but I can’t, yet, cuz I promised. There are lots of orgs that make living like this difficult in various ways. It’s not fair for me to just tell you to make it happen w/o giving some idea of what you’re likely to press against and how to overcome it.
Most likely issue: your org makes it impossible or very difficult to access a product person. There’s no short answer for this other than "don’t do that". To add one more sentence to that, if you’re not going to put product together with developers, you are absolutely not going to "do agile". If u need expert cites, ping me. I know dozens of product specialists who agree.
Still, backing off from that, we still have two common difficulties: 1) product person lives in another place or even timezone. 2) product person is booked in outlook 19 hours a day every single day. The answer for both of these is the same: block out a half-hour that’s congenial to both parties every day. Use it when you want to, don’t use it when you don’t.
We tend to think of outlook-allocated timeboxes as things we must fill. But it’s not true. Outlook works for you, you don’t work for outlook. I’ve never met a meeting-loaded person who wouldn’t be delighted at having a mandatory half-hour slot at their desk that often didn’t have a meeting, but sometimes did.
Another common issue: there’s no handy big monitor laying around unless we have a meeting in a conference room. Buy one, on a rolling stand. At less than a grand, it’s chump change compared to the benefit it provides.
A very deep process issue: "we never have anything that goes from not showable to showable in a day or two." of course, there is often staggering. Once a team reaches a small critical mass, it’s likely that some story will reach showability every day or two, even if most stories take more time than that. But that’s a dodge. A set of stories whose "time to show" mean is more than a couple of days is actually evidence that we have not gotten good enough at our job.
I have explained (and advocated) extreme increment and iteration (I&I) elsewhere, at length. It is central to the modern technical synthesis. If you’re not yet able to do that, we need to work on that. Hard. We need to work on that hard.
One more thought on these and other potential blockers to this way of showing your code every day or two. It’s a generic thought, applicable to any and all political difficulties you might find in getting this all started.
As working geeks you are your orgs "makers making the made", & they are hopelessly dependent on you. Because you sit on the 1st floor, you might think you’ve no power. This is the greatest myth in a myth-laden muse.
You have power to change. You just have to use it.
So. In conclusion: figure out how you are going to get to sharing your code with your product person every day or two. The benefits are enormous, the cost is minimal.