My latest track is inspired by a book I recently read – The War of Art. Even though I don’t think it’s the best book I’ve read, the sentiment resonated with me, especially since I’ve made my goal for this year to write as many songs as possible.



Cog in the Machine

Happy Friday all! To celebrate the freedom that is the weekend, here’s a song to stick it to the man.

And the lyrics

Chained to my cubicle.
Handcuffed to the screen.
Orders sent through email,
keep it clean, the machine.  

Clock ticks, time slows
There’s a break coming soon.
Bell goes, chains off,
March to the machine.  

(One) Machine (two) machine
Working for the machine
(One) machine (two) machine
Cog in the machine.  

Caffeine queue, single file,
craving for my drug.
Swipe my card, grab the cup,
Jack up for the machine.  

(One) Machine (two) machine
Working for the machine
(One) machine (two) machine
Cog in the machine.


Bodies bodies everywhere

Here’s the next track for all you out there. Hope you like it, and as usual, I’d appreciate feedback.


Behind Closed Doors

Here’s my latest track and the first for 2016.

It’s a song written in reaction to the suicide of my friend, Eirin Lankwarden. I got to know Eirin through a mutual friend and he was helping me learn about trading. It was a huge shock to hear that he’d taken his own life as he seemed so sorted and happy.


Can you teach the right attitude?

Is it possible to teach someone how to have to right attitude?

As a consultant working for a company that both delivers software and trains others on how to develop software properly, I’m always searching for the best training and communication techniques. These techniques usually revolve around helping agile novice BAs understand the Agile Way – scoping requirements, writing stories and clear acceptance criteria, etc. We often take for granted that the people we are working with already have the implicit skills of a BA – hunger to understand, clarity of thought, succinct and clear communication skills, and, of course, empathy. In short, attitude. This, as I’ve discovered on a few of my gigs, is not always the case. So how do you deal with those situations?

The most powerful way is by example. People are inspired when they see someone passionately doing what they love doing. It’s infectious. If someone else in the team is putting in 100% and really enjoying it, the other team members will notice, and more often than not, push themselves to try a little harder.

Part of leading by example is explaining what you’re doing and why you’re doing it. You may think that what you’re doing is the most logical thing to be doing and that the reasons are clear, but others cont always see this. Vocalizing your steps and thought processes along the way will help others put the pieces together a lot easier. Remember that your experiences have sculpted the way you think and act and gave you the tools to solve problems rationally and logically. Don’t force others to infer – be clear by talking others through your actions.

A second method I use often is simply to ask questions. Most of the time you know the answer, but it isn’t the answer you’re after. You’re trying to help someone understand the right questions to be asking and by doing so, help them see the processes you follow to get to the right answer. The trick with asking questions is being flexible enough to restate your questions in a variety of ways. Your student may not give you the answer you want the first time around, but asking again in a different way may help them understand what you’re getting at.

A third technique I use is just as simple – encouragement. Celebrating the small victories encourages your student, making them want to try harder for more victories. Everyone likes to be told when they’re doing something well, so find something that you can compliment your student about. Stay away from pointing out problems in a negative manner, even if you’re frustrated with a lack of progress or understanding. This will only help to put a distance between you and make it that much harder for any real progress. Remember that not everyone will find this as easy as you may, and they may need a lot more time to even get the basics right.

Attitude problems can stem from a number of factors and are generally a symptom of other issues that can be deeper and more personal than you think. Remember that ultimately, we are all just human with our own unique histories, emotions and perspectives, and that we each need something different to motivate us. Keeping this in mind will help you approach others with the sensitivity and respect they deserve, and that you as a consultant are being paid for.


Who’s story is it anyway?


No, it’s not yours. No matter what you may think, the story just isn’t yours. You may have a hand in it, you may even pick it up off the backlog and start working on it, but really, it belongs to the team.

As a Business Analyst on an Agile project (or indeed, on any project), it’s your responsibility to understand the requirements of the client and translate them into workable bits of functionality that the team can build from. Yes, these bits of functionality are called stories, and they usually follow the format “as a [something] I want to [do something] so that I can [achieve some valuable result]”. We all know this drill by now. What I see everyday though, are BAs struggling to flesh out the entire story by themselves. Hello there! No one said you couldn’t ask for help! That’s what the team is for!

I’m currently working on a large project where we are working with the clients development team, including developers, UXers, and BAs. Most of these people come from the traditional waterfall method of working and it’s clear from the BAs that we work with that collaboration is not high on the priority list in waterfall. Oftentimes the BAs will pick up a story and not come away from the computer until a few days later, when pretty much the whole story has been done. This is the area where we end up doing most of our coaching work. We spend our time trying to get the BAs to work with the other team members. Pairing with them on writing the story and getting the format right, the acceptance criteria well structured is the first challenge (which is a topic for another post…) but changing a BAs mindset to let go of the belief that they need to figure out the entire solution by themselves first can be much trickier. Coming from a more traditional (read Waterfall) background myself, I know how difficult it can be to let go and allow the team to help scuplt a solution. The BA is supposed to know everything, right? Wrong! The BA should be trying to use the expertise of the whole team to come up with the best possible solution. Each member of the team has unique experiences and specialities and tapping into these allows you to sidestep potential hurdles easily and avoid unnecessary rework.

The first bit of collaboration you’ll do on a story is to figure out what the heck it’s all about. Who do you go to for this? The Product Owner. This should give you a good understanding of the direction/s the story could go in.

After this, there is sometimes a period when you you may need to do some thinking by yourself, if that’s your thing. Sometimes you’ll need to make some calls, gather some information, before you can start sketching out the requirement. But this shouldn’t go on for too long without checking in with someone else to bounce your ideas off of. An important port of call is the developers in the team. They’ll be able to give you guidance around any technical hurdles you may not realise are lurking under the hood. Close on the heels of the devs, you should definitely be speaking to the UX team to give them the scope of the story and let them start throwing together some wireframes for the Product Owner to start workin with and testing through. A check in with the QAs on the team can uncover interesting edge-case scenarios that you never considered, as well as requirements for test data that needs to be prepped and which may take a while to do so. Better get that ready ASAP!

Some BAs pick this up faster than others. Those with larger egos tend to find it more difficult to let go. Some still believe that the roles in a team are clearly defined: “I’m the BA, so I should be creating the solution first and only when it’s completely worked out should I just double-check it with another BA.” WRONG ATTITUDE! Everyone on the team is working towards the same goal, albeit from different perspectives. A good BA is able to effectively harness these perspectives and distill them into a great story. And don’t we all want to tell a great story?


Visual Observations

Which combo would you like? Everything on the menu is a combo….

Which combo would you like?

Everything on the menu is a combo. If you want an individual item it’s called an extra. We’re only offered prepackaged stuff now. Sad.



Track the process, not the outcomes

master ladderI read an interesting post by John Maeda where he questions what exactly we should be practising for the 10,000 hours that Malcolm Gladwell suggests is required to master a skill. He points out that although we can understand that it takes this extended time to master a skill, often we are not sure exactly what it is that we should be practising for this time.

Coaching tech UX

Back to my future

Today I started my engine to travel along a new path. My passion for building software that solves problems was too strong to ignore and so today I join ThoughWorks to continue my quest to help the world by building better software. I’ve long been an advocate of Agile development practices, using it to improve the software development practices at White Wall Web. ThoughtWorks has always been on the forefront of Agile and custom software development so I believe the match is a great one. ThoughtWorks also focuses on positive social change and to rings very true for me.

I’ll be focusing on understanding clients needs and issues and then creating highly usable and simple solutions to address these needs and issues. Clear and simply user experience is a major driver for me and I’ll be pushing this agenda hard.

I’m grateful that the experiences I’ve had, the people I’ve worked with and the clients I’ve had have brought me to this new juncture. The future is bright!


The path of least resistance

It’s become quite clear to me that the more I use technology, the more I just want it to work. Reliability and ease-of-use are extremely important factors for me. If I start my mail app, it must start quickly and it must immediately connect and send mail, without problems. It must also be clear and quick to write a mail and new mail should arrive as quickly as possible.

Focus is another important consideration. I want to be focused on the task as hand and get that completed in the shortest time possible. I don’t want endless notifications interrupting me and breaking me away from the immediacy of my current task.

This is why I’m increasingly choosing my iPad over my Mac. My iPad is always on, even when it’s off. If doesn’t go into a sleep mode that it takes a couple of seconds to wake from. Apps work reliably and connectivity is never a consideration. It is connected all the time. I’m having endless problems with my MacBook and yes, I could probably sort it out by reinstalling the problematic apps, or reconfiguring the network settings or a variety of other actions, but the point is that I don’t even have to think about these actions on my iPad.

Yes, there is functionality that is either missing or slightly more difficult to get to on the iPad but I’m willing to make these sacrifices for the convenience and lowering of my stress levels. In my early IT career, I was like every other geek that wanted the biggest, most badass desktop with the fastest processor, most RAM and awesomely powerful graphics card, but when you realize that these factors mean increasingly less and less in a world where we just need to communicate easily and quickly, you start seeing the folly in that line of thinking. There will always be the use cases for the best, most advanced tech, but increasingly it isn’t relevant in the everyday workplace.

So for me the argument isn’t iOS vs Android, but rather Desktop vs Mobile OS. I’ve made my choice.