Apologies for the recent outage. My hosting provider scheduled an upgrade to the server and broke the site at the same time. Normal service has resumed.
Software Craftsmanship is an Apprentice’s Journey to Guild Master
In part six of my series on software craftsmanship I have a look at how software craftsmanship is sometimes portrayed as an apprentice’s journey up a guild heirarchy to the elevated rank of “master”.
Continue reading
What do I do When … ?
A few years back I did a big agile roll out and I asked people for a list of the things which might upset the agile software delivery process. Although I asked for Agile Gotchas the team actually came up with was a set of questions on "What do I do when … ?".
I’ve answered many of these questions in my big articles on Agile Project Management but I’ve decided to put a bit more focus on them. So, in a new series of monthly posts, I’ll answer questions on the theme of What do I do When.
I have some questions in mind but I would also welcome other questions along the lines of What do I do When … ?. If you’ve got a suggestion please drop me a line or add a comment.
Can Cucumber save Raja?
I’m worried about Raja. Unless I do something drastic he’s going to die. In a rather messy and unpleasant way. Crushed by the weight of a 60 person-year software product.
But I think I’ve got a solution. Cucumber might well save Raja from his gruesome fate.
Continue reading
Software Craftsmanship is a community of practice with overlapping values
In part five of my series on software craftsmanship I look at the definition of software craftsmanship presented in the book by Hoover and Oshineye (2009). Their definition is wrapped around the concepts of community and values. Nice embracing terms but what does that mean for software craftsmen?
Continue reading
New Agile Teams and the Overcommitment Bear Trap
The most common problem I’ve seen with software development teams is over commitment. Invariably individuals and teams are overly optimistic about what can be done in a certain time period. There are any number of reasons for this including arbitrary management deadlines and the team not pushing back, the developers desire to please, and just the fact that estimating in software development is hard.
Agile development teams are just as prone to this problem as any others. Every team I have helped transition to Agile has stepped into this bear trap almost immediately. And forewarning them doesn’t help. I now see stumbling into the trap as a valuable lesson and an essential step in the process of getting more mature about software development. I don’t mean maturity in the sense of the SEI’s Capability Maturity Model, I mean maturity in the sense of growing up, being realistic and accepting the limitations in themselves, their team and the organisation.
The difference about Agile, compared to traditional approaches to software development, is that Agile offers techniques to avoid the over commitment bear trap.
Continue reading
Software Craftsmanship is skilled software development in small scale production
In this, the fourth post in my series on software craftsmanship, I interpret Wikipedia: Craft in the context of software development. I’m doing this because Ade Oshineye: Software Craftsmanship – More than just a manifesto
recommended the wikipedia definition of craft although Ade generally avoids dictionary style definitions for software craftsmanship (Hoover and Oshineye, 2009).
Continue reading
A Lean-Agile Perspective at the Project Research Institute
I was recently asked to write a series of blog posts for the Project Research Institute of Athabascau University in Canada. The institute wanted to expose their audience, mainstream project managers, to an Agile perspective. I relished the opportunity and readily agreed.
My aim with my PMI series is to show how the principles and practices of Lean-Agile Software Development offer creative solutions to general project challenges such as governance, uncertainty and complexity, under estimation and empowerment. My first post for the institute tackles this head on and I argue that Lean-Agile relevant to all project managers” simply because Lean-Agile offers a new slant on these problems. I am not advocating the wholesale adoption of Agile by all project managers. Merely to offer up a different perspective to that of main stream project management. Armed with this perspective project managers from other domains may be better placed to face their own challenges.
The first couple of posts have already been published and the rest of the series will appear over the next couple of months. If you want to follow the series on the PIR site then have a look at my blog at Athabascau. Otherwise I’ll also post updates here.
Software Craftsmanship is not writing crap
In the third post in my series on software craftsmanship I’m having at look at Bob Martin’s call to arms to software craftsmen to not write crap.
Continue reading
Agile Infrastructure
A senior manager in the operations area of my organisation recently commented:
There is no such thing as agile infrastructure
That got me thinking. I can imagine that adopting an agile approach to infrastructure might be inappropriate in certain circumstances, for example military or medical domains.
On the other hand my current programme needed a completely new infrastructure stack and I found a considerable amount of agility was possible through that exercise. To my way of (probably simplistic) thinking any changes needed from the infrastructure are to provide either more capability or faster capability. With that in mind I’ve found it is possible to architect for agility and deliver the infrastructure in an incremental and iterative manner.
Continue reading