There are countless processes published that purport to deliver maximum effectiveness from a development team. What they really mean is that the process will maximise the effectiveness of the team as it currently exists. As the old adage goes:
You can’t make a silk purse out of a sow’s ear
The foundations for high performance teams are laid long before we overlay a development process. Technology organisations as it turns out are generally good at hiring top talent, but unlike other high-performance teams and organisations we are not good at sustaining that performance.
What’s the difference then between a high performance technical team and say a top-flight sports team? Well there are a few. Coincidentally we tend to start from the same place, but the approaches diverge as the process continues.
Continue reading “Building High Performance Development Teams”
When dealing with companies moving towards Agile as a process, occasionally I will deliver a presentation offering an overview of Agile to set a context for the future conversation. The presentation itself is not an in depth treatise on Agile processes; in fact it’s pretty lightweight as these things go, but it does serve as a catalyst for conversations and offers a forum for questions, which is the real purpose.
As organisations begin to change their processes, there is a natural tendency for people to resist that change because change takes us outside of our comfort zone. Resistance then is often cry for ‘help’ or maybe a cry for ‘bring me with you’. It’s easy to get a blinkered view on Agile, to assume that not only does everyone recognise the benefits, but also to assume that everyone knows what exactly Agile is.
The presentation, which I’ll post somewhere soon to let you see what I’m talking about, offers a whistle-stop tour of the Agile Manifesto to set the stage followed by a review of the shopping list of different Agile / Lean / XP processes / methodologies / approaches (I’m going to call them systems from now on) that all refer back to that manifesto. Just a note that currently there’s 15 systems listed in the presentation, and that’s trimmed back.
Continue reading “Agile and the Agile Mindset”
I spend a lot of time with organizations of various sizes helping them transition from their current state to their desired future state.
In practice this offers a wide variety of challenges from one organisation to another. Some have great developers but poor processes, others have strong processes, but lack support systems, some are just struggling to understand what their goals are. Inevitably there is some level of confusion, frustration and a sense of someone else ‘just not getting it’.
I’ve increasingly taken on a mission with all of these organisations, a personal mission that I believe goes to the very heart of the malaise that I see in the IT industry over and over again.
That mission is to help everyone remember that once upon a time, not so long ago, this used to be fun.
Continue reading “Why are we doing this?”
The only constant is change
In the technology world we’re well used to the shifting sands that epitomise the environment, we’ve always lived with change and embrace it with a fair degree of gusto. In other industries, ones that may not have had a traditional basis in technology, their adoption rates have historically been a bit more ‘pedestrian’. But this world is waking up fast to their need to adapt and change, but in the awakening they are realising that the gap between their ambition and their ability to adapt can range from a crack to a chasm. There are more than enough challenges when determining the nature of the change that an organisation needs to adopt to meet the new opportunities without having to worry whether those changes will actually stick.
Continue reading “Making Change Stick”
I get to spend a lot of time with junior developers and designers – actually at my age it seems like everyone’s a junior developer. We spend large tranches of our time together discussing the various designs, architectures, technologies, patterns and standards that will best address the particular problem domain we’re exploring.
Inevitably the conversation turns to the question of priority: what is the most important thing? The need to apply ‘best practices’? The use of patterns? SOLID? Structured Exception Handling? Language? Platform? Or is it speed of development? So I tell them: the most important thing is to set their own high standards and stick to them.
Continue reading “‘Me First’ Standards”
Behind the Curtain
The range of things that go on behind the veil of an API are legion. So much can be hidden here that it can very quickly become startlingly complex in a very short amount of time. I’m going to show the general approach that I take, which has served me well since the dinosaurs were killed off and the Internet emerged as a service delivery system.
The trick in my mind is to separate and isolate into layers early and often, with a view to collapsing those layers during an optimisation phase. You want to be as productive as possible without doing anything that gets you into trouble later. In many respects it reflects your life in your early twenties.
Continue reading “Simple API Development pt 3.”
You’ve got this far and there’s not a child in the house washed. Lets get practical on the things that we really need to think about to actually write some code. These are the things that we really want to think about to get from nowhere to a working skeleton in the shortest amount of time. Most of the points presented here are language and platform agnostic. When I’m developing API layers this is what I do almost every time and I need to have a very strong argument before I deviate from this approach. It may sound a bit dull and a bit unimaginative, but I like to spend my time creatively solving the problem being presented by the application rather than dedicate myself to thinking up new ways of doing common things. I’m funny that way.
Continue reading “Simple API Development pt 2.”