As a programmer, how do you measure your productivity? What kinds of tools do you have to determine project progress? Are you using story points? Is it the number of stories delivered in a certain time span? Do you track your progress with burn-down charts?
When you think about a successful working day, one of those days where you come home to your partner and say it has been really productive, what happened that day?
For me it is very simple. I measure my productivity in code. Thus a really productive day is a day where I have written and tested a good amount of code. Or even more specific than that: A day where I have written code that compiles, runs, and does something deliverable to my customer and thus actually matters. When I accomplish this then I feel satisfied in my job.
The flipside is that everything that keeps me from writing code that matters makes me feel unproductive. Mostly these are little things, routine day-to-day activities, processes and meetings that need to exist in any organisation. Programming is a task that requires a huge amount of concentration and focus. Interruptions make me feel unproductive and in summary are disempowering. How to get more coding done and spend less time with trifling matters? For me the answer for this always was agile software development.
Recently though, I read an article by Tim Anderson about a talk by Erik Meijer that was overwritten with “AGILE must be destroyed once and for all”. Working in agile projects for the best part of my career I was initially shocked by this title. Indeed I would accredit a huge part of the success of my projects to agile methodologies.
I do understand Mejer’s complaint though. Some agile processes focus a lot on just that: being processes; focussing on processes rather than people and outcome is actually not agile at all. In fact it is working against the agile manifesto. If we recall, the agile manifesto actually doesn’t talk about specific processes at all or things such as stand-up meetings or even story points or burn down charts. Instead it defines four simple values:
Individuals and interactions over processes and tools.
Working software over comprehensive documentation.
Customer collaboration over contract negotiation.
Responding to change over following a plan.
If a focus on processes is not healthy, then what should we focus on in software development? How can we objectively measure our productivity? The answer is as simple as it is obvious. We should focus on creating value: value for our customers and value for our business. Producing value and increasing productivity will make your company more competitive and at the end of the day pay your salary. For you that simply means focus on creating working software, great products to sell, code that matters.
This development is not new. Indeed there is significant buzz in the industry around this topic. From almost comical approaches like the programming motherfucker manifesto to serious approaches, such as value driven development backed by pragmatic marketing and the lean start-up movement.
At 1E we take huge pride in our agile approach. We have well-established agile processes and we discovered early on that optimising our processes is the key to successful engineering. As a software house, engineering is the heart of our business and continuously challenging and improving our own processes is key for the engineering team to produce the maximum value and for the company to increase its competitiveness.
To empower the teams to create value we recently formalized this approach with a specific function in the business: Process Services. This division, which is part of the engineering department, takes care that our processes across the engineering team are as lean and efficient as possible, with the least amount of distraction for the developers as possible. To allow programmers what they love to do: writing code that matters.
