Tag Archives: Agile

Weather the Storm (or ‘learn something for next time’)

I’ve had a lot of thoughts to blog, just not a lot of time. Not to make excuses… if you followed my twitter you’d know I try to stay busy.

Rubyconf was great, my talk was ok, B+ maybe, I learned some lessons, next talk will benefit, lots of cool smart people, trying to explain Puppet to Ruby developers is always interesting. I gave another version of the talk at the Utah Ruby Users Group.

Ignite Salt Lake was epic, but apparently the AV capture was a fail.  Total lighting fail and everyone is really dark in the video. This is sad because the talks really were excellent.  The strategy is to try some image processing and see if there is anything worth salvaging, and if not just take the audio and match it with the slides. Another lesson learned, next time will be better.

My wife is traveling almost every week lately for interviews and leaving me home with the boys.  She is trying to match in an opthalmology program and the whole process is black magic, which means a bit of stress and we have no idea where we will be in 6-18 months.

Part of me wants to stay here in Salt Lake City, because I love the high mountain desert and will always have roots here, but I always like new things and it would be nice to get acquainted with a new town.

I’ll be glad when the process is over one way or another.

There seems to be an upsurge in the Agile backlash lately, but I have personally made most of the same observation/critiques before.  Should make the next Agile Roundtable discussion more fun.  On a related note, there seems to be an upswing of ‘pastry‘ searches on blogs (maybe just the holidays).  Oh well, popularity drives dilution, and now I really really really want to have an AgileFringe conference.

I feel some good posts percolating… (next time will be better…)

Advertisements

Miles Per Gallon

In truth, a good case could be made that if your knowledge is meagre and unsatisfactory, the last thing in the world you should do is make measurements; the chance is negligible that you will measure the right things accidentally.

George Miller

Last week I drove to Los Angeles with my wife, two kids, my mother-in-law and her sister in our not so eco-friendly SUV. Hilarity ensued, but that’s not the point of this post.

I don’t usually drive this car. Until recently, most everything in my life was in about a 5 mile radius, work, play, whatever. The SUV is ‘her’ car; my wife drives it to where she does research and home most everyday.  Occasionally, we all get in and go somewhere exciting, like grandma’s.

You are starting to wonder what is the point, and I’m hoping I’m about to make some.

This late model SUV has a speedometer, a tachometer, and in addition has a computer that is estimating instantaneous MPG and average MPG since the last fillup, since the beginning of the trip, since the epoch, etc.

On the way to LA, with this SUV stuffed full of people and random stuff, I averaged just over 20 MPG at ~80 MPH. On the way back, I averaged 25.6 MPG with the same people and even more stuff and nearly identical MPH.

On the way there, I kept watching the gauges and thinking ‘these rolling hills are killing my gas mileage’. On the way back, I was optimizing the speed and acceleration patterns, only dipping below 20 MPG on the steepest inclines.

If one rides a bike on hills, he or she figures this out pretty fast. There are certain speeds you can hit a hill that can be maintained with less effort than it will take to go slower, all this is based on fitness, the equipment and the hill. Also, acceleration uphill is fairly expensive. Your body figures this stuff out because energy expenditure and efficiency have consequences, and the feedback is rapid.

In an automobile, I doubt I ever would have figured it out without the gadgetry.

You can’t manage what you can’t measure.

What does this have to do with software? Velocity is a commonly used idiom in project planning. I’ve seen velocity measured different ways in practice, and seen it’s measurement discussed in many more.

But I’ve never really seen efficiency measured with relation to velocity. The only time efficiency is considered is with respect to getting more velocity.

I’ve never seen anyone in a planning meeting ask, how can we maintain this velocity more efficiently? Is this velocity the most efficient? Over the life of any decent sized project, this seems like it would be important.

(Aside: The XPers might, as they have a notion of sustainable pace, but I’ve never been in a pure XP setting. I’m starting to think they only exist in legends or they are like the Jedi scattered by the clone wars trying to cultivate the force in swamps and deserts… I’ll be at Agile 2008 this week, so I’m hoping to come home with some new Jedi minds tricks.)

How many miles per gallon are you getting? Are you losing MPG to the rolling hills?

Perhaps the more important question, how would you know? What do you measure? (The instantaneous estimate feedback was key for me, hmm…)


Agile Infrastructure

True stability results when presumed order and presumed disorder are balanced. A truly stable system expects the unexpected, is prepared to be disrupted, waits to be transformed.

-Tom Robbins

One thing that became clear as software practices matured and self-optimized was that not being able to build a project from source in an automated fashion can bring development progress to a grinding halt, particularly as more bodies are added. Without that ability to build from source in a predictable manner, which is the predicate for any flavor of test driven development or continuous integration, the development efforts from a growing team is like so many butterfly wings each capable of unleashing storms on the unsuspecting halfway around the world.

But how many organizations dependent on a web application can reliably build their production servers from bare metal? automatically? unattended? When your application is a ‘service’ on a server, how is that fundamentally different from building a traditional application from source?

How does capacity planning change in a world where ‘Digg’ and ‘Slashdot’ are explicit goals? When Facebook can drive adoption? When adding new servers changes from a purchase order and weeks of waiting to a web service call?

If you want to participate in this ‘as a Service’ brave new world (get up in that ‘aaS’ if you will), and your plan to bring up new servers involves a meatcloud sshing their little hearts out, you might as well give up now. Seriously…

How Agile is your infrastructure?

How Agile is your infrastructure?

Further, what is the plan to manage the life cycle of the servers? Most people have figured out that ‘tail -f’ is not a monitoring solution. But how many of them know exactly what is running on their machines and why? How many have servers that they are afraid to turn off because they aren’t sure what is running, but it might be important? How many configure a server, back away slowly and hope they aren’t the next one who has to touch it?

In another recent episode doing some custom Puppet work with Luke, who has essentially crossed the Developer-Sysadmin divide (I’m not sure he is a chief of the new tribe, but he’s definitely a shaman), Luke became frustrated that he couldn’t write Puppet code like he could Ruby code. (He had not written complex Puppet code for a while, since he stays pretty busy working on Puppet’s internal code.)

Sure, I guess this would be awesome if I was a sysadmin, but I can’t test this code. The only way I can have any confidence it works is to run the whole thing. I guess I just take for granted all the tools that are available to me as a developer now.

Luke Kanies

How does it change things when your infrastructure is code? Can be versioned and diffed? Can be shared and reused? Can be tested? Continuously?

How awesome will PuppetUnit or PuppetSpec be?

Test Driven Infrastructure?

It is only a matter of time…


Adopting Agile (The Art of the Start)

In theory there is no difference between theory and practice. But, in practice, there is.

-Jan L. A. van de Snepscheut

So you decided you want to be Agile, what now? First ask why? Do you really believe in the principles or has something else convinced you to become buzzword compliant? Have you read Fowler, Martin, Cockburn or Beck? Do you know the difference between XP and Scrum? Have you heard of Crystal? Do you know the pitfalls? Have you read the critiques? the rants? Do you know all the personalities involved and their biases?

How could you? Who has time for that? Oh, and the software project that the life your company depends upon can wait for you to sort it all out? Not likely. . .

While we deliberate about beginning it is all ready too late to begin

-Quintilian

A reoccurring theme for teams adopting Agile practices is what may seem like an overwhelming sense of chaos as the old habits and sensibilities collide with the new. The chaos can be real or perceived, but is most prevalent in teams where Agile is being adopted without a lot of experience, often without buy-in or organizational support and on top of a legacy code base. Furthermore, the fledgling Agile champions, while enthusiastic, are trying to balance the notion that the methods only work if they follow all the disciplines and the fact that there is no possible way a team can adopt all the practices instantaneously.

Let me be clear, I personally think Agile, as embodied by the values of the manifesto, is about as good a way to approach the problem as one can get, but transitioning a team can often be a source of pain. In fact, let’s remind ourselves what those values actually are, because in practice, I think people often lose sight of them.

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

No river can return to its source, yet all rivers must have a beginning

-Native American Proverb

How to proceed? Well, that depends, where are you at now? and where do you want to go?

There are plenty of blogs and books and consultants, which offer appropriate advice, and depending on whether you have more time or money these can be great resources.

Here is my free unsolicited 2 cents of self referencing advice for teams who really want to deliver, take it for what it is. . .

Focusing on Trust and Results, a lot of problems will just melt away. Standups, sprints and software will just become byproducts of commitment and accountability. Honest conflict in retrospectives optimize the process.

I’ve got no science for you, just faith. (Unless someone can give me a way to measure ‘trust’)

Like I said, take it for what it is. . .

So where do you start?

Create trust, problem solved.


Shared Metaphor: Gnome Cloud Meat Pastries 2.0

The problem with communication … is the illusion that it has been accomplished.

– George Bernard Shaw

Underpants ????? Profit

One of the topics arising frequently in my conversations is the need for clear vocabulary to describe emerging concepts forced by technical evolution and how those concepts fit into to a personal understanding of the world.

Dialects arise, but until we have shared symbols and metaphors these discussions must always be clumsy. (after we have shared vocabulary, it will still mostly be clumsy)

This is a feeble (and misguided) attempt to share some metaphor.

Gnomes: Some of you might know of venture funded technical start ups that are going to change the world. Some of those start ups might have ridiculous valuations and little or no revenue. Some just have no revenue. . . at least they have a business plan, good luck with that.


Clouds: Everyone knows about ‘the clouds‘ Or maybe they don’t? Or maybe the whole point is that they don’t? Or something? Some anonymous thing over there does something like this other thing I once knew and could touch. . .


Meat: Every organization probably has some hardware and some software, but even in sophisticated technical endeavors there are niggling little tasks that probably should have been automated a long time ago. How are those tasks accomplished? Meatware. . . but of course.


Le Patisserie: This might be less common for some, but I fear those of you in software might have lived it in one form or another. This might also be referred to as ‘dessert tray‘ Agile, or euphemistically as frAgile development. You take one part flailing development organization, two parts buzzword compliance, cut in some shortening or lard, and then bake until golden brown, top with whipped cream and viola! Sprinkle with legacy code if you want a real treat!!

Now comes the fun part. . . mix and match. I haven’t found a permutation that isn’t relevant, informative and amusing. (Ok, so I might be easily amused)

Cloud Gnomes – a virtualization startup

Meat Pastries – developers doing mind numbing repetitive work with Agile razzle dazzle fairy dust.

Meat Clouds – Uhm, like. . . built the pyramids and make your shoes

I leave the rest as an exercise for the reader:

Gnome Meat Pastry Clouds

Cloud Pastry Gnome Meats

Pastry Meat Cloud Gnomes

. . .

Pardon me, I have to get back to playing with puppets . . . and gathering underpants.


Less is More . . . doh!!

Smaller projects are more work, not because they are, but because they encourage a business to pile a bunch of them on top of each other.


Dysfunction: Avoidance of Accountability

The ancient Romans had a tradition: whenever one of their engineers constructed an arch, as the capstone was hoisted into place, the engineer assumed accountability for his work in the most profound way possible: he stood under the arch.

Back to The Five Dysfunctions of a Team, so we have built up Trust, Conflict and Commitment. What do we need now?

Accountable: subject to the obligation to report, explain, or justify something; responsible; answerable.

In the model from the book, the avoidance of accountability is a psychological byproduct of the underlying dysfunctions of the team. Without firm commitments, after healthy disagreements are addressed, there is a tendency to not hold people accountable. We have a hard time holding people accountable, when we know they never really committed.

Ok. . . uhm, and?

How many of you have witnessed(participated in) the following scenario?

  • Incredible pressure to deliver a product/feature
  • Developers are hacking their little hearts out (very few tests being written, of course)
  • Quality Assurance is testing whatever they can see flying over the wall (with little or no prior knowledge of what it will be, bless their little hearts)
  • Product Management is doing whatever they do (anything but looking at what is actually being developed)
  • Daily stand ups where no problems are mentioned
  • We are so Agile, yay

Features delivered are a disaster. . . PMs are freaking out, Devs are indignant, QA is whimpering in the corner. What happens next? Rinse and Repeat. . . WTF?!??

I believe one of the fundamental principles of all Agile methods is ‘Reflect and Adjust‘. The built in adjustment is only going to help your team if it isn’t used as an excuse to ‘just do better next time’.

It is not only what we do, but also what we do not do, for which we are accountable.

– Molier

That doesn’t mean I’d advocate command and control shock and awe style, that just puts everyone into ‘cover your donkey’ mode and totally destroys the foundation of trust.

Honestly, Good Product Management is HARD. Good development is a creative endeavor that ebbs and flows. Good Quality Assurance is an acquired skill. All of these pieces are heavily dependent on each other.

Holding each other accountable doesn’t have to be antagonistic, but it does have to be honest. (truth, remember)

Brutally honest… Shit happens, but it doesn’t have to happen all the time.

Around the time of Caesar, there was a European tribe that, when the assembly horn blew, always killed the last warrior to reach his assigned place, and no one enjoyed fighting this tribe.

Don’t settle for mediocre, for yourself or for your organization.

Some people can’t handle ‘Truth’, and that is the seed for every other dysfunction.

Change your ‘organization’, or. . . change ‘your’ organization.

add to del.icio.us :: Add to Blinkslist :: add to furl :: Digg it :: add to ma.gnolia :: Stumble It! :: add to simpy :: seed the vine :: :: :: TailRank :: post to facebook


%d bloggers like this: