Confessions of a Lapsed Developer

I think it happens more often to developers who become development managers, but that’s not the route that I took.

The world is suffering through the use of software designed or, to verbify a noun, ‘architected’ by former developers who ascended to the rank of software architect and decided coding was beneath them after that.  I didn’t go that way either, although I did occupy both of those roles, I continued to code while I held them.

No, my route to non-coding started when I decided that I had to be the one to try to make it possible for developers in a certain very large bank to practice Agile software development.  I spent four years in the corporate change group educating, explaining, presenting and otherwise promoting Agile methods as a valid and safe methods of developing not only software, but for performing any change.  My team and I made a lot of headway and now, Agile methods are considered an alternative in enlightened areas of the bank.  I feel that I was successful at that.

There’s another part to the confession.  While I was still coding and practicing Agile techniques, I was pretty much a purist in that I stood by the idea that simplicity should and would win over adopting frameworks like WPF, or WCF (I was primarily in the Microsoft world at the time).  I disdained data binding where custom controls hid all the ‘magic’ required to update a view.  I preferred MVP (Model-View-Presenter) later re-christened Passive View pattern, not only because of its inherent separation and ease of testing, but because updating the view manually allowed one to have literally Web, Windows or Command Line interfaces to the model and use the controller (or presenter).

These two elements of the confession mean that I probably have been outside of the mainstream of development for six to eight years – a lifetime.

I now find myself in a situation where understanding not only Javascript but AngularJS will be tremendously helpful and I am lost.  These new frameworks are full of magic, so I guess I’ll just have to get used to not knowing exactly what is going on.

I can still code in C#, and I can even push by in Python if I have to but these new frameworks in their new environments have me stumped – at least for the moment.

I have to relearn a lot of stuff, and re-orient myself to the new environments and I’m finding that summoning the energy necessary is extremely difficult.

If you have any shortcuts to knowledge and understanding for guys like me, I bet you could make a fortune.  I can’t be the only one who’s out here struggling..

If I figure something out, I’ll put it here.  I’m hoping you’ll do the same.

Origin Story (or Restarting a Long Quiet Blog)

This is the original “Pragmatic Agilista” blog. I’m claiming it.  I started it in 2003 on a different service and in fact, this is the third blogging service to host the The Pragmatic Agilista.  As an aside, I now wonder whether I should have called it Pragmatic Agilsto but that’s another story.

It’s funny, now that I think of it, how I came up with the name.  At the time, I was newly enamored of the Agile software development movement.  It was the way to solve all the things that were inherently wrong with the old way to develop software.  Since I had been writing software for different companies, in different countries for over 20 years at the time, I felt qualified to make that judgment too – so did many, many others but that’s beside the point.

So, back to the name. I had started my Agile journey by reading the “Pragmatic Programmer: From Journeyman to Master” back in ’99 or 2000 (I remember reading about the book in books column in Dr. Dobb’s or another now defunct programmer’s magazine) and excited by Kent Beck’s Extreme Programming Explained, I was off and running – or trying to; it was rare that potential clients were trying Agile in those days.

Partly, the “Pragmatic” in Pragmatic Agilista is a nod to the Pragmatic Programmer, the book that changed my programming life.  The other aspect is, as I said above, no one (near me at least) was trying Agile in any guise so the ‘pragmatic’ was meant to be ‘realistic’ or ‘not pure’.  ‘Agilista’ was because the ‘-ista’ suffix was fashionably applied to distinct (sometimes revolutionary) things and those devoted to them; think Sandinista or Zapatista.  (It’s true that the –ista suffix is also used to dis a concept, e.g. fashionista or Guardianista, but I chose it for the affirmative form).

Anyway, the title was meant to say, “Here’s a bunch of articles about being Agile in the real world by someone who’s into it” and apparently, I wasn’t the only one thinking about it in this way because by the time I thought about getting the domain name agilista.com, it was gone (I have but haven’t used agilista.net), and there are at least two other bloggers using “Pragmatic Agilist” as either their title or their identifier.

Why the long dissertation on the name of the blog?  Because it dawned on me this morning that to some extent, I am no longer ‘pragmatic’ about Agile; there’s no need to couch the intent – everyone and their neighbor claims to be Agile (or at least ‘doing’ Agile – more on that later).  On the other hand, after working at being Agile myself and helping others get to that state for 13 or 14 years now, there’s a certain reality to the journey that ultimately suggests pragmatism.  Maybe I should re-title to Agile Pragmatista?

Over the past, nearly six months, I’ve been writing a blog about my current heath issue – that’s not to say that I have a history of health issues, but this one’s a deusy (or doozy, if you’re less historically aware) – and I’ve enjoyed the experience (of writing the blog).  It has helped me deal with some things that I wish I hadn’t had to, but needed to handle.  So when I started feeling like my job was throwing challenges at me from different directions I thought, “Hey, why don’t I write it out on the blog?”

So, the plan is to come back to this as I think of things that I need to explore at the office and hopefully offer some insights into implementing an Agile environment.

We’ll see how it goes.

Fess up Apple Fanboys..

It’s a long story* but after many years of resisting the siren call of buying a Mac when all the cool kids were doing it, I have recently come into possession of a 2 year old Macbook Pro.

So here’s where I expect a confession from all the Apple fanboys.  I’ve been getting familiar with the Mac, adjusting preferences, installing Office:Mac, etc. and you know what happens?  Every time there’s a change to anything ‘important’ and even though I’m logged into an administrator account, I get prompted for my account password every time.

Weird.  Microsoft’s Windows Vista was raked over the coals for exactly the same behavior.  That was the beginning of 2007, and Windows 7 made that behavior a little more intelligent (Windows 8 makes the experience a little different but that’s another story).  This is OS X 10.6.8 which presumably is newer than that, but hey, I’m not a fanboy, so I can’t give chapter and verse.. and yeah, I meant that analogy.

Fess up fanboys; OS X isn’t that fantastic.  In the words of one of my old friends, “It’s just another operating system.”

———

* As a result of a relocation, we are moving out of our 3,000 sqft single family home into a 1,500 sqft apartment and the lawn tractor had to go.  A local craigslist listing was looking to barter a Macbook Pro for some lawn equipment and voila, I now have a much smaller package of equivalent value.

Two Sets of Books – Wrong Metaphor

You may have heard folks talk about having two sets of books; usually they say that conspiratorially and with a wink.

Why? Because when you have two sets of books, that means you are deceiving someone. You are literally telling one story to the authority (a false story) and another to yourself, or whomever you want to tell the truth to.

Gangsters have two sets of books. Long haul truckers who don’t like maximum drive hour restrictions (and violate them) have two sets of books.

You get my point. “Two sets of books” is synonymous with deception.

Why am I going on about this? I’ve heard several Agile advocates talk about this idea over the years. Early on, the idea was that management would be hostile to Agile and therefore, for the good of the company (and the team), we should go ahead and keep our Agile information to ourselves and tell management we’re doing something different.

I’ve never been comfortable with that approach.

One aspect of becoming Agile is being transparent, and two sets of books isn’t being transparent. I feel a lot better about telling it like it is, and educating folks about the data we have about progress that they never had before.

There’s a difference, though if one is talking about having a translation available to help guide folks to a new understanding, but that’s not having two sets of books. That’s having one book, with a translation.

So, for me at least, ‘two sets of books’ is a bad metaphor. Be transparent and say what you mean.

We’ve Heard This Before, but Where is the Value?

This morning I was fiddling around with TweetDeck (I’ve been neglecting my feeds) when I came across a tweet from Scott Ambler (@scottwambler) referencing a tweet from Tom Gilb (@imtomgilb), the guru of requirements, wherein Mr. Gilb exclaims:

Massive €142 billion IT failure. Agile did not solve it. Coders cannot solve it. Requirements cited. Wake up!

Here is the article, by-the-way: http://www.bcs.org/content/ConWebDoc/19584

The only trouble is that Agile is not even mentioned in the article, so the assertion that “Agile did not solve it” is disingenuous.

The article mentions that 7 of 10 projects were likely using Waterfall, based on some previous research, but there’s no mention of what the other three were – not even speculation.  The analysis goes on to explore multiple angles about where development efforts were stopped or not, leading to the conclusion:

Developing an alternative methodology for project management founded on a leadership, stakeholder and risk management should lead to a better understanding of the management issues that may contribute to the successful delivery of information systems projects.

Sounds like the way I describe Agile to folks.  No, Seriously.

But here’s the big miss as far as I’m concerned – and this goes for the various Standish CHAOS Reports that we hear about from time to time – the definition of failure is this false triangle:

…projects that do not meet the original time, cost and (quality) requirements criteria

Where is the value proposition? None of those three data points are important if the customer received enough value from the solution to make the investment worth it.

When will they add the question, “Did the resulting solution deliver enough value to warrant the extra investment in time/money?”

I’m not saying that any of those projects could be cast as successes if the value question were included in the analysis, but there might be some.  Do you think all those expensive and/or late projects were useless?

I doubt it.

Even leaving Agile out of it – although I think it would be hard to deliver software consistently in the following examples without using some elements of Agile – let’s look at some possible outcomes using strictly scope/cost/time:

• Your customer decides that you have delivered enough value after two thirds of the allotted time and don’t need to go further.  Failure (scope and time)
• Your customer realizes his/her initial idea had some flaws and changes direction to meet reality: Failure (scope)
• Your customer discovers that the competition has already delivered similar functionality and we need to add some new abilities: cost is not a consideration.  Failure (scope and cost)

I could go on, but you get the drift here: Scope aka requirements are the problem.  Or rather, signed-off, big-requirements-up-front contracts are the problem.

Yes, you can manage all this in a Waterfall environment, sort of.  But if you really could, you wouldn’t be using classic Waterfall, would you?

Agile methods provide an answer for these challenges because we concentrate on delivering value, close involvement with the stakeholders, and regular feedback at short intervals.

Value is the missing metric.

It’s Not That Simple..

In a recent post, Tim Ottinger & Jeff Langr gets to the inevitable snap-back point for all agilistas; “KNOCK IT OFF WITH THE TOOLS!” (I’m paraphrasing).

I understand the sentiment, but it’s not that simple.

In cases such as ours, we have heavy regulation, we have auditors, we have distributed employees all over the world.  Heck, it’s hard to find a US-based team that isn’t distributed.  I work from home myself, as do something like 18,000 of my co-workers.

We need tools.  Not one, but several to accommodate different technology platforms.  We need to have a centralized repository of stories and reports, like burn charts, velocity reports, test coverage, etc.  We need all those IDEs and refactoring add-ins and Group Chat clients and virtual pairing stations.  All that stuff.

I get the argument from some of the agile practitioners in our organization, “Look, open source projects have governance and distributed team members and all they use is e-mail and maybe Excel.”

Yes they do.

The key differentiator is that an open source team (even a foundation) is governing only one product, or one suite of products, not thousands or tens of thousands of applications.  Did I mention we have something like 100,000 technology staff?  I’m guessing we have 20-30 thousand developers.  Manage a portfolio like that with e-mail and Excel. 

Good luck.

There is no way that we can afford to send auditors to each team room wherever it might be; it’s just not realistic.  If we’re lucky (and sometimes, we are) we can get the whole project team together for initial story workshops and release planning.  The rest of the time it’s conference calls and LiveMeeting.

So, yeah, if you are working in a small company with a small team, or even a large company with a small suite of custom applications and a few teams of developers, use a whiteboard and a bunch of index cards.  It’s way more fun; I’d do it again in a second..

Reality for me and my co-workers is that we don’t have the luxury of that style of intimacy.

It’s just not that simple..

Support This!

So this morning I was notified that my new MindAlign account was ready to use and "don’t use your Office Communicator account after you install MindAlign."

Oops.

I installed MindAlign the other day when I requested access.

Sure enough, MOC was there running on my desktop, and equally sure enough, all the problems they said might happen did.

Crap.

The FAQ said to call local support to get my account reset – and stop running MOC.

I called local support and went through the usual stuff. Finally after about 30 minutes they asked, "May I take over the desktop and look into it?"

"Why?", I asked. "What are you going to do?"

"Uninstall and reinstall MindAlign.", came the response.

"Okay.", I said suspiciously. "You won’t wreck anything, right?"

"Of course not.", she said.

Famous last words..  Recovering now; or trying to…

You Call Yourself Agile?

We had our monthly Agile Users’ Group meeting today.  Did I say meeting?  What I meant was, announcement.  Or something.  It was a completely one-way affair; from us to them.

I have no idea how many ‘agile’ practitioners were on the line today.  The reason I don’t know is that we don’t take attendance, and very few people speak up.  Most of the time, we have to call someone out by name to get a response to a question. 

I’m beginning to wonder if these folks get what it truly means to be ‘Agile’.

I work in a bank; I know what it means to be frustrated by arcane process rituals that don’t necessarily add value.  There are some obvious ones like High-Level and Low-Level design documents that are only as valuable as the paper they’re written on because the actual running design changes once the rubber meets the road — and the documents never get updated until you are replacing the system at which point they’re useless by definition.

Imagine trying to run a project in an agile way while all the management and governance folks are still using waterfall sensibilities.  You can think of ten ways that this would be frustrating, maybe more than ten.

Apparently, everything is okay in these folks’ environments.  No frustrations, no problems, no areas where they could use a little guidance.

Really?

Maybe it’s just me, but Agile means caring about the work you do, it means changing the way you do things for the betterment of the project.  It means passion!

I’ve never worked on a truly agile team where there weren’t strong opinions about how to change things for the better.  If I offered a ThoughtWorks team 10 slots on a call to improve a process, at least 15 would show up.  That’s what I’m talking about.

For the folks on the call this morning: Ho hum.  Silence.

I fear for our transformation efforts if this is the level of excitement people are feeling.

The only hope I hold in this case is that folks are so beaten down by the waterfall and that they don’t believe (yet) that our team is for real.

We are.

Or that they are cynically using this time to take an hour out of their schedule to do other things; “Sorry, I’m busy between 11:00 and 12:00.”  They put the meeting on and ignore it.  Maybe a combination of the two.

I hope not.

Our team is for real.  We are working the waterfall issues – and succeeding.  We have management behind us.  We need these ‘practitioners’ to get involved.

Wake up guys.  A true Agile project option is coming.

I hope you’ll join us.

What is the Agile Sweet Spot?

An interesting question came to us from an executive sponsor of our initiative: “What is the sweet spot for Agile?”

My initial response was unspoken; “What do you mean, ‘sweet spot’?  Agile is best for all projects!”

Then, I thought better of that response.  He was, after all, an executive sponsor.  Too much passion may be passion, but it’s still too much.

So, I went away with this question in mind, and I’ve been thinking about it pretty much every day ever since.

I saw an article by Tom DeMarco in the IEEE Software magazine, entitled “Software Engineering: An Idea Whose Time Has Come and Gone?”.  In that article, he makes a great point: There are essentially two kinds of projects, ones that have significant value, and ones that have marginal value.

Tom makes the argument that marginal projects require greater control over the lifecycle in order to manage the expense versus the returned value.  Whereas, projects with a greater or more significant value relative to cost require less control.

This sets up a paradoxical situation.  Quoting Tom:

This leads us to the odd conclusion that strict control is something that matters a lot on relatively useless projects and much less on useful projects.

Nice!  That appealed to the elitist agilista in me.  But how was I supposed to go to the executive sponsor and say, “Well, Agile projects should be ‘restricted’ to those projects that matter most.  Use Waterfall for the projects that don’t matter.”?

No way.

But, what did dawn on me was that ‘projects that matter most’ is a good analog for strategic projects.  So what is the opposite of strategic..

I was watching some conference videos this evening, and one that showed on my radar was a talk by Martin Fowler in Australia at the Amplify ‘09 conference.

He makes an excellent case for strategic versus infrastructure.  And he gives the ratio of 80/20 or higher (i.e. 85/15 or 90/10) infrastructure to strategic.

Perfect.

That’s what I’ve been feeling, but didn’t have a way to say it.

Apply Agile to Strategic projects.  Apply Waterfall to Infrastructure projects.

I know.  You’re saying, based on my previous discussion above, that infrastructure doesn’t matter.  That’s not what I’m saying at all.

What  I am saying, echoing Martin’s presentation, is that infrastructure projects are more like commodities; there’s value, but it’s low margin.  And that’s okay.  In fact, we couldn’t do our business without it.

But, if you want bet your business projects to get the most value faster, you need to do it in an Agile way.

And it’s a lot easier to scale 20 percent, or less, of the project portfolio than a higher ratio.  And to get business buy-in and their dedicated time.  And justify cross-functional teams.  And justify co-location.  Etc.

I feel like I have something I can work with to answer the ‘Sweet Spot’ question.

Let me know if you have a counter to this, but I’m feeling pretty optimistic..

Another Fun Quiz..

Okay, you probably guessed this much:

My Political Views
I am a left moderate social libertarian
Left: 6.71, Libertarian: 2.89

Political Spectrum Quiz