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

Moving on to New Responsibilities

Well, not moving on so much as transferring to a new position.

As of the first of the month I am transferring to an enterprise role in the Bank where it will be my official duty to help drive the adoption of agile processes in the Bank.

I know.  Agile and Bank in the same sentence?

The answer is, “Of course.”

What better methodology to use than one that does the best job (currently) of minimizing risk?

After managing risk, the next most obvious goal is to improve speed to market – we are in a competitive business after all.

Combining the twin goals of risk mitigation and speed to market gives the side-effect of managing the release of vast waves of change across dozens of disparate yet connected software domains.

Sounds like fun to me.

I won’t always (ever?) be able to get into the details of the trials and tribulations of revamping the process implementation, but I’ll do my best to post the play-by-play of the lessons learned as we go.

Keep in touch, it’s going to get interesting…

When is Helping, Hurting? Or, Another Example of Why Handoffs Should Not Be Documents

Sometimes, when you try to help, the outcome is less than desirable.

It’s like helping your kids with their homework.  Helping is one thing; doing it for them is something else entirely.  Sure, their grades are maintained, but at what cost?

The other day, I was working through a negotiation to get a non-standard package approved for use.  The problem was that the negotiation I was doing needs to be done by someone else in the group so that when I leave the group they will have a sense of how to get what they need.

I discussed this briefly with one of my co-workers and agreed to put together a kind of brain-dump email about how to go about the negotiation with some contacts, some suggested points, and some background so that he could do the official negotiation.  I’d already started the back-channel process by letting folks know that something would be coming through and laying an unofficial case.

I should say that I was on a floating holiday yesterday (Independence Day’s on Saturday) so the fact that I was checking my mail was purely by chance, but I received the official notice of the exception application for the non-standard package. 

What!?

My email had specifically said, “Talk to this guy first.” and “Send the license to this guy before you submit.”, etc.

Then I noticed an email to the first guy – after the application was filed – and I thought, “I said, TALK to him.”  I’m sure the license for the other fellow is in the mail too.

The whole point was to talk to the people in my email, get a sense of whether there were objections, and answer those concerns in the application.

Instead, my co-worker simply cut and pasted chunks of my email directly into the application – including some of the discussion points I’d included to help him with the VERBAL negotiations..

This bothers me on at least two levels. 

One is about the state of the organization and management maturity.

My co-worker is a guy further up the food chain from me.  What does that say about the organization’s ability to get what it needs in a larger whole?

I’m afraid that because of the lack of understanding and finesse exhibited by my co-worker, the application will have a tougher time than was necessary.

The other, is that I’m reading a book about reducing waste in processes, and I should know better: Documents as handoffs are a big generator of waste.

Handoffs should be higher bandwidth communication than a simple chat and an email.  So by sending the email, I was delivering a document with lots of content, but very little of the tacit knowledge that I have about the process – who to talk to, and how to talk to them.

What I should have done is say, “Tell you what; when I get back from my trip we’ll sit down in your office and go through the process.  That way, you’ll get to see how these things progress from back-channel discussions, to managing concerns, to the official application.”

Back to my first concern, I’m pretty sure he would’ve insisted he didn’t have time for pairing on a negotiation like that, and to send him an email explaining everything.

It seems like I fumbled the hand-off.  Or maybe I’m a control freak, and everything will be fine.

I guess we’ll see.

Latest on the Reading List

It’s been a while since I posted about what I was reading; mostly because I was reading current events instead of books. 

But anyway, as usual for me, I have two books going at once.  Both are tech books: Implementing Lean Software Development: from Concept to Cash, by Mary & Tom Poppendieck, and The Productive Programmer, by my buddy Neal Ford.

To early to get into details, but I like Neal’s folksy style.  I also liked Lean Software Development: An Agile Toolkit, the first book I read by the Poppendiecks.

I’ll give a full accounting in a couple of weeks.  Hang in there..

I Did Okay

The photo was actually taken by my wife, as I was enjoying my new title..  Out loud.

And further.. You can’t do Code Metrics in Visual Studio Team System Database Edition. Ridiculous!

So, I received some encouraging words from Mark Groves, the Program Manager for VSTS saying that UML is back in VSTS 2010.  See the comments on my previous post.  Thanks Mark.

That’s good.  A little late for me, but better than the alternative.

My latest frustration (Sorry Mark) is that there is an arbitrary limitation in VSTS Database Edition, namely that I can’t run Code Metrics on the code I can write in the tool. 

Ridiculous.

Apparently, to do that, I’d have to have VSTS Developer Edition installed – which I did, but installed the DB Edition for the database schema management functionality.

Annoying.

I know what the answer is though.  Get the VSTS Team Suite which has everything.

This is a poor answer because of the cost involved.  We have a team where we are trying to instill agile techniques and engineering practices.  That means everyone on the team does a little bit of everything, and common code ownership is what we’re after along with test driven development, et al.  Code includes database schemata too, by-the-way.

It doesn’t work well if the team has to be compartmentalized into a few Database Edition users, a few Development Edition users, and a few Architecture Edition users.  Maybe if there was a rotating license concept so that today, I’m working on Database issues but tomorrow I’m writing code like a fiend in the Development Edition; and the following day we’re collaboratively working on Modeling across the team.

Expecting development teams to absorb the cost of VSTS Team Suite in this economy is unrealistic and it’s driving us to look for alternatives.

I’m working up a list of .NET open source tools for the Bank in my capacity as a .NET Center of Excellence leadership team member.  This is a result of my cross-pollinating with the Application Lifecycle Management Center of Excellence, the Free and Open Source Software Center of Excellence and the Agile Users Forum.

Yeah, I’m busy.

So, if you have suggestions for Windows-based open source or inexpensive commercial best-of-breed solutions for .NET development by all means, let me know.  By-the-way, most of the tools have to be command line accessible to support Continuous Integration.  We are using JetBrains’ TeamCity in a pilot/proof-of-concept and it’s great.

Here’s a list of the tools I think I need.  Suggest others if you know of them:

• Build Scripting: Currently using NAnt, but being encouraged to use MSBuild (which itself sucks, imho.  A poor man’s NAnt – probably not enough exposure)
• Unit Testing Framework: Currently using xUnit.net
• Code Coverage: Currently using the last open source version of NCover.
• Cyclomatic Complexity: Open
• Refactoring IDE Support: Currently using JetBrains ReSharper

I’m starting to consider looking at SharpDevelop as an IDE, but I’d lose ReSharper.  That’s a tough one.  Another possibility is Eclipse if someone could create decent C# support.

I love the .NET framework, and generally I’m a fan of Microsoft products.  Hell, I’m using Live Writer to write this post.

But I’m getting tired of the splintering of products in order to pry an extra couple thousand dollars out of us.  In our case, that’s a per developer cost.  

That’s a lot of dough.

It’s no secret that we’re being asked to look for ways to be more efficient and lower costs.  Open Source is getting a close look at the highest levels.

Can you say Mono?

No UML in Visual Studio 2008? It’s true.. and stupid..

There I was this afternoon, backfilling a waterfall requirement to produce a low-level design of a feature that is on it’s way to production, when I thought, “You know, it would be really handy to fire up Visio and get a first cut of a class diagram for this.”

It’s been a while, so I fired up Visio 2007 and stated scanning the menu options, looking for ‘Reverse Engineer’.  “It’s gotta be here somewhere.”, I think as I plow through the options.

No joy.

Now it’s time for the help system.  It says, “Open the project in Visual Studio then use the Visio UML option from the Project menu.”

I opened Visual Studio Team System 2008, and started looking.

Nope.  Not in the Project menu.  I looked some more.  It’s not there.

Then, out of the fog that is my memory some days, came a remembrance of a conversation I had with a Microsoft Product Manager some time ago in Redmond.

(Paraphrasing) “The Class Diagram tool let’s us add whatever we want to the palette.  If we had to go through the UML standards body we couldn’t make the progress we want to make.”

Oh yeah… No embrace and extend this time.

More like, disconnect and ignore.

Microsoft has decided that Class Diagram is all we need.  No more Visio Add-in.  No more UML in VSTS.

It’s arrogant in the extreme for Microsoft to simply assert that the Class Diagram tool in Visual Studio is sufficient for developers’ modeling needs.  UML is the standard, and Class Diagram is not UML. 

The other rub for me is that it requires the Architecture edition.  What about all the developers in my group?  I guess they all need the Architecture edition — which doesn’t include the Database Edition functions?

By-the-way, Visio has always been a poor choice for UML in my opinion.  Unless something significant has changed (my prior experience was so bad, I haven’t bothered to look since), the better choice has been Sparx Systems’ Enterprise Architect product.  It’s not an add-on like UML is to Visio; it’s purpose built and priced competitively.

No I don’t work for Sparx.

Removing integration with UML tools, even a poor tool like Visio, is a bone-headed move.

It’s not news that they decided this.  I knew about this a while ago; like two or three years, and I’m sure others remember too. 

It just bit me today for the first time because it’s the first time in five years that I have had to do low-level design diagrams after the fact to allow the checking of a box somewhere.  No one will ever look at these diagrams again, once they are perused to make sure they exist – not for understanding mind you.

And, no it’s not really news that Microsoft has done something like this again.

Unfortunately..

Close.. So Close. And yet..

I was working on figuring out the latest Visual Studio Database Edition GDR when I came across this Microsoft definition of Agile Methods:

A family of processes that application developers use to minimize risk by developing applications in a series of short iterations that last one to four weeks. In this paradigm, the primary measure of progress is working software, instead of hours spent or tasks completed. Agile Methods emphasizes real-time communication, such as face-to-face meetings, telephone calls, and instant messaging, over written documents.

The documentation asked for Feedback.  Who am I to shrink from that?

Here is an except of the Wikipedia entry for Agile Software Development that is closer to the real meaning:

Agile methodologies generally promote a project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self-organization and accountability, a set of engineering best practices that allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals.

Notice that there is a reference to a "set of engineering best practices" (one of which — developer-level unit testing — is supported directly by the Database Edition, yet no mention). 

Notice also that there is no mention of a dearth of documentation. Documentation is a requirement to be prioritized along with the working software aspect.  But I digress.

My primary concern is that it be clear that Agile Methods stress a disciplined approach to creating high-quality software through engineering best practices.  It is not chaos with no documentation as generally assumed by those who don’t know any better.

And I’ll keep pointing that out whenever it’s necessary…