Geek Philosophy

Buoyed by the success I had in sticking to a post-a-day schedule in November, one of my “end of year personal goals” (new year’s resolutions, you might call them) is to write more. Another goal is to keep more in step with the current state of the art of the Kanban community. Combine the above with positive feedback I received about my summarization ability, and you get a new series – This Week in Kanbandev, a weekly update where I discuss some of the happenings on the always-interesting Kanbandev mailing list.

The initial goal of this series is pure self-improvement. It will get me writing, and it will get me reading Kanbandev, two things I’d like to do more of. Summarizing and explaining my reading will also help me solidify what I learn. These posts may be useful to some people, but that’s purely by accident . I can’t promise not to color my commentary with my own personal worldview, knowledge or experience (or lack of any of these), but I’ll try to call out any relevant biases when I can.

Now, onto the first week!

• Why should we size?

The value of estimation gets discussed quite a bit on Kanbandev. This thread reinforces the fact that Kanban doesn’t actually say anything about whether a team should estimate or not – if it provides value, keep using it. That said, there’s a heavy bias (possibly justified) on the list against using detailed estimates for planning. Personally, I’ve gone away from doing estimates for small, flow-based projects, and for larger batches of functionality I’m trying to shift towards using “t-shirt sizes” (Small, Medium, Large).

• Working on one item vs. multiple items

Limiting work in progress is one of the Core Properties of Kanban, so of course it gets a lot of mind share on the list. This conversation quickly turns into a pretty standard checklist of the steps to go through when trying to determine a WIP limit – keep policies explicit, measure lead time to gauge effect of changing the WIP limit, and keep stakeholders involved in the process and informed of the results.

• John Seddon about “Lean”

This thread got into the semantics of Lean, a mindset and series of tools that are in many ways a spiritual predecessor to the Kanban Method. The thread got a bit derailed by cries of commercialization, but it did spawn a great discussion on the topic of leadership – who are the leaders of Lean community? What does it mean to be a leader?

• Batching up releases… necessary or just patching over a symptom?

This was the most interesting thread of the week, in my opinion. I first heard of the concept of continuous deployment when I saw Eric Ries speak 18 months ago at the Agile Vancouver Lean mini-conference. The idea makes sense, especially with the “Stop Starting, Start Stopping” focus of Kanban, but there are differing opinions as to whether single-issue deployment is always a worthwhile goal to try to attain – for my current team, I prefer batches, albeit small ones. This thread also forked off into interesting discussions of the negative aspects of the phrase “Kanbanista” (summary – don’t use it, it fosters cliques and ossification), and what to do when your Kanban board says you’re overstaffed (summary – layoffs are sometimes the answer, although give new products a shot too).

Well, that’s it for week one. Next week, I’ll take notes as I go so I don’t need to re-read every thread of interest!

According to my calendar, it’s the last day of November, and thus the last day of NaBloPoMo. Time to reflect on the month.

I’ve written more this month than in any previous month, and I think I’ve written (mostly) better content. Sure, there’s been some filler, but I’ve also put out together what I think are some good posts. I’ve figured out what I’m decent at writing about (summarizing presentations, explaining concepts) and what I don’t really like doing (“haircut blog” style personal updates). Without the obligation of posting every day, I can focus more on what I want to write.

So, what now? I may take a couple of days off, but then again I have a few topics kicking around in my head that I’ve been wanting to write about but haven’t had a chance to. I also want to start posting summaries / mind maps of various books I’m reading. There’s plenty to write about, and I’ve gotten pretty positive feedback from people I respect, so I hope to keep doing it. I’ll also probably move back to WordPress, since Tumblr doesn’t support comments and the interface isn’t that much more complicated.

Thanks to everyone for reading this month!

I didn’t wait in any lines this past week for a good deal on a TV, but my wife and I did spend a large part of the weekend shopping. We had reason to be downtown on Saturday and at Metrotown today, so we took the opportunity look around and take advantage of some of the deals.

The total damage wasn’t too bad – the weekend came in at under $200, and that includes 4 sweaters, a sweater dress (for my wife), and tickets to see the newest Harry Potter flick (not bad – dark, action-packed, and wizardy). Walking among the thousands of shoppers was an experience, as I usually tend to avoid shopping at busy times, but I think I’ve had enough. We don’t really do Christmas gifts, so I’ll do what I can to not set foot in a mall until next year – unless, of course, a Boxing day TV is in my future.

I’ve spent the last few weeks in occasional correspondence with someone who’s interested in working at my company. Their skill at networking and communication, especially communication of the “I want a job” variety, is worth sharing.

I met this person (subsequently referred to as “X”) at a Q&A session with a panel I was on. This session took place at a local university as part of a day-long career-building workshop. I talked a bit on how I had used my technical degree to further my career, and fielded several questions about what exactly I do at work. After the session ended, there were still a few students (including X) interested in chatting about what my company does and how my team develops software. I love chatting about these things, so I stuck around for an extra half-hour, handed out some business cards, and called it a day.

Usually, when I hand out business cards (always on request – I don’t foist them on people), I’ll hear nothing back from about 95% of people. A few may follow-up in a week, either through adding me on LinkedIn or emailing me and asking what opportunities are currently available at Sophos. The latter often comes as a blunt question such as “are you hiring?”

X has been different. The follow up email came a few weeks after the initial meeting, but it was asking about different parts of the company’s technology and how those fit in with X’s interests and specialties. It was only after a few back and forth messages that X expressed interested in working at Sophos, and he did so in a way that focused on the specific skills he had that would make him a valuable addition to the team. All of the correspondence has been very professional, detailed, and yet succinct – X realizes that I’ve got better things to do than read an autobiography, but relevant educational and career highlights are always welcome.

This is how you network, how you successfully take advantage of a friendly professional resource such as myself. Sorry, eager job hunters of the future – X has spoiled me.

One of the roles that I see myself growing into as time passes is that of change agent. I don’t mind speaking up when I see problems, I’m dedicated to seeing problems solved even if it won’t happen immediately, and I don’t get discouraged if there is resistance or setbacks when implementing change. I’ve been lucky enough to be leading a team where I can experiment with new ideas and have a lot of control over how my team works.

However, when I look at professionals in my field who are interested in team and organizational improvement, they are almost always consultants. Does it have to be this way? I can see the benefit – moving from company to company, the rate of feedback is much faster, and you can learn what works and what doesn’t work much sooner than you could working within the same system. Also, there’s always this old quote from Deming:

“As a good rule, profound knowledge comes from the outside, and by invitation.  A system can not understand itself.”

Is it that companies refuse to accept major change initiated from within the organization? I’ve heard this repeated many times (though I’ve never seen any studies), so that could account for the lack of “famous” internal change agents. It could also be that people who are genuinely good at turning companies around demand too high a price to be a permanent employee. Alternatively, maybe there’s an inherent bias of contractors and consultants to be more vocal about their methods, previous clients, and successes, as it helps them gain new business.

All that said, I like working in a single company and have always thought that I’d hate being a consultant. That distaste is changing a bit – I think it’s mostly the gathering of clients / insecurity that I’d dislike, as opposed to the nature of the work – but I’m still not very interested in jumping ship and becoming an entrepreneur.  Of course, all of this may be due to inexperience. I’ll be the first to admit I that have relatively little experience in the industry.

For now, I’m still in a good place. I run a small team in a large company, and there seems to be some opportunity for change that I may be able to help out with, so I’m definitely not out of growth options in this area. I try to keep as up to date on modern methods as I can by reading books and forums, talking to other professionals, and airing my ideas publicly so they can either be torn down or validated. Still, it’s interesting to think of the future, and wonder if I’ll ever have the desire (not to mention capability!) to go solo.

Well, it’s Friday night, I’m half-asleep on the couch, and I’m only posting because I’m so close to finishing NaBloPoMo and I want to see it through.

Things I did this week that I haven’t done before:

• Installed high-end server hardware myself. The network card had 2GB of RAM!
• Drove in snow in Vancouver. It was pretty crazy here (for Vancouver, at least), but the new car held up well.
• I went to visit a puppy for adoption. We didn’t end up going for her (she’s not our type – sorry, Sophie!), but we’re looking forward to doing more looking.
• I ate cauliflower. Intentionally.

Yeah, it was that slow of a week. Hopefully I’ll have the time and energy to come up with something more interesting tomorrow!

Today (November 25) I did a guest lecture for CPSC 310, the software engineering class at one of the local universities that’s compulsory for the computer science degree program. I took this class when I did my degree there, and I really disliked it – it was in the process of being redesigned, I believe, and we only got through about half of the required material. At the time, it convinced me that I hated process and just wanted to keep my head down in the code. How times have changed!

The curriculum has changed since I took the course, although it is still mainly focused on traditional software engineering techniques. I was quite excited this past summer when I was asked to give a guest lecture in the class on the topic of what I do at work. I’ve spoken at schools before on the topic of Agile development, but never in a software engineering class. Apparently I did a passable job, as I was asked back to lecture this term.

I’ve never given the same presentation twice (although I’ll have an opportunity to do that soon), so I still have troubles with timing and fitting in all my content, but I think today’s talk went well. It was 50 minutes, less than half the length of the talk I gave this summer, so I had to cut out a lot of content. I know what I’d do next time to fix up the pacing, so hopefully I’ll get another chance to try it out.

Now that I’ve given a talk or two to professional groups, I actually find student groups more of a challenge. With professional groups, I can assume a certain level of base knowledge and experience, and if someone isn’t familiar with a term they’re quick to ask for clarification. With students, I’m often dealing with people who have never developed software professionally with a team. If I was talking about programming languages, that wouldn’t be an issue, but since I talk about shipping software, team dynamics, and process, I’m always scared that I’ll leave people behind. Students can also be quite timid, so if they don’t understand something they’re not necessarily going to put up their hand.

I don’t mind talking to students, and I want to get better at it, but to do that I’ll need to find a balance of easily-understood terminology and widely applicable concepts. In the meantime, I look forward to my next two presentations, both of which will be in front of professional audiences.

After seeing the pile of books I want to read grow and grow, while not actually reading anything due to indecision of what to start next, I’ve decided to implement a reading kanban. I’ve never really used a personal kanban, but I thought that having the titles I want to read laid out in front of me (sorted by category) could spur me to action.

To start out, I think I’ll have allow myself to have three titles in progress – one fiction book, and two books out of the three categories of technical, business, and personal growth. I’m already well into a personal growth book (How to See Yourself As You Really Are), and I’m just starting a business book (The Five Dysfunctions of a Team). I have a raft of technical and business books to choose from, but limiting my WIP will ensure that I actual finish some of them. I only have 2 or 3 fiction books that I’m considering, so I’m less concerned with burning through those.

I’ll try to write up my thoughts on any books I find particularly interesting, and will also try to report back in a few months to see how the book kanban is going.

I’d like to start off this post by saying that I’ve never worked professionally in a company that uses business analysts (in the IT sense, #4 on the Wikipedia page) or UML. This is just speculation, and I’m tagging it as such.

I had lunch with a business analyst today (a friend of mine from university who I haven’t seen in a while), and it was really the first time I’ve had a chance to talk to a traditional IT business analyst and find out what they do. The role sounds like something that would be required – find out requirements from customers / stakeholders, and translate those requirements into formal specifications for developers. How else are the developers going to know what to write?

One way to improve this inherently error-prone process (hand-offs are hard!) is to use a formal specification mechanism such as UML. This gets rid of the ambiguity inherent in human language, and often provides a significant amount of design in the form of object hierarchies. This ensures that the developers are creating a system that is as close to the business analyst’s vision as possible. However, I would say that this is solving the right problem (disconnect between the customers and the developers) in the wrong way (even more up-front specification).

Of course, Agile has an answer to this, and this is how my team works – we have an on-site “customer”. Our product manager acts as a customer surrogate, talking to as many customers as possible (we have thousands) and understanding the market. Then, instead of writing a specification, he works in conjunction with the developers to evolve the ideas and product vision. There are no detailed diagrams, no lengthy descriptions of functionality – just a conversation, a continuous design and refinement of the ideas. Things are more open to change (and thus improvement), and can change more rapidly due to not needing to update extensive documentation.

I would say that in a way all members of my team are business analysts, as we are all trying to understand our customer needs and solve them through our work.