The new user story backlog is a map
I’ve been recommending a similar approach – though not as completely fleshed out – for the last few years. (I organise the spine of my map as a mind map, though – I like spreading it out in 2d instead of just a line)
One of the odder practices of “conventional” software development that I’ve ever come across is the post-release test cycle. It’s something that has baffled me ever since I first saw it; you go through the normal development cycle, including testing, and then you deploy to production – and then you test it again. Sometimes with test cases that weren’t done during development. Why?
I mentioned in my last post how we have started using Feature Branches with Git and Jenkins. In that, I rather casually mentioned that
“The build server uses the Git plugin for Jenkins to monitor all the branches on the local repository. Whenever a developer pushes to the repository, Jenkins will see the change and try to merge it into the stable branch. If the build passes, the merge is committed. If it doesn’t pass, the FeatureBranch doesn’t get merged – and it will stay unmerged until another change is made against it.”
This feature means that broken builds have almost no impact on team productivity. In fact – it can even be more productive to allow a broken build than to try to prevent it all the time.
If you’ve been following my tweets recently, then you’ll know that we’ve recently converted the majority of our projects at work from Subversion to Git for our source control. We didn’t just do this because we wanted to play with a new shiny toy, but because we hope to achieve a new way of working. That’s what I want to describe here.
The title says it all, but I thought I’d spend about eight hundred or so words saying more. 
I’ve seen a number of people think that “being Agile” is about having a build server, or about using Kanban, or an Agile project management tool. It’s not about unit testing, or pair programming, or continuous delivery, or devops, or any of a hundred other buzzwords. Don’t get me wrong – well performing Agile teams will be using these kind of tools and practices. But that’s not what makes them Agile.
I saw an an article on Seth Godin’s blog about positive thinking. Godin makes the valid point that people who think positively tend to succeed more, in part because their confidence means they don’t second-guess themselves. You can easily waste a lot of energy debating what to do.
A point that Seth didn’t cover is that positive thinking means it’s more likely you will attempt something new: if you feel you can accomplish a task, you’re more likely to try. Sometimes, when you try something new, you will succeed. Other times you will fail. When you fail, there’s a chance you will learn – and learning makes it easier to succeed next time.
One of the key take aways of agile development for me is “experiment, and fail early”. Fail early, fail often, fail cheaply. And learn every time.
from Martin Fowler: Software and Obama’s Victory. I like the last org model shown; it would be very interesting to work in a company structured in such a fashion, with middle management acting as guides & facilitators, instead of intermediates, filters and superiors.
Mike Cannon-Brookes asks Is Atlassian still a startup? And when is a startup not a startup anymore? Well, Mike, the answer’s simple. If it still feels like a startup, it’s a startup.
We’ve been doing a lot of recruiting at “Wotif”:http://www.wotif.com/AboutCareersPositionDetails.jsp?jobId=7 recently, so I’ve been doing a lot of resume skimming and interviews of late. And I’ve noticed, amongst many other things, statements like this: “Oh, yes, we did continuous integration; we used CruiseControl!”
Folks, using “CruiseControl”:http://cruisecontrol.sourceforge.net is not continuous integration. And that’s coming from a former committer on the CruiseControl project.
The Australian IT on Tuesday had a “lovely article”:http://australianit.news.com.au/articles/0,7204,18994350%5E15306%5E%5Enbv%5E,00.html?from=rss on the Trellis system rollout in WA – specifically, how it was a “Big Java Job [that was] blasted on blowout”. The implication, of course, was that Java was to blame.
