New (old) blog
As of last night, I’ve started posting on my new blog, chrissimmons.ca, which is in the same location as my original blog. Please update bookmarks / RSS readers accordingly - there’s not going to be any more content at this address.
Tumblr was good to me, in that it was easy to set up, allowed me to easily remotely post, and was new enough that it helped encourage me to write during November, but it’s got some drawbacks - lack of comments, sketchy uptime, and limited extensibility. Going back to my own hosting puts me back in control, and now that I’m actually posting more often, I’m a fan of that.
Thanks for reading!
This Week in Kanbandev - Jan 5, 2011
This week was a bit of a slow one on the list, but it made me realize that I’ll never be able to summarize every interesting thread on busier weeks. As such, I’ll commit to commenting on at least three.
Kanban is an evolutionary change system, and as such it takes time to decide and act on change. This thread questions Kanban’s incremental focus, as compared to literature and anecdotes that prefer a “big bang” change. Larger organizations may be interested in having a common development process, thus discouraging incremental improvement, and sometimes (such as when an organization is in dire need of immediate change), Kanban should not be the preferred method of change. This is followed by some interesting discussion of learning as a motivator (as opposed to urgency), examples of how Kanban can be a fast (though not instant) change agent, and the emotional aspects of change, including a reference to the Satir model of change that I’ve mentioned before.
This was the most popular thread of the week, with over 40 posts at last glance. The crux of it was whether BVI (Business Value Increment) should replace MMF (Minimally Marketable Feature) as the dominant term used for a small, complete, useful bit of functionality, and whether there should even be a definitive term for such a concept. The concept has some detractors, who note that BVIs are almost necessarily variable in size, and such variability can disrupt flow. Several alternates are proposed, from replacing the term with “Smallest Responsible (or Valuable) Feature” (with the caveat that “feature” may be too heavily stressed for teams such as mine that have maintenance responsibilities), to supplementing the term with concepts such as a “Minimum valuable feature”, an idea borrowed from the lean startup movement. In the end it may just be a nomenclature thing - as long as the idea is well understood and explained, the exact term may not matter. Consultants, and those trying to convince others of the value of such an idea, may want to converge on the best possible term, but for people like myself who only have a small group to work with it’s the idea behind the term that’s much more important.
This was a rather short thread, highlighted by an experience report that saw cycle time (that is, the amount of “active time” spent on a task) vary independently from estimated story size, but instead saw it correlated to the start date - stories that were started later into the Kanban trial were uniformly shorter in duration, regardless of estimate. This calls into question the usefulness of estimates, which were being measured in story points (2, 3, 5, 8, etc.). Although the value of estimates may be an issue here, with too much faith being based on the precision of numeric estimates instead of a “big/small” comparison, the real issue could be that as time went on, WIP decreased. When WIP decreases, the cycle time of each item in progress decreases, as a direct consequence of Little’s Law.
In addition to the thread summaries above, there were some links of note this week.
- Bringing Excellence to Service Delivery (David Anderson, LESS 2010)
- Alan Shalloway’s blog post on Big Change Up Front
- A new Yahoo! group, Kanban for IT/DevOps
This Week in Kanbandev - Dec 29, 2010
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!
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).
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.
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?
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!
Rounding out NaBloPoMo
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!
The right way to network
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.
Black Weekend
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.
Whither the Change Agent?
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.
Sleepy Friday - Firsts
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!
Reading Kanban
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.
Teacher for a day
Today 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.
