Guild Blogs

Cory has a great post titled: Scrum-ban | Lean Software Engineering. In it he describes how a team can take advantage of kanban within a Scrum environment.

While I am sure that there will be those who insist that Scrum doesn't need to be improved, there are those of us who learned Scrum, practiced Scrum and are aware of it's limitations and want our teams to get even better.

Personally I like kanban for the context I work in. When I explain how we develop software I always try to make sure the other person is aware of the context I made my decisions in and how in other contexts I would not make the same decision.

For instance we do not estimate each individual story (although for a short period we did 30 second estimating). We have collected enough data about our performance that we know how many stories per month we complete (~10). Part of this context is a stable team that knows the software and a mature product.

Back in the day I lead contract teams doing work for state and local government. In that context I would go back to estimating because the contracts tended to be fixed price and the team was pulled together just before the project started. Different context, different practices.

Previously I posted about my new V-Strom which is a nice bike. However, after taking it on something more difficult than gravel roads and compared to my wife's Honda CRF150 I knew I needed something much lighter, more dirt oriented, but could still be ridden on the street.

After much research I initially narrowed it down to the Kawasaki KLR 650, Honda RX650L and the Suzuki DR650. The KTM and BMW were out of the picture because of cost. My lingering concern was the weight of the 650s.

So what did I buy? A Kawasaki KLX250S!.

Why did you buy such a small bike after owning (and enjoying) those liter street bikes? Well, basically it was time spent riding the CRF150. I knew that the 250 would be able to take me anywhere I wanted to go, and it easily does the legal speed limit. What more do you need? (well actually I'm saving my pennies for a Ducati ST4 for my wife and I to do 2-up riding.)

Hank Wallace turned me on to a post by Allison Shapira where she summarizes a key point from Rob Walker's writeup of the Blue Man Group - the "Why To" manual.

This "Actors' Journal" is not so much a how-to manual as a why-to manual; it's not about stage directions, but rather tells the story of the show step by step, from the point of view of the Blue Men. As a decoding and deconstruction of Blue Man's at-times baffling, even mystical behavior, it's a fascinating document, thick with references to everything from Being There to George Bernard Shaw to Robert Motherwell to the caves of Lascaux. Some explanations are straightforward ? "The Blue Men are not aliens" ? and others are more subtle, as when the trio's harmonic "three as one" relationship is described in terms of "blesh," a mix of blend and mesh borrowed from Theodore Sturgeon's science fiction novel More Than Human.

What would a "Why To" manual look like for a development team?

Miško Hevery has written a great summary of some basic coding rules for testability in his post Writing Testable Code.

I love this quote because every time I introduce unit testing to someone who has an existing code base you can see this in their eyes:

"I understand how to write tests for your code, but my code is different"

He goes on to list the rules most often broken by developers that make unit testing hard in his top ten list:

1. Mixing object graph construction with application logic
2. Ask for things, Don't look for things (aka Dependency Injection / Law of Demeter)
3. Doing work in constructor
4. Global State
5. Singletons (global state in sheep's clothing)
6. Static methods: (or living in a procedural world)
7. Favor composition over inheritance
8. Favor polymorphism over conditionals
9. Mixing Service Objects with Value Objects
10. Mixing of Concerns

I haven't posted much about my enjoyment of motorcycles, but yesterday I took the next step in my ongoing series of motorcycle experiences.

My new bike is a 2005 Suzuki DL1000 otherwise known at the V-strom. I'm looking forward to getting to know it a lot better. The previous owner put a lot of aftermarket farkles on it including heated grips (incredibility useful as it was 40F on the way home) and a custom seat which seems great so far.

For the last few years I've been riding this 1998 Ducati ST2, which has been a wonderful bike, but as I get older the position gets more uncomfortable the longer I go. And lets just say it is a tad expensive to maintain.

Back in the day I rode one of these to and from work. Things have sure changed.

Jason Goldberg has a great post on some of the things he learned while CEO of Jobster.com.

1. The CEO's job is to create value.
2. Try to ride some powerful existing waves vs. just creating new waves.
3. Technology companies are all about the product.
4. Related to #3, the rapid iteration model (ship early, learn from usage, adjust) works well for consumer services but works not as well for B2B services.
5. Hire people who are passionate about the specific problems you are trying to solve.
6. You must get close to your users and customers and live their personas.
7. The value of your company is directly related to your capital efficiency.
8. In the early days, I highly recommend that you force your startup to be resource constrained.
9. Don't listen to outsiders who tell you to go faster and ramp sales and marketing.
10. Avoid field sales in favor of telesales.
11. Once you are in the market and have established some measurable and repeatable levels of success, #11 negates #8 on this list.
12. Have fun.

Planning on starting your own company? Here are some good points to consider from High Tech Strategies - Ten Reasons High-Tech Companies Fail

• Lack of Market Focus
• Excessive Pace of Product Improvement
• Incomplete Products
• Undifferentiated Products
• Channel Mismanagement
• Failure to Establish the Right Competitive Barriers
• Using Price Alone To Drive Market Transformation
• Improper Use of Advertising
• Misinterpretation of the Technology Adoption Lifecycle Model
• Irrelevant Market Research

Jeffrey Phillips wrote a nice post on Accountable for production not attendance. In it he argues that most knowledge workers should be treated like virtual workers – they should be held accountable for their production, not their attendance. The implication is that the results of the work is far more important than when or where they work. This is something I have given a great deal of thought to and agree with in principle. However, the focus here is on the individual. What if the individual works on a team?

Teams and times
Generally I find there is a happy medium when the team is allowed some flexibility in the individual schedules while maintaining some amount of schedule overlap so that there is a guaranteed time when everyone one the team is present. In my experience this is typically 10am – 3pm. For highly interdependent work I have seen team members on healthy teams adjust their individual schedules to overlap significantly so as to not impede individual tasks purely because of individual schedule preferences.

Teams and locations
Location seems less flexible to me. Certainly technology exists to allow teams to access all the resources they may need from far flung locations, but sometimes you need more that access to just electrons. Just ask someone who needed a flaky server rebooted and couldn’t get in contact with someone who could actually flip the power switch. Admittedly access to physical devices varies by team. My current teams deal with lots of hardware add-ons and regularly visit “the lab” to ensure the product is working as expected. Whereas in my previous position the entire team could have been airlifted to Fiji and it wouldn’t have mattered much (other than their tans).

Teams need to work together
Now teams could be distributed or virtual, but I believe that teams work best co-located and face to face. The team’s output is still of primary importance, but because they are working together the where and the when become important as well. It is harder to work together if part of your team is either at a different location or a different shift or both. And if it is harder to work together the output suffers and the results are what really count.

I attended AONW last year and had a fabulous time. It was great to reconnect with some of the local practitioners and have some really interesting conversations and be introduced to new idea. If you can make it I would highly recommend attending this year. Remember, attendance is limited to the first 100 people, so sign up soon! Look me up and I'll buy you a frosty beverage of your choice.

Here is a flyer for your office