Mind your language!

I find it hard to pick out a favorite quote from Guy Ritchie’s cult movie “Lock, Stock and Two Smoking Barrels.” It’s just chock full of great lines.

Ignoring the obvious masterpiece from Rory, one exchange that I’ve always remembered with a smile is between Harry’s enforcer, Big Chris and his son (who is of course known as little Chris). They’re visiting someone who owes Harry money, and Big Chris’s son rifles through the indebted man’s belongings. Upon finding a serious pile of cash he exclaims: “Fuckin’ hell John, do you always walk around with this in your pocket?”

Big Chris, despite the dubious London underworld he and his son inhabit appears to have aspirations for his son to remain reasonably polite. He replies, “Hey! You use language like that again son, you’ll wish you hadn’t!” Unless you’ve seen it, it’s hard to appreciate the energy with which that warning is delivered.

Despite immersing myself in agile and Scrum and the language that comes along with that, and despite doing my best to socialize it over the last couple of years in my engineering group I think there are limits. Just as Big Chris doesn’t necessarily want his son to use the lingua franca of the underworld everywhere, I think you need to consider how far outside a development team you use agile and scrum vocabulary.

One of the three legs of Scrum is transparency. But being too transparent isn’t necessarily a good thing (think body scanners in airports, for example).

Maybe, if your entire organization has decided to operate using scrum, in everything from sales and marketing to operations, HR and accounting as well as engineering then you can happily talk about daily scrums, sprints, points and stories and velocity. But if they haven’t, then I think you have to balance carefully the education of those groups with whom you interact and the language you use.

For me, there are three key pieces of terminology that I am, with hindsight, wondering about the wisdom of sharing widely.


Story
Yep, I don’t think we should be talking about stories. Now don’t get me wrong. That doesn’t mean I don’t think we should be using them. On the contrary, I’ve said it before and I’ll say it again, one of the most profound books for me as I was learning about agile was Mike Cohn’s "User Stories Applied."

The concept is great. As a unit of work it’s perfect. For organizing requirements it’s helped tremendously.

However, as a term to use with unsuspecting business stakeholders, customers and so forth I’m not so keen. Frankly it sounds rather ridiculous. I’ll stick with feature, thanks very much.


Sprint
Few people with practical experience of dividing your development up into fixed duration timeboxes is a bad thing. But do we have to call it a sprint?

One of the things I like about Scrum is the fact that done right nobody’s having to dash like a lunatic to cram in all the last minute jobs to ship your product. Instead what we have when we do it right is a predictable, sustainable, humane way to utilize teams.

Sadly sprint conjures up anything but that vision.

These days I prefer to describe that we work in short two-week cycles, and if I need a short snappy name for them then iteration works just fine.


Points and Velocity
I’ve pulled these two terms together as they really go hand it hand. At least, if you’re estimating stories in points but not measuring your velocity you might want to reevaluate what you’re trying to achieve.

And these two are a little different for me than story and sprint. Whereas those are just unnecessarily goofy in everyday conversations with the wider business, and alternatives can serve us better, points and velocity need very careful handling, whatever you call them.

Here’s the problem – points and velocity are a tool for the team to be able to evaluate their performance, to plan and make reasonably firm commitments. Stakeholders outside the team should be concerned more with what gets done and in what order. The Product Owner and team together can use points to respond intelligently to new requests, to switch things around, and figure out what fits where and what needs to get dropped.

But start telling your stakeholders too much about average velocity, the points involved in a particular story and you inevitably risk them starting to focus on points rather than the “what should we do” and “what order should we do it in” issues. Perhaps in a really mature agile environment were a deep understanding of what points and velocity are for this wouldn’t be an issue. But early on in an agile adoption I think care is needed.

Too much data on story sizes in points, team velocities and so forth risks the following questions:

“Can’t you do more points per sprint? Why didn’t you make your commitment? Why has your average velocity dipped? Why does the tracking team have a higher velocity?”

Those kinds of discussion are not the most value one can extract from a stakeholder. I don’t want to see agile teams micromanaged by a group of well meaning people who know nothing about agile software development. But we are baiting them into doing exactly that if we report too much detailed data about points and velocity. Before you know it they’ll be looking at your definition of done suggesting we don’t need to do unit testing and who knows what else…

I say keep the dialog with stakeholders confined to steering the product, negotiating the relative priority and let the team use points and velocity data to communicate what can be done for any given release.

Put another way, what do you really want customers and stakeholders to concentrate on? The minutiae of your process? Or innovative product ideas and how they should be prioritized in the backlog?

Fully distributed Scrum

(Or, "How we pitched the idea of letting everyone on our team work from home and got the thumbs up")

---

Back at the beginning of November I wrote about my recent experience as the scrum master on a highly distributed team.

For those that didn’t read (or don’t remember) that post, a key thing to know is that the team is comprised of several people who work from home. I ended that post (partly tongue in cheek I admit) saying how it would be interesting to take those team members that were still office based and have them work from home too. Well, starting early 2011 we’re going to give it a try!

The original suggestion was first seriously discussed in a team retrospective. On the premise that it’s easier to offer an apology than ask permission I sent the appropriate managers in our group an email indicating that the team had decided we were all going to work from home next sprint. That didn’t fly. Which isn’t surprising (although it was worth a try, or at least entertaining, no?) and a more considered proposal was requested.

Myself and the team duly worked on preparing a properly coherent argument, supporting data, benefits we expected, a concrete description of how we would run this little experiment and details on how we would measure the success (or otherwise).

I know there must be many other teams trying to reconcile the demands of their managers to “do agile” and also “leverage offshore resources” so I wanted to share details of the proposal that helped convince ours that trying the rather radical proposal of sending everyone in the office home might help.

What are we trying to do?
Before we go anywhere further, it’s worth properly answering this question. Lest there be any doubt, this isn’t about folks wanting to get up late, watch daytime TV and get their laundry on during teleconferences.

This is an authentic endeavor to make our team work better. You can argue till you’re blue in the face about the benefits of team co-location, or the silliness of splitting teams into onshore and offshore components when you’re trying to simultaneously implement Scrum, but the fact remains that many, many organizations are still going to insist you can’t move the furniture and you have to structure teams this way.

Therefore, if we have to live with this, we’re going to make it work as best we can.

At the heart of much agile advice is an emphasis on communication. The trouble is, with team members scattered across different timezones and locations, communication gets clumped into localized groups. People on the edges miss out. By putting everyone on an equal footing (working from home) everything becomes more equitable and information sharing is normalized allowing for a better functioning team. At least, that’s what we believe, and what we’re trying to do is prove that out.

“Craft a philosophy and live it.” – Umair Haque, bubblegeneration.com

How did we approach this?
Our presentation covered five key areas:

• Why did we want to try this idea of everybody on the team working from home?
• A list of benefits, beyond simply the team working ‘better’ that we anticipated
• A description of how we wanted to run the experiment
• How we intended to evaluate the outcomes
• The support we needed to get this going

I’ve already talked about the why, so let’s look at the others:

Anticipated benefits
Besides the hoped for improved communication, there are some other interesting and very tangible benefits we anticipate.

As I write this blog post the time in Colorado is 2.54pm. Meanwhile, in Hyderabad it’s 3.24am the next day. We have quite the time difference between some of our team members. Before Daylight Savings Time (DST) came to an end in the US this year it was just possible (if not entirely pleasant for everyone) to have a daily scrum via phone with all team members present. Now however, since Indian Standard Time doesn’t adjust, the earliest we can hold our daily scrums is just unreasonably late for our colleague there to attend every day. Although they do stay late to attend some of the sprint planning meetings and sprint reviews they’ve been missing a lot, including retrospectives.

One very worthwhile thing we can do operating as a team that works from home is create a more humane work/life balance for people. This will pay particular dividends for our colleagues in Hyderabad, allowing them to work the majority of their days at normal local business hours. They can they stop just early enough and save the remainder for meetings in the evening. Although nobody particularly wants to have to regularly work super early or super late hours, this is a much better arrangement than having to be still stuck in an office at 9pm at night.

In addition, there are another couple of benefits we see. One is immediately realizable, the other perhaps a longer term proposition. They are reduced environmental impact through less travel and reduced office space needs.

An article in Forbes magazine in 2008 indicates there were as many as 17 million software developers in the world at that time.

More than 2 million of them are in India and the US is approaching 3 million.

Most if not all of these people spend time in cars or other transport every day commuting to and from work.

Indian emissions standards for motor vehicles lag about 5 years behind Europe, and in the US of course the majority of us love our gas-guzzling SUVs.

We may not be able to keep millions of these people off the road, but by allowing those that work in our team to do their jobs from home we can have a small but positive environmental impact. Who knows, maybe this innovative idea can spread.

As for the office space thing, if you can establish a team working at home, with perhaps continued but minimal office visits as needed then do you really need such large premises? With enough teams operating this way you could save on what you lease, on what you heat and so forth.

Running the experiment
Being a Scrum team convinced of the benefits of incremental and iterative development, we naturally intend to use the same approach to this experiment. Starting early 2011 we will try a sprint with everyone working from home.

At the end of that sprint, a large part of the retrospective will obviously explore how things worked. We’ll be asking ourselves questions like:

• How well did that work?
• What work well and what would we like to change?
• Can we fix the things that didn’t work well?

If we think it was worthwhile and we can improve those aspects that didn’t go too well then we’ll repeat another sprint with any changes we need. With this approach we can pretty quickly home in on how to do this well, or equally quickly conclude that our original arrangement with two-thirds of the team staying office based was better.

Evaluating the outcomes
Many years ago I used to quite like the idea of capturing data you could analyze to objectively evaluate things. Peter Drucker is renowned for saying “What gets measured gets managed.”

I’ve since learned that if you measure the wrong things in the wrong ways then it’s more a case of “what gets measured gets gamed.” Regrettably I’m not renowned for saying that. Maybe one day.

However, we do need some way to determine how our experiment is going.

Agile thinking provides us with a few simple tools that we can employ: velocity, burn-up charts and cumulative flow spring most readily to mind. To some extent though there is the possibility that these could indeed be gamed, or unconsciously given treatment to provide the desired out come.

So besides those, we will also be looking at some other areas:

• PO and stakeholder satisfaction. From their point of view are things better, worse or pretty much the same?
• Team satisfaction. Do we feel that things are better, worse or pretty much the same?
• If the experiment pans out well enough that we conduct a whole release with people working at home then we can utilize SLIM Metrics to observe productivity benefits.

Required support
Of course my team is not an island unto itself; we needed support to undertake this. First and foremost we needed the support of our management. Luckily the director of our group is open to innovative ideas and. After our presentation to him and a series of questions that the team was able to answer was willing to permit this experiment.

In more material terms we pretty much had all that we needed. People have broadband connectivity and telephones at home. They have quality spaces to work in. We do need to configure a few machines for remote access, and a few people needed new laptops. Other than that though, we’re ready to go.

In conclusion
The whole team is excited to try this. I think we’re onto something. I’m eager to see what our actual experience is like. Will things be better or just different? Next year, after we’ve run this experiment for a bit I’ll report back on how things have turned out.

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.