Archive for the ‘Agile’ category

Do You Really Know what Continuous Integration is All About?

May 17th, 2012 by clucca

When I ask people what Continuous Integration (CI) is, I generally get a lot of different answers. Popular ones include:

“Running builds all the time!”

“Binaries on demand for QA.”

“The automation of the build so that developers don’t have to do it.”

And my favorite – “That server that sits in the corner that only the release engineer cares about.”

While all of these responses might be partially true, they don’t really cut to the core of what Continuous Integration is all about.

The true value that CI provides to your organization is QUALITY.

Let’s take a step back and talk about how quality happens. If we take a typical software development organization, feedback from the QA team is what drives product correctness. This feedback is used to help developers fix mistakes, and even change course in the way that something is designed for a specific release. One of the best ways to improve quality is to get that feedback to the developers faster, so developers don’t invest too much time, effort, and work into something that might actually be broken.

In Mary Poppendieck’s book “Lean Software Development: An Agile Toolkit” she often refers to feedback loops as being an important part of a development cycle – even going as far to point out that feedback loops help optimize certain common objects we use in everyday life, like a traffic light or in my opinion, a toaster oven. Feedback loops are all around us, it’s the difference between waiting at a traffic light that operates on a timer versus the ones that take feedback from the sensors in the road, sensing when vehicles are there. Which one do you think is more efficient?

This is what CI really is, it’s a basic feedback loop to tell your development organization that the code is either alive or dead. If dead, notify everyone and fix it. Without it, you might wait a week without fixing the problem, and will have coded yourself into a bad situation. It’s not about running builds all the time, it’s about knowing your code is still good.

What’s even more interesting about the current state of CI is that people are figuring out all kinds of ways to add new types of automation to it. For example, with Continuous Deployment, teams are measuring how the builds perform in a deployed state, even adding automated testing to it.

CI is turning into the ultimate feedback machine, going beyond regular builds and improving quality for development organizations.

Agile vs. Waterfall: We’ve Been Doing it Wrong for How Long!?

January 16th, 2012 by clucca

I was browsing reddit.com the other day and ran into this post:

20120116 Lucca Reddit Agile vs. Waterfall: We’ve Been Doing it Wrong for How Long!?Yup. It’s true. The tried and true development approach of Waterfall that we’ve been using for years was an example of what NOT to do for software development.

From the Wikipedia article: The first formal description of the waterfall model is often cited as a 1970 article by Winston W. Royce,[3] though Royce did not use the term “waterfall” in this article. Royce presented this model as an example of a flawed, non-working model (Royce 1970). This, in fact, is how the term is generally used in writing about software development—to describe a critical view of a commonly used software practice.

That’s what’s amazing about waterfall, and the agile transformations that seem to be taking the industry by storm. Maybe we all know deep down there is a better way to develop software.

I hope someday we don’t look back on Agile the same way we look back on Waterfall. I don’t think it will happen for the simple reason that Agile doesn’t have one methodology tied to it. Agile can mean a simple set of practices to help with software development, but it’s more like a mission statement as opposed to a plan.

Three Surprises in Software Development in 2012

December 8th, 2011 by lorne cooper

‘Tis the season to make unsupportable predictions for the future.  Despite my prior record (and I remain surprised that we don’t yet have personal jet packs) I’d still like to share a long-range weather forecast for the software industry.

You’ve been warned.  From here on, you’re on your own.

Prediction 1: Everyone Will Claim They Are Agile

And 50% of them will be wrong, just based on the Nokia test.  And of the rest, half won’t get any value from it.

There are a lot, and here I really need to underline a lot, of bad development practices out there.  For every organization that is killing it with Agile, there are five (my agilesta friends say ten) organizations that are limping along, delivering buggy code to their customers, late, and missing committed functionality.  And often all three.

This “Going Agile Without Knowing How” problem is probably an inevitable result of the success the early-adopter teams had with Agile methods.  For instance, when I watch The Olympics, figure skaters make skating look effortless.  When I do it, I look like a drunken hippo and hurt my butt.  It’s hard to stop and remember that these athletes, in addition to good genetics, spent years at the rink with their coaches learning, trying, failing, and improving, before they got in front of the TV cameras.

Agile has crossed the chasm, and the great majority of organizations have too few people, with too little coaching, and hardly any tooling.  Sure, your boss doesn’t realize how useless your stand-up meetings are, or that your code isn’t fully tested at the end of a sprint, but she’ll eventually see that your customers are not happy.

Prediction 2: Development for Mobile Devices Will Still be Small

Yes, Mobile is really big, and moving fast.  It’s just that the great majority of the work to support useful mobile apps remains in the back office.  When we’re finished inventing new ways to swipe our coffee-stained fingers across our screens, the value of the great majority of our apps is back in the glass house, running Java and C++ on big ‘ole honking (virtualized) servers.

The development problem in the era of proliferating small platforms, remains the problem of dealing with large, complex, data and it’s interactions.

Sleep well, Larry Ellison.

Prediction 3: The Gap Between Pros And Amateurs Will Grow

Every new software technology “spike” rewards the early adopters with higher productivity, which can level the playing field for the “newbie” or occasional software developer.  But as application complexity grows, as the platforms become more complex and development environments become richer, the professional advantage becomes more significant.

There isn’t much of a disadvantage in time-to-market for the young developer, maybe working on his laptop with open source tools and no identifiable process. The difference between them and a team of experienced professionals, working with industrial strength tools and procedures, and building apps that run businesses on virtualized hardware in a web connected world, is in “value created.”

Created Value is a concept that we’ve all been learning during the past ten years of Agile evangelism.  Created Value is measured at the customer side, and primarily by the classic metrics of software: how does the software help me get my job done better and faster?

There was a time when the lowest cost labour source for a software project was the key criteria.  Over the past two years, software projects have been revisiting their decisions as they’ve seen the crippling effects of buggy, unmaintainable, badly architected products.  We’ve seen the evidence with a hiring boom in the US for developers and QA alike.

In short, in 2012, we’ll see a renewed focus on quality of development, over quantity.  And a better appreciation for the talent, tools, and techniques, that create it.