Blog name change

I changed my blog name to "Coding When High."

This probably requires a little explanation lest you draw the wrong conclusions.



Originally I named this blog "Mixed Messages" with the explanation that I was unsure I could restrict myself to any one topic. And indeed over the last couple years there were a few  posts on things other than software development  topics. However, as its turned out, the vast majority of what I write about has stemmed from my experiences managing and participating on agile and scrum teams over the last few years.

Since a clear focus has emerged for my writing here I thought a new blog name was in order. Plus I wanted to play with Tumblr, so I'll henceforth be posting my non-work related stuff over at http://jonarcher.tumblr.com/ (nothing interesting there yet...)

So how did I arrive at this name? Well, I've recently switched back from management to individual contributor on a team. Currently I'm acting as Scrum Master, but with a definite intention of writing some substantive code soon. Add in that I live at 9,200 feet above sea level, up in the Rocky Mountains west of Denver, CO...et voila, "Coding When High" sprang to mind.

So no, don't worry. I'm not doing MDD (marijuana driven development).

The perils of rolling your own

I spent a good portion of the early years of my adult life messing up my health by smoking. Even throughout my thirties I was an off and on smoker (or “social smoker” if you will) at various times.

It’s well understood that no matter what you smoke, whether regular cigarettes, “low-tar”, cigars, hookahs or even medicinal (or illicit I suppose) marijuana: inhaling smoke will screw your lungs up pretty good. For my part, I smoked hand-rolled cigarettes, which is probably one of the worst options: no filter to take out anything at all.



In 2002 I moved from the UK to Boulder, Colorado in the US. For those that don’t know, there’s probably no place else on earth with a more militant anti-smoking stance than Boulder:

"In 1995... Boulder voters made national headlines and created a local uproar by expanding the city’s smoking ordinance to ban smoking in all indoor public place... The Boulder Dinner Theater had to get a special dispensation so an actor could light up on stage, as called for in a play."

From Insider's Guide to Boulder and Rocky Mountain National Park by By Ann Alexander Leggett, Roz Brown

As it turned out this was actually a great thing for me. It helped make quitting smoking and attempting a significant lifestyle change considerably more possible. Nonetheless, the first time I went to a gym and tried to run (for just sixty seconds!) I swear I nearly died. Humiliatingly, the gentleman on the treadmill next to me, easily older than my father, was barreling along at 6mph and hand been doing so for the last twenty minutes.

I definitely learned the hard way that rolling your own is bad.

I think this lesson translates into software development too. It’s often tempting to “roll your own” frameworks for various software development needs. At one point in time this was especially true for web applications. I’ve been to party this. Several years back we wanted an MVC web framework with AJAX support. There weren’t any at the time, or certainly none our lead engineer liked. So a couple of the guys I worked with wrote one. It was a cool project; fun and intellectually stimulating as well as educational. And we got to do things the “right” way, no more tolerating those parts of other frameworks we didn’t like. But it became the biggest albatross around our neck.

When you build your own proprietary framework there are several key problems:

• Nobody's going to maintain it but you. This starts off as fun -- nobody else is "screwing" with your code, but quickly becomes a bind. In our situation in particular, with the AJAX/MVC web framework there was the never ending tedium of browser compatibility issues.
• Dubious value. Is building general purpose frameworks *really* what you want to be paying your engineers to do? Is that *really* the business you’re in? Is it *really* the best use of their time?
• It's hard! Sure, building 80% of the framework you think you want isn't too hard. But try finishing it. Try polishing it. That last 20% is tough.
• Eventually the originators leave. You may think you've got the institutional knowledge for your framework well shared. But I'm willing to bet that if the main driver behind your home grown solution leaves it'll start to rot. A year later (if that) everyone will hate it. Not much longer and it'll be the reason why nothing can be done and everything about your product sucks (this is often melodrama but try countering it effectively...)
• New employees have never heard of it. So they have to learn it. And, obviously you can’t hire anybody with experience in using it.
• It lives...and lives and lives. Once you have products depending on your framework, extricating yourself from that can be difficult and costly. Just try convincing non-engineers that you spend time fixing this problem.

These are big problems and not to be underestimated. Based on my experience you should think very, very hard before you decide to commit to investing in building your own framework for anything.

The MVC/AJAX web framework we built years ago still limits us even today.

It was OK for the experienced highly-skilled programmers that built it. It was great for them to build rich one-off applications with. The trouble was, the business needed us to build dozens and dozens of cookie cutter applications…all similar but slightly different.

The trouble with that kind of work is that one doesn't tend to use experienced, highly-skilled programmers for it (or if you do, they don't stay around for long).

So then of course we had a framework that was hard for most of its users, and certainly wasn't geared to churning out cookie-cutter applications. They were frustrated and it was overly complex for the actual task at hand. Part of the consequences of that was we suffered the same defects and problems in the cookie-cutter applications over and over again. And it took longer than it needed to build them and longer than it needed to test them.

Once again, I learned the hard way that rolling your own is a really bad idea. We should have built a tool for building cookie cutter apps, not a general purpose web framework. Quickly and reliably turning out cookie cutter apps was the business we were in, not web frameworks.

P.S. if you've still got that itch to build a framework, how about contributing to an open source one instead?

You are not my customer

(And I am definitely not your supplier)

---

Recently our VP sent out one of his regular update emails and included in it a little piece about the virtues of internal customer service. He included the following in his email which appears to have come from Entrepreneur.com:

Internal Customer Service: Getting Your Organization to Work Together

Great customer service isn't just about serving the people outside your company.

By Scott Miller 

Providing exceptional customer service lies at the heart of the mission of many organizations. It is the central theme of books, articles, motivational seminars and business courses. Its value is undisputed in business circles. What many companies fail to focus on, however, is the primary path to exceptional customer service: internal customer service.

Internal customer service is the service we provide fellow employees and other departments within our own organizations, as well as our suppliers and anyone else with whom we work to get our jobs done. It is what we do when a colleague asks for information she needs to complete her main task for the day; it is what we say when someone from marketing asks for the addresses of good contacts; it is how we greet the vice president of sales when he walks into our office with an "I need something from you" expression on his face.

All these things can be seen as interruptions that take us away from our "real" jobs, yet they are vital to our company's success. If you see a gap between your "real" job and the needs of others in your organization, you need to rethink what your real job is. In helping others in your company, you help your company succeed. Here are some tips for creating an atmosphere of internal customer service:

1. Begin with your own perspective: Regard fellow employees and other departments as your customers. Understand that helping your colleagues do their jobs more successfully helps your organization and you. Therefore they are your customers. Treat them like VIPs.

2. View interruptions not as nuisances, but as opportunities to serve your internal customers. If you tend to view every interruption as a pothole in your road to success, reexamine those interruptions. If someone interrupts you to share gossip, that's a pothole. If someone interrupts you to ask for sales figures she needs to analyze sales team performance, that's a necessary lane change that will get your company closer to its destination. Learn to identify every real need from a colleague as a "necessary lane change," and think of every "necessary lane change" as an opportunity to move your organization closer to its goals. Take pride in helping your colleagues; enjoy your role in sharing information and providing services that help others get their jobs done. In most cases, your willingness to help others get their jobs done will lead them to readily assist you when you need it.

3. Exceed your internal customers' expectations. When someone exceeds your expectations, how do you feel? Most people feel delighted, excited, upbeat and very, very positive about that person and his or her organization. Think what you can accomplish in your organization by exceeding the expectations of fellow employees. If payroll asks for time sheets by 3 p.m., provide them by 1 p.m. so payroll can relax, knowing they have the time sheets in hand. If human resources asks for a list of important points to cover in an employee orientation, take time to think about it and provide a thorough list of what you would want to know if you were being introduced to a new job and company.

4. Say thank you. A simple, genuine "thank you" goes much farther to create an atmosphere of sharing and helping than two such small words would suggest. Even when it is a person's job to provide information or a product to you, tell them "thank you" when they have done it. Express your appreciation of their timeliness in providing it. Explain how it has made your job much easier. Show them your delight when they exceed your expectations.

I was immediately reminded of what was a very memorable counter to this way of thinking from an old colleague. This far away from the original conversation I forget the exact details, but over the years I've developed my own variant (it may be identical, I cannot say, but hopefully I've added my own nuances).

The trouble with the internal customer model is threefold. Consider:

1. It’s not equitable. Not everybody is a customer, some people are just suppliers (accounts, engineering, HR)
2. Those in the customer role are not paying, so they can often make unreasonable requests without consequences. As a supplier you can’t refuse their business, even if they’re a terrible customer. Real companies of course can pick and choose who they do business with. Further, you can’t charge them more when they demand unreasonable changes and extras.
3. For the most part, people treat suppliers badly (quote from former colleague: “I love when we outsource this crap to somebody else. I can just dump all this shit on them and not have to deal with it.”) *

Is this really what you want? I say no. I say you don’t want internal customers as your model. I say you want team as your model. Put yourself in the mindset of all being on the same team. That for me is a far more pleasant, appealing and realistic model.

* OK I made that up. But it's entirely plausible is it not?

When average is good

Calling something average is one step removed from calling it mediocre. But in the mathematical sense, especially when applied to a team’s velocity it’s a good thing.

One of the certain tricky bits for any new team trying out scrum is establishing the team’s capacity. That is, without an historic record of how many story points of work a team can complete you are somewhat in the dark as to what to aim for come sprint one.

For a team that’s been working together in the past but not estimating in points it’s possible they may have a fairly accurate gut feel for things, and that can be your guide. There’s likely still the novelty of having not just to develop but also test, fix defects and truly complete (according to your definition of done) but, with experience of working together in the past a decent guess can be made.

For a newly assembled team however, or one that’s less confident in figuring out how much of the backlog to bite off initially, my advice would simply be don’t worry. Just pick more than enough and accept that you won’t make it all. From what I’ve seen the first few sprints are very much a learning experience and part of that learning is going to include figuring out your capacity.

Given just three or four sprints the team, with good coaching and guidance from a competent scrum master, will have figured out a number of recurring key items: big stories are bad, transparency between those that code and those that test is key, getting things “done” means limiting how much you work on concurrently and, ultimately, a reasonable average velocity to work with for planning future sprints.

The team I am currently working with had quite an erratic velocity initially: 16, 8, 49 (yes really!) and then 26 points. After this we have stabilized nicely with an average of 24 points a sprint.

This “we dunno, we’re just gonna try it and see” approach to working out a team’s capacity for quality work is inarguably logical. However it doesn’t necessarily sit well with those from a command and control background, especially those with management responsibilities for the team new to scrum. They like detailed planning. Predictability. Commitments. Maybe even punitive action against teams that “fail”.

This is completely the wrong approach.

Like it or not, this is when managers need to decide if they are truly supporting scrum or not. If you are, then step up. Provide the environment your team needs in this early phase of the adoption. Make them comfortable with the new regime of trying, reflecting, learning and improving. Without that support you will stifle their ability to rapidly improve, and in turn lead to a less than stellar scrum implementation. Maybe even to a failed one. This happens a lot, and people revert to traditional, comfortable but ultimately unsatisfactory approaches to building software. Don’t let this happen to your team. Create the right environment and harness the power of average.

What's the velocity of a turkey?

“What do you mean, an African or European turkey?”

Neither, I mean a North American Thanksgiving turkey. And no, this is not some kind of cheesy Python-esque skit. Rather, as my favorite US holiday approaches, a particular truism of turkey roasting occurred to me: your 12-16lbs bird will need about 15 minutes per pound at 325F until it reaches an internal temperature of 160-170F.

So that, I would say is the velocity of a turkey – 15 minutes per pound. And the internal temperature is your “acceptance criteria” since I’m doing dubious cookery/scrum metaphors.

Just like a scrum team’s velocity is what it is, the same is true of our turkey. You can try and "turn up the heat" to get it done quicker, but in reality the results will suck. Your end result will be all dry (for the turkey) and the product flaky (for your scrum software team).

So, to get good results, work with the reality of the situation. Plan based upon your known velocity. If you want 100 points worth of features implemented, and your team’s velocity is 25 points a sprint, reckon on it taking around 4 sprints. If your family is hoping to sit down and feast at 1pm get that 12lbs turkey in the oven with enough time for it to cook and rest afterwards. You just can’t rush it. If you have other features you want within the next 4 sprints you are going to have to make some hard choices about what you drop from your current plans. You simply can’t have it all. Similarly, if there are other things you need the oven for, plan accordingly. You can’t fit everything in there with the turkey all at once.

As much as scrum is about prioritization, it’s also about accepting the reality of what your velocity tells you can be realistically done, and working with that. That means good planning, and sometimes hard choices.

Highly Distributed Scrum

I'm just about to finish sprint four as the Scrum Master for a team that has a higher than average number of distributed members. And I don’t just mean that we got two offices involved, one in the US and one in Europe or India. We have three software engineers spread around the Denver Metro area, all working from their individual homes. Then we have our Product Owner in Billerica, MA. Alongside her are a couple of QA engineers. Then we have some folks over in Hyderabad, India: another software engineer and a couple more QA engineers. Finally we have me, working out of my home in the Rocky Mountains above Denver, CO. That’s six locations for just ten team members.

Add in some interested stakeholders in Berlin alongside those in the US and India and you can see what we’re up against. I’m sure we’re not alone in such a setup, but I suspect that having a number of people, including the scrum master, “decentralized” (my organization’s term for those of us that work permanently from our homes) is less common than a team made of people from two or three offices.

It’s been a fairly interesting experience, and not in the “OMG-what-a-total-disaster-I-have-a-dozen-more-horror-stories-to-take-around-with-me-warning-people-about-the-folly-of-distributed-scrum” sense.

One of the interesting things about this experience was how incredibly smoothly it went. I may just be one of the luckiest scrum masters in the world. I can’t claim superior scrum mastery as the root of this easy transition. The team was a well-established, mature team that had been working well together for a long time. The relationships were strong and team members trusted and respected one another. They had already introduced many agile practices way ahead of other groups within the organization. It seems clear to me that this helped immeasurably as we layered scrum on top of what they were already practicing. The other contributor to this, which I discovered serendipitously earlier this week on Twitter is explained in this excellent blog post by Bob McWhirter. In it, he makes the distinction between simply being a remote worker, and being a remote worker in a distributed team. In a truly distributed team there isn’t a single center of gravity where a ton of conversations occur that remote workers aren’t privy to. Due to people being spread out, a distributed team necessarily uses communication techniques that support remote workers, such as mailing lists, IRC etc.

I think the most interesting thing though is that we haven’t really seemed to need any special dispensations for what is a fairly unusual team configuration. No tweaks to scrum; no special tools, tricks, techniques etc. I’m not saying those won’t necessarily come as the team reflects more on areas for improvement during future retrospectives, just that we’ve been able to get going just by sticking to the basic principles. Our only accommodation has been for the people in Colorado to start a little early and the people in India to finish a little late (it’s a fairly brutal time zone difference).

So how are we doing it? Well, here are the basics:

• We use Rally as our tool for agile project management, so that’s where our product and sprint backlogs are.
• We use a wiki to organize a lot of other material. It all starts from a team home page which links to all manner of useful things: our definition of done, agreement on how we document stories, the build server, source code repository, released software etc.
• We have a build server. This team’s current product is a rather old piece of legacy software that, presently, doesn’t lend itself to CI due to the lengthy build time. But it does still build every night.
• We have used http://planningpoker.com to do distributed, real time story estimation in points. It’s not quite got the natural feel and immediacy I would like, but it’s not half bad at all.
• We have daily “stand-ups” held in the morning (US time) which is evening for team members in India.
• Sprint planning, review and retrospective meetings are, similarly, timed for US AM and India PM.
• We have a phpBB discussion forum for the team set up…we also have an email distribution list that includes all team members. Interestingly the distro list gets all the action. I’m not sure if that’s because people are less familiar with using the discussion forum medium. I think it might be because there’s a greater immediacy to email based communication.

Interestingly the team has, through retrospectives, identified all the usual early issues I’ve seen other teams come up with during scrum adoption:

• Big stories are bad
• Spread out completion of stories during sprint
• Recognize and raise impediments ASAP
• Need the right people at the sprint review to make it truly valuable
• Be clear that we have commitment from people outside the team for stories that depend on them for success
• We have technical debt and we need to pay it down

We have, of course, faced some challenges; the two key examples being:

1. Meeting our commitments, i.e. getting stories “done done” by end of sprint. After a couple sprints we realized we would be much better off with smaller stories. Better to slip one small story than fail to finish two large ones.
2. English is a second language for a number of team members. With more spontaneous verbal and (due to our distributed nature) written communication there has, understandably, been moments of confusion. This isn’t quick to fix, but with more and more practice things can surely only get better.

All things considered, I’m very pleased to be part of what’s shaping up to be a really great scrum team.

Now, I’ve argued hard against distributed scrum before. That piece was mostly borne out of frustration, seeing teams of two halves. I still stand by the views expressed there. Having your whole team co-located alongside your customer still seems, by my experience, the preferable situation. The really interesting lesson for me here though was how, with a truly distributed team, Scrum can be made to work better than I anticipated. Moreover, it seems that by adding more team members at the office based locations we might weaken, not strengthen, our existing team. Perhaps we would do better to let those who are currently office based work from home too. With the right people, it seems that perhaps a fully distributed scrum team could trump a team split between two offices. I remain skeptical that they could better a fully co-located team. That said, I wouldn’t mind the chance to find out. It’d be a fascinating experiment.

#Positivember and the response continuum

Over my first coffee this morning I happened across the following tweet from Corey Haines:

"Today is day 2 of a month long positivity-fest! Love your life: #positivember http://vurl.me/WJU"

I almost feel bad for saying this, but it’s the truth: that handful of words irked me. Why? I think it’s because of my default interpretation. A month long positivity-fest sounded to me like some kind of rose-tinted denial of reality. Images of well-meaning but naïve parents that abound in a nearby town I’ll not name sprang to mind. The kind that work really hard to stop their children from expressing themselves when upset. The kind that want to insist that everything is always great. Even a cursory look at the psychological impact of that kind of suppression reveals that it probably ain’t healthy...

Then I read Corey’s blog post. It’s not (thankfully) quite that kind of hippy-dippy call to action. It’s much more an observation on how high levels of negativity are counter productive. How a concerted effort at positivity is the order of the day for advancing the notion of software craftsmanship. I’m up for that.

Still not sure I can quite buy into the notion of being completely positive about everything for the whole next month. Dropping the moaning and whining and negativity though is a good thing. It’s a bad habit I’ve had since forever. It’s easy to find fault and complain about silly little things.

A bit later, as I was walking the dog, an idea popped into my head that might help explain why the “all positive all month long” concept is hard for me. I believe gunning for all out positivity is an extreme reaction to the unpleasant other end of the scale. I think when we respond to something, that response lies somewhere along a continuum a bit like the following:

Sabotage → Meanness → Negativity → Apathy → Constructive Criticism → 100% Positivity

Reducing things to a binary negativity/positivity option over simplifies the matter. It’s the stuff to the left of the middle that’s toxic. To the right is great. I like to think I’m over there more and more these days, but still have plenty of work to do.

Not too long ago I read “The Lazy Manifesto” blog post by Leo Babauta on his zenhabits.net website. Items number 5 – “Do less complaining and criticizing” and number 7 – “Do less judging and expecting” are, for me, a more palatable way to think about what I believe Corey is trying to achieve with #postivember.

I hope I'm not too far off track. Even if I am a bit, those two ideas resonate with me and since making a conscious effort to try and adhere to them I have to say things feel good.