I am a developer at heart. Even while doing other jobs, I still describe my vocation as a software engineer. Sometimes being a software engineer makes you feel like the odd one out. Meetings concerning business intelligence (BI) used to make me feel that way. The people in the room were talking about data, reports, feeds, and data stores — all things that we do in software development, but their focus was different enough to make me feel like a fish out of water. But that is changing and the gap between BI and software development seems to be closing. Let me highlight a few data points:
The Agile Regime Change by Dave West and Tom Grant
Agile is dead, Long live agile.
That’s how the Agile 2009 conference in Chicago opened. In the keynote, Alistair Cockburn cleverly paraphrased Marc Antony’s funeral oration from Shakespeare’s Julius Caesar: “I come to bury Agile, not to praise him.”
A very narrow definition of Agile has passed away, to be replaced by a mature, expansive version that has now joined the mainstream of development methodologies. Agile with a capital “A,” with its vision limited to the development team, died of natural causes. Its successor still worries about build scripts, daily Scrum meetings, and IDE plug-ins, but it recognizes the sovereignty of business objectives, and governs jointly with other methodologies. While we might talk more about agile with a small “a,” the significance of this change is big.
During the last three months I have been talking to many people on what a software development process looks like to them in the 21st century — you have seen some of the initial thoughts and ideas posted in this blog. The community seems full of different views as to what makes a process, or even if process, as we currently think of it, is right for software development teams.
It is clear that software development is NOT the same as other manufacturing processes, and that organizations that approach software development in that manner do not exploit the opportunity for innovation or develop an efficient process.
In the pursuit of building better software, it has always been the belief of most senior managers that if you have a good process you will get great software; that problems with software can be attributed to problems with process. Many people are now questioning that traditional mindset, believing that changing the tasks, work products, and responsibilities within the process does not lead to success, but a focus on culture, knowledge, and skills will instead improve the end product. This change in emphasis is embodied by the Agile methods movement and described nicely in one principle in the Agile manifesto ‘Individuals and interactions over process and tools’.
During the last six weeks we have been researching the state of software development processes and a number of very interesting trends have become apparent. These trends and the results of our research will be documented in the research report Best Practices In Software Development Processes slated for Q1 2009. But I just couldn’t wait to share some of the insights and get your reactions to them before then.
When I started in software development writing Cobol, sitting in an office with my humming green monitor. I was part of an IT department that was linked to a business department.The work I did was in direct response to my customers requests for new features or changes to existing features.We planned work at the start of the month and worked through that list during the month.Yes, there were cross department projects, but that was handled by everyone involved sitting in a room and saying ‘if you do this, we can do that’.It was a simpler time, a time when you could leave your screen unlocked and you had a real lunch hour.