Archive for March, 2010

Continuous Integration vs. Continuous Perfection

March 26th, 2010 by clucca

Continuous integration is about confronting your risk. It’s about giving rapid feedback and responding to problems that you may encounter in your development environment.

If you’re Agile, you know one principle is adaptation. It’s not about sticking to the plan; it’s about exposing and responding to change in your development cycle.  This is why the principles of continuous integration and Agile walk hand in hand.

Delaying the inevitable risk of code integration doesn’t mean the risk will disappear.  Each line of code you change is a risk. Each commit you do is a risk. You can’t avoid the risk by putting it off.  Just like anything, if you were going to bottle up all of that risk, let it ferment for a few months and open it later… I’m pretty sure you wouldn’t want to drink the whole bottle in one gulp. It really only takes one sip to know the concoction is bad.

Continuous Perfection is one of the reasons we bottle up the risk. Let me give you an example.

We set up continuous build on trunk, we encourage our developers to integrate early and often, life is good…. until the day of the broken build.

If it’s broken for even a day, panic ensues, we’ve issued blame to developers for something they should not be responsible for, a stoppage in work for organization. People will feel rushed to resolve issues, the QA team will stop testing, and our release engineer will struggle to roll back code. Essentially, people will be running around like chickens with their heads cut off.

Our management teams do what they do best, they listen to the release team, QA team and the dev team. “Joe Developer broke the build, it’s his fault that we can’t work today”.

When did the broken build become such a big deal?

This scenario may repeat itself, over the course of several weeks our mangers will react, and start asking developers to put in process to avoid breaking the build. Our teams will start to feel that their code must be perfect before they commit. This problem is called Continuous Perfection, it’s the idea that the code must be perfect before it’s committed to the repository.

And doesn’t this seem to work against the principles of continuous integration? The idea here was that we integrate early and often to avoid Integration Hell and the Big Bang merge. We want to confront and work through our problems right now. But now we’ve started to go back to what we do naturally. Isolate changes, put off the inevitable and work off of our private branches. Our developers do local builds to make sure the builds work correctly, and jump through hoops to avoid committing to early in fear of being blamed. We are back where we started, with a huge merge at the end of the project that could fail everything.  We bottled up all our risk, and ended up in a more dangerous place then we intended.

But what can we do to solve this problem ?  To be continued…

April Tour Updates

March 24th, 2010 by AccuRev

SQE’s “Agile Comes to You” seminar tour has added new dates and locations for the month of April!  Due to great turnouts and positive feedback, AccuRev, Rally, AnthillPro and Coverity will continue their cross-country tour with upcoming stops in Colorado Springs and Minneapolis.

The half-day seminars are filled with Agile tools product demos, presentations from keynote speakers, Coverity, Rally, AccuRev and AnthillPro, and a question and answer session with a panel of Agile product experts.   Below is the panel from one of the most recent seminars in Seattle.

QA for 3 34 blog April Tour Updates

Attendees also learn about the new AgileCycle ALM suite of integrated software and services, designed to increase the speed and impact of Agile projects and enable Agile adoption.

Interested in Agile and want to check out AgileCycle? Join us in Colorado Springs on April 6th or in Minneapolis on April 7th.

April Tour Updates pic

Register here for Colorado Springs on April 6th.

Register here for Minneapolis on April 7th.

What’s a Manager to Do? Management’s Role in Scrum Organizations, Part III

March 15th, 2010 by lorne cooper

I love the concept of self-managing teams.  Everyone figures out what needs to be done, and does their best to make the greater organization successful.  Beautiful.  Reminds me of the Shaker Village, the Russian Artel, or the Israeli Kibbutz.  All of which are (largely) extinct today.

There are three structural problems that, like termites behind the wallpaper in a French Quarter house, cause these “worker’s paradises” to fail.  Our job, as managers of the Innovation Engine, are to sniff ‘em out, expose them, and exterminate them.

Problem #3: The Buck Starts Here.

For all the happy talk about mission, values, and meaningful work, the ultimate metrics for business are financial.  Our inability to grow, make profits, secure new investors, etc., will ultimately end our ability to accomplish our missions, support our values, or provide work to our employees and worse yet, ours bosses. That’s the bad news.

The good news is that we managers can use money (or their engineering equivalents, people) to accomplish great things.  Which things we choose to accomplish is largely up to us.

No, that doesn’t mean we want to create our own user stories, and reprioritize the backlog to meet the requirements communicated to us in our sleep by our deceased pet snake.  That’s the product owner’s job.

The Scrum process, like its Lean predecessors, is based on incremental improvement.  That’s great for two reasons: first the changes are small enough that we can get them done and see the results before the environment has changed, and second because they are small enough in scope that the individuals in development or product management can understand and control them.

We managers have to see the bigger picture, and that generally means determining the funding level for each of the initiatives we have.  Adding people to a team will eventually, not withstanding our bad management, increase its velocity.  Pulling people off will generally do the opposite (although not as quickly as you might think …….).

The optimization problem for the overall success of the organization involves lots of variables, but that’s really why they pay us the big bucks.  Is this group servicing a stable and productive customer, while this other group is struggling to overcome a mountain of technical debt?  Are competitors starting to emerge for what has been a stable area? Has this project achieved most of its goals? Is it time to determine what should be the next big initiative?

The purely business and marketing side of the equation is usually an area of influence, not control, for the development manager.  But the assignment of resources to projects is the execution of that strategy, and requires management comprehension and “buy-in.” For those of you uncertain, the term “buy-in” refers to agreeing to do something you’d really rather not do at the risk of losing your job.  It’s been around a long time, but has flourished in the recession.

On the technical side, there are important funding issues to consider.  One of the biggest is the effect of architecture on the overall success of projects.  Studies have demonstrated that one of the biggest factors in ROI for IT initiatives is the quality of the underlying architecture.  Should you add features to your Windows XP app, re-write it to run on an i-Phone, or re-write it to run within your CRM system?  Big questions with lots of impact both in the short term or long term.

Conclusions

Senior engineering management is a tough job with many tasks and responsibilities, too numerous to list here, but including team dynamics, people management, strategic funding decisions, and golf at expensive resorts.  Middle management has similar responsibilities, without the golf.

Great organizations are rarely the product of good luck.  Great leadership recruits the right people, puts them in the right roles, identifies problems and fixes them, and looks ahead at trends to make sure resources are assigned to the right places.

In Scrum, this doesn’t require a lot of managers, but does require of lot from managers.  Empowering managers to act, and ensuring that they do, is critical to the long-term success of your Agile organization.