Doing a talk about Kanban at Skills Matter in London this Wednesday

I’m holding a talk on first impressions of a team moving from Scrum to Kanban at Skills Matter in London this Wednesday (25th of November) evening. Sign-up, it’s free.

 

A simple rule to decide on any action or use

Waste is pervasive in todays society: in companies, in the public sector, in organisations large and small. It’s a shame, because there is a very simple decision criteria for any action or use of any product/framework that is universally useful in almost any situation where a productive pursuit is at hand.

It is simply a question you should ask. Does your action or use of a given product or framework:

1. Add value
2. Subtract value
3. None of the above

If the answer is anything but 1), you are wasting your efforts. If something does not add value to the outcome you are looking to achieve, it is waste.

Always be adding value. And always cut out waste where ever you see it.

 

Conditions of Dissatisfaction

A friend and I where jokingly playing around with the idea of “Conditions of Dissatisfaction” as an alternate to Conditions of Satisfaction.

Maybe the idea isn’t so bad after all as a gimmick to avoid scope creap and keep focus on delivering minimum marketable product: With Conditions of Satisfaction there can sometimes be an urge to throw in everything and the kitchen sink in how they are defined. I’ve seen CoS spanning several pages.

Using “Conditions of Dissatisfaction” and asking “What would really piss you off if the feature was lacking it?” might promote a more minimalist, functional approach.

It started out as a joke, but maybe it is worth picking for ideas as a concept.

 

Starting a new blog: Adventure Capitalist

I have started a new blog: Adventure Capitalist.

The implication for this is that this blog will get even more of a software development & software project management focus (with the occasional gadget talk).
The more entrepreneurship and life hack related content on the other hand will move over to the new blog.

The new blog will be focused more on my entrepreneurial pursuits and interests, while at the same time covering life hacks/lifestyle design and travel – it will basically be a diary of thoughts, experiences and ideas as I strive to find greater freedom in my own life, and by freedom I mean freedom in the sense of doing more of the things I want to do (money is a means to that, but definitely not an ends).

 

The mistake most developers and development organizations make

The mistake most software developers and software development organizations make is the one about what they are in business for: Most will think they are in the business of building software. That’s the wrong focus, they are in the business of delivering software.

What you do is not your purpose, it is a means to an outcome. The difference is subtle but important. Focusing on what you do as the purpose of what you do will result in a process mindset rather than outcome mindset. What and how you do something is unimportant as long as you deliver what and how you promised (there just happens to be means that are more and less effective..).

It might seem like I’m nitpicking, but the subtle difference and shift in mindset can make a great difference: if you focus on what you do, you will be inclined to just do it without questioning WHY you are doing it. If you have an outcome focus, you will start questioning the why and the intended outcome. Shifting this way will allow you to recognize unessential distractions, tasks and targets, and get rid of them. Getting rid of what is essentially a waste and a waste of your time will free up your time to do more important things: in the context of software development this means delivering better software faster.

 

London Wicket event on the 21st of November

There will be a London Wicket meetup on Saturday the 21st of November at Foyles bookstore in London. I have a feeling this might be an extra special event, considering it is on a Saturday at Foyles, and a number of high profile Wicketeers will be in attendance, including Al Maw, Martijn Dashorst, Matej Knopp (all Wicket committers), Lionel Armanet of WiQuery (Wicket/JQuery integration) and many more.

Sign up now so you don’t miss out!

 

Learning new programming languages expands your toolbox for your previous languages

In the last two months I have spent a fair amount of time doing Objective-C and Cocoa programming. I think I’m starting to get half decent at it, in fact, I am starting to see things in code I wrote 1-1.5 months ago where I go: “What the hell was I thinking?!”.

Refactorings are in order and coming up soon. I’ve found it interesting though: though I know a number of languages and I learnt Scala earlier this year, Objective-C is sufficiently “different” from what I am used to for me to not just easily translating my existing coding style to Cocoa/Objective-C. Instead I have had to/been forced to learn Cocoa paradigms of programming, which have definitely pushed me out of my comfort zone. Scala on the other hand was sufficiently close to Java for me to just write “Java in Scala” and slowly, softly move into more Scala-like constructs.

Learning both Scala and Objective-C have achieved a few things though: it has made my programming toolbox bigger, I can use Cocoa-like constructs in Java, Scala like constructs in Cocoa to achieve results I wouldn’t have been able to had I only known one of the languages/environments.

 

Kanban success story

Though I sometimes take inspiration from current projects for blog posts, I usually try to keep current projects separate from this blog.
However, given the last 3-4 weeks have been my first experience with Kanban proper, I think it’s worth blogging about.

So what has it been like applying Kanban principles to a project?
In one word: liberating.

But to be more specific, in traditional Agile/Scrum terms, applying Kanban has at least doubled our velocity (though velocity is not really measured in Kanban, and I am generally skeptical of “velocity” measures). Productivity has sky rocketed.
Setting Work In Progress limits (WIP) achieves a couple of very tangible results:

• Focus: it achieves focus, WIP limits means that team members will exert one of two behaviors, either bandy together around work to get it done, or people who feel uninvolved will slack of being passive. In the case of this particular team, the team seems to have bandied together to get things done.
• Outcome focus over task focus: People start getting more focused on results and outcomes over moving task cards around. People get more done just through the fact that tasks are no longer as important as results and outcomes.
• Sprint estimates no longer drive sprint results: though it is not the meaning of having sprints, having sprint estimates and goals tend to lead to one of two results: either achieving the sprint promises and sprint promises only, or not achieving sprint promises at all because too much was estimated. With planning on demand, WIP’s and no estimates for what can be achieved in 1,2 or 3 weeks, people strangely enough start overachieving because they no longer have fixed expectations limiting or stretching their achievements.

My first test of Kanban principles has been a positive one: outcome oriented focus based on a team coming together and just trying to get a few stories at a time off “the board” can be surprisingly productive. It is still early days, but early signs are encouraging.

 

Has Spring increased or decreased code testability?

I’ve seen a lot of applications using Spring in the past few years, and I’ve noted a very worrying trend: they are becoming more and more dependent on Spring and harder and harder to test.
It begs the question: has Spring really made applications easier to test or not?

Compared to the EJB applications of yore, Spring is definitely a step in the right direction – Spring was originally created to alleviate and replace the pains of EJB’s. But, and that is a big but, Spring was meant as a replacement for a turn of the millennium technology, not 2009-2010 technologies.
I’ve seen a proliferation of projects in recent years where unit-tests require the whole Spring context to be loaded to be tested in a meaningful way, and this is made even more horrible when Spring configs contain imports of other Spring configs that include other Spring configs and so on.
You might argue that this is a result of bad design, and yes, it probably is, but nonetheless, it is design that Spring encourages/entices poor developers to use.

What Spring has mostly achieved in recent years seems to be in making code less testable, and moving what would have been compilation errors (and caught early by a good IDE) into becoming RuntimeExceptions.
Compilation errors become RuntimeExceptions? Not exactly great.

 

Did Java snobbery set up Ruby-on-Rails success?

It’s worth contemplating: did the snobbery of the Java community around “Design Pattern” layer-cakes setup the success of Ruby-on-Rails?

Most of what RoR achieves and does well could be achieved quite simply with Java, however the Java community’s obsession with Design Patterns, often with no awareness or skill of how to actually apply them have probably put off a fair number of developers from using Java at all. The community’s misplaced Design Pattern-obsession reputation precedes it, it would seem.
I’m not sure about RoR in particular, but I would not be surprised if it’s rise has not at least been partially helped by the dysfunction and snobbery of the Java community. Why would you want to work with a technology where most users of it insist on mind-boggling complexity for complexity’s sake? Why wouldn’t you embrace simpler alternatives that emphasize simplicity?

Personally, I still prefer Java and Wicket over RoR anyday, but I don’t blame the hordes of people that the rest of the Java community has turned off and away by virtue of thinking it was a lot smarter than it actually was (remember the old Business Delegate- Service Locater- Session EJB, Entity EJB layer cake, where 90% was just pass-through code? What a waste, and everyone did it).