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 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.

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!

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.

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.

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.

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).

I think Scrum, applied pragmatically is a great way of working, however depending on people and culture, it has a number of short comings and pitfalls that I have noticed over the years. Someone defending Scrum might (partially justified) defend Scrum by saying that people who fall into these pitfalls are doing it wrong, but at the same time, if it is easy to fall into the anti-patterns based on the “default” way of working, I would say the pitfalls are very much part of Scrum. Those old enough to remember probably have some clue about all the pitfalls of Rational Unified Process when it was big: most RUP implementations became bastardizations of the core purpose of RUP, but nonetheless tainted its reputation to the point where it is barely used anymore.

So what are the pitfalls? Here’s my take:

Task rather than outcome focus
Though user stories and conditions of satisfaction are the target, due to the way Scrum does sprint planning it is easy to fall into being task focused rather than outcome focused: in practice this means people become more focused on moving around task cards on the board rather than take the next logical action that will contribute towards achieving the goal of the user story. This results in a lot of waste when meaningless tasks are done regardless, and sometimes meaningful tasks being omitted, resulting in missed conditions of satisfaction and non-delivery.

Sprints as mini-waterfalls
For all the aggressive posturing against waterfall methodologies from a lot of Agilists, Scrum is certainly very prone to the same failings as waterfall methodologies but just on a shorter time span: the task orientation and way sprint planning is done often gives both management and team members the false sense of security that everything can be known and planned for in a Sprint. Not any more true for Scrum than for traditional project methodologies: what you know will rarely bite you. What you don’t know that you don’t know most definitely will.

Scrum invites micro-management
Again, the strong task focus of Scrum is an open invitation for micro-management by Seagull managers and those team members and stakeholders prone to it. This is a very real risk that could kill the flow that a team might have.

Story pointing is too course grained and as inaccurate as any sort of estimation
In my experience and opinion, any estimate that is on a scale of higher than a day is likely to have an error margin up or down of 100%. Any estimate that is on a scale of more than a week can effectively be replaced by “I don’t have a f***in clue”. Though story pointing may look like a holy grail for managers wanting to extrapolate things like velocity, progress and likely time lines they are will probably be no more accurate than the good old guesstimates of waterfall projects.
If you used a pseudo-random number generator with a story-point distribution like a bell curve with a bias towards 2 or 3 points, I’m pretty sure it would be just as accurate as most peoples story point estimates.

“Let’s play Sprint sudoku!”
Ever seen a sprint board for a largish team? Chances are it will read like an advanced sudoku board, with cards all over the place. Is that really achieving visibility of the work to be done? Is that visualization worth anything at all? Is having 10 stories and 100 tasks on a board conducive to people keeping focus and actually finishing any of the stories?

Does all this mean I am dismissing Scrum out of hand? Not at all. But I do think being aware of the potential pitfalls is important, and that Scrum is not perfect by any means. A methodology and process will never be a replacement for good judgement and common sense.
I personally like some of the things coming out of the Lean/Kanban camp, if applied with common sense and judgement. On a project I am working on at the moment we have tried to mix in some of these practices (WIP limits, work queues etc) to minimize the risk of some pitfalls, and the initial signs are promising.

There is a lot of disdain in startup circles towards so called “lifestyle businesses”, businesses that have limited potential for growth and might only bring a limited profit to their owners. There is also a common conception of lifestyle businesses being a “trap” for their owners – forcing them to work long, hard hours for a very limited upside.

But is this really an accurate depiction of small businesses with limited growth potential? Maybe for some, but hardly all of them. What if you could bring in a small profit monthly, yearly for a very small active effort? Is $5000 or even $500 a month in income really something to sniff at if you are only spending a few hours a month on it?

My answer would be an emphatic no. To me the key issue is the required active effort in running something, as long as it does not trap me and does not require me to work very actively, I don’t really care if a potential business is small. $500 a month for 2-3 hours of my time is a pretty good reward for my efforts, scale that up to 10-15 similar things, and I’d be making pretty good money by just working one week a month.

Personally, I’d embrace the concept of a lifestyle business as long as it does not require too much of my time – the freedom and autonomy granted by having a few thousand dollars a month just flowing into my account with very little effort is a “problem” I’d be happy to have.

There seems to be a debate raging between the Agile and Lean camps, among others, Jurgen Appelo recently leveled some criticism of Lean’s lack of people focus, while Scott Bellware is a critic of Agile from the Lean side of the aisle.

Though both sides have valuable points, I get a little bit of a feeling that this is a little like the conflict between the Peoples Front of Judea and the Judean Peoples Front in the movie “Life of Brian” (see clip above).

Yes, there are certainly differences and differences are worth exploring and debating. Agile focuses on being Agile which may lead to being successful, while Lean focuses on being successful, which may lead to being Agile.
But, at the same time, I see both movements sharing a lot of practices, values and goals.
Personally, I’m not anymore religious about methodologies than I am about.. religion (agnostic with atheist leanings). I’d like to mix and match: Agile methodologies provide me with a lot of answers where Lean does not, and vice versa.

Whereas Appelo’s criticism of Lean lacking a people focus might be on the money (I don’t know, I’m not a lean expert), Agile in general and Scrum in particular (or at least the way it is commonly implemented) has a lot of faults I’ve become aware of over the years: my main problem with Scrum is that it is often too introspective, too focused on methods and means rather than results and outcomes, too focused on tasks and cards rather than goals. To me, this is where Lean thinking steps in and fills the gaps with answers to how to be more result focused and deliver value constantly.

What is my take? Well, there is a lot of overlap, but also a lot of areas that complement eachother. To me, software development is not about finding religion, it is about doing the things that have been empirically proven to work while learning and adapting your way of working to the context of each individual situation and project with only one ultimate goal in mind: the successful delivery of business value.
For me, that tends to mean I try to be both Lean and Agile in whatever combination works for the project at hand. Lean and Agile both provide answers to questions, but they are not all the same questions, so you may have to look in both places and do some thinking of your own.