Developers are taking over the world!
Everyone involved in software development projects should read the book The New Kingmakers.
The book gives the background why traditional tayloristic approaches are not effective in the knowledge work environments of software projects: Plans and roadmaps are not going to work as long as you don’t get developers intrinsically motivated.
For some reason the book is free on the Kindle.
On the same topic:
Here's an updated version of my "What makes knowledge workers productive?" venn diagram pic.twitter.com/9FfmcjECiq
— Oscar Berg (@oscarberg) March 24, 2014
Planning, planning and more planning!
Speaking of motivating developers. In my experience, one of the most demotivating construct in enterprise development is planning.
The Agile Manifesto speaks about "Responding to change over following a plan”.
While Scrum is facilitating many Agile principles, the concept of the backlog is often used to re-establish a waterfall-like long-term plan. With the long-term plan comes the justification for controlling and micro-management. Newer methodologies that promise to “scale agile to the enterprise” (like SAFe) even reinforce this tendency for establishing and following a plan (note how the arrows in SAFe all point in one direction?). SAFe is an approach by classical management to re-apply tayloristic approaches that have been questioned by the Agile movement.
That’s why Water-Scrum-fall is the reality of Agile today.
And that’s why I don’t believe in scaling Agile to the enterprise.
That is why we have the Manifesto for Half-Arsed Agile Software Development.
Ken Schwaber (the inventor of Scrum) puts it like this:
A core premise of agile is that the people doing the work are the people who can best figure out how to do it. The job of management is to do anything to help them do so, not suffocate them with SAFe.
Do we really need strict control (which is basically the reason for all that detailed planning)?
Tom De Marco (a pioneer and author in the area of software project management) has an interesting thesis about this in his paper: Software Engineering: An Idea Whose Time Has Come and Gone?
strict control is something that matters a lot on relatively useless projects and much less on useful projects
What can developers do: They should choose their work!
So for us developers this boils down to making a choice: What kind of projects do we choose to work on?
Mike Monteiro repeats that in his brilliant presentations: How Designers Destroyed the World
The work we choose to take on defines us!
Webstock '13: Mike Monteiro - How Designers Destroyed the World from Webstock on Vimeo.
Conferences
I want to point to two special upcoming local conferences:
SwissJeese - An indie JavaScript conference in my beautiful hometown of Bern (July 26th 2014). I have never been to that conference and unfortunately my talk-submission was not accepted (probably the topic of Nashorn is too enterprisy for the conference :-)). But the program looks very promising and there are still tickets left.
ch/open Workshop Tage - An excellent event with a marvellous collection of interesting topics (September 9-11, 2014). I am attending and also holding workshops at the Workshop Tage for the last 7 years, and each year I am looking forward to the event again.
Battle Cry
Speaking of conferences: Philip is calling for an epic battle: Web vs Native on mobile devices - let the strongest prevail!
(actually, according to the rules of Philip it would be the quickest, not the strongest ... maybe Philip should look again at what happened to Oberyn Martell?)
On JavaScript
The obligate Gartner prediction:
Through 2014, improved JavaScript performance will begin to push HTML5 and the browser as a mainstream enterprise application development environment.
ThoughtWorks Technology Radar chimes in:
The ecosystem around JavaScript as a serious application platform continues to evolve.
Large JavaScript codebases are hard.
Stackoverflow explains the difference between JavaScript and Java:
Java and Javascript are similar like Car and Carpet are similar.
One is essentially a toy, designed for writing small pieces of code, and traditionally used and abused by inexperienced programmers. The other is a scripting language for web browsers.
Btw. responding to change over following a plan implies that you have a plan. Otherwise there are now changes....
ReplyDelete@Simon: Yes you need a plan that tells you where you want to go. I would rather like to think of a goal or a vision.
ReplyDeleteBut trying to establish a complete backlog with estimated items that then can be used to track every task of the development team will not work in software projects.
For capturing a goal/vision you don't need an issue tracker ...
You are right about the vision. That's why my preferred dev methodology is RUP. There you have a vision and it is incremental!
ReplyDelete