The concept of code as an ends rather than a means is an appealing concept for a developer, and as a possible pillar for whatever post-agility may end up being. It may help restore some interest for those of who customer value is of little relevance, such as free and open source developers, people in the academic community, systems developers, and even those deep in the enterprise so far removed from the customer that they have nothing else to form a relationship with apart from code.
It seems a lot of people suffering from "agile-fatige" and looking for something post-agile are in two camps. One camp seems to be competent leaders working with poor developers. For them things like Scrum have bought some improvements in the organization and they despair that after all this "agility" the code is still crap. These people crave something like craftsmanship to light a fire amongst their developers. The other camp seems to be competent developers suffering under poor leadership. They see the XP practices and clean code as obvious to the point of being trivial, and wonder why people like Bob Martin are calling for more focus on code, when it is clear, to them, that future improvements lie in better management practices, better understanding of value streams and improved relations between customers, management and developers. These people are currently looking at things like lean and kanban, and finding a lot of valuable stuff there.
Additionally I feel that for 90% of the typical enterprise development a classic balanced agile approach is still a winner, good solid XP engineering practices, combined with engaged leadership that understands and operates according to the agile principles and values.
I don't think you need to be a software craftsman to shuffle data between a database and a webpage, you just need good XP engineering practices. You don't need to be a software craftsman to come up with killer algorithms, or work on complex AI, hardware or systems projects, you need to be a competent computer scientist.
Software craftsmanship definitely has the potential to be a core pillar of whatever post-agility may be, but only for those whom agility lacks something. I suspect software craftsmanship is still looking for its sweet spot, the particular pain points that it intends to address.
For me it seems like this sweet spot is in smaller organizations, perhaps in lean startups, doing things with mobile and the web, creating genuinely new products and ways of doing things.
I definitely doubt that craftsmanship should only be about the code. The craftsman of the future I think needs to be someone who is not only highly competent at programming, and can choose which practices are appropriate when, but also understands the business, can develop long term relationships with customers, understands the nature of the flow of value, and possesses a toolkit of a variety of methods, managerial, personal and technical, to ensure that this flow of value is appropriately managed and executed, according to the demands of the situation, and of course I think there will be an ever increasing focus on the cultivation of such talent.
It should be interesting to see what the future holds, but I think the community should strive for a little more than a simple rebadging of XP engineering practices.
> You received this message because you are subscribed to the Google Groups "software_craftsmanship" group.
> To post to this group, send email to software_cr...@googlegroups.com.
> To unsubscribe from this group, send email to software_craftsma...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/software_craftsmanship?hl=en.
Don't know how to find a link to the exact tweet, but you can google for retweets.
I doubt that any of the original signatories were thinking about
themselves as advocates of 'lean' back in 2001.
I remember at the time that Agile was an attempt to replace the
existing brand which was "lightweight methodologies" because it had
become increasingly meaningless.
I understand the temptation to try to claim an association to
everything good in the world of software. However when I read articles
like this: http://www.jimhighsmith.com/2011/01/07/innovators-imitators-and-idiots/
that try to claim that everything from DevOps to Kanban are outgrowths
of Agile I worry that we're building a movement so inclusive that it
becomes meaningless. Or worse that we're going to end up with a
movement that says that you have to be doing _all_ of the things on
some ever-growing list before you can benefit.
There are omissions and errors in a lot of the early (and
contemporary) writing on Agile. For instance the methodologies are
often presented as if they can overcome any deficiency of skill in
Or consider Scrum. Scrum is at best insufficient and at worse
dangerous to software development teams that don't have a wide range
of skills that are glossed over in the standard Scrum training. Do we
really want to be closely associated with that?
One of the things I like about software craftsmanship is the idea that
we're putting the focus back on people and the skills they need to do
an effective job for their customers. These skills cover much more
than just code. For instance I'm going to be focussing this year on
improving my design skills and my understanding of the field of user
experience. That's because that's the skill that's going to have the
most impact on the work I'm currently doing.
Software craftsmanship gives me a model for thinking about this kind
of skill acquisition and the deliberate practice needed to grow my
skills whilst the Agile Manifesto does not. I think we're
under-selling ourselves if we think of our little community as merely
post-Agile. We have a lot more to offer than just another methodology.
I think it's fair to say that steadily adding value is referring to
*business* value, and as such is in fact talking about working with
the business or enterprise and responding quickly to its needs by
adding additional business value to the systems we deliver.
I also think the *productive partnerships* value, which builds upon
agile's customer collaboration, clearly wants to increase the
closeness of the developer's relationship with the customer, not
decrease it as you seem to suggest. SC, per this document, is not
trying to place software craftsmen into ivory towers or research
bubbles where the code is its own end. It's clearly very much talking
about collaboration and communication with customers, as well as with
other craftsman (the community of professionals value).
Just my $.02.