Share this:

As I read and commented on Mike Gualtieri’s post on Agile, my mixed feelings about Agile burst into my chest.  I violently agree and disagree at the same time if that is possible.

Through the years of managing Software Products, I saw some benefits to Agile like most, but the claims of a beautiful world of on-time software with all the promised features is simply too good to be true — Dave Rooney, Veteran Agile Coach, concurs in his response to Mike.  I have always worked with world-class developers and architects…  But I know that, with the aggressive schedule we have to put together, with the complexity of enterprise software components, there isn’t much room for experimentation…  Agile helps address some of it, but it won’t make everything perfect.

Agile has flaws

In his criticism of the Agile Manifesto, Mike makes an excellent point that Agile has been too narrowly focused on Software Development, confusing the end with the mean.  We may have been losing sight of the true objective, which is not to write code of course, but to build applications that serve a purpose.  It is all about catering to the users to make them more productive, more efficient, more effective.

Writing code that runs is the way you get to empower those business users.

So, yes, Agile helps with the end goal as it contributes to its success.  But if you obsess on this metric only, without paying attention to what matters to the users, you will end up with a failed project.  On time.  But useless.

In order to ensure that the application serves a purpose, the Manifesto recommends joining forces.  With business users involved full-time, they can voice their needs as the software gets built.  This is the next strike:

“Business people and developers working together daily” is lazy. This principle is a capitulation by developers who say it is impossible to understand the true requirements. Developers would much rather stick with what they know: typing class definitions, if-then-else statements, and looping constructs into glorified text editors.

Mike loves provocation…  Clearly we need some collaboration between the 2 partners, but joining them at the hip may not be the best way to get there.  I agree with that.

The most critical aspect, in my interactions with Engineering, was to get them to see the vision I was painting.  Having them ask me every minute if I liked “that button here” would not have scaled, and would have alienated everyone.  Micromanaging is bad for a manager; it is bad for a business or product owner.  But if you can have them understand how and why you ask for features, then they will likely make much better design decisions.  Then the interactions can really focus on the tricky, contentious use cases.

In that way, Agile helps ensure that both parties discuss the requirements for the sprint at hand and establish the success criteria.  I think this is great.  But if this is done in a vacuum, without a good understanding of the big picture, there is a risk that the details take over, ignoring at that point other paths in the software.  For applications, it may not be as much of an issue; but, for software tools, the implications tend to be much deeper in terms of impact on the architecture.

Agile can be beautiful with Design

That being said, all methodologies have benefits and flaws.  It is much more productive to look at the good, the bad and the ugly; then select the relevant aspects of the methodology that you will enforce.

I, again, violently agree with Mike that Design is key.  Design is a term that has been abused so let me elaborate: user experience has traditionally been considered as second-class citizen of Software Development.  The classic argument is that “we can always add lipstick on the pig later”.  But UX is more than a pretty user interface.  As Mike admirably pointed out: it is about the EXPERIENCE.

Let me try a stretched analogy here…  If you are in a gorgeous vacation destination…  Bora Bora or the likes…  The “pretty picture” is certainly there…  But if the resort design makes it such that you have to:

• Get up super early to grab breakfast while the activities only start much later in the day
• Choose between your favorite activities because they are only available for short and overlapping hours
• Give up on watching the sunset on the ocean because it is the only time you can get dinner… and the dining room has no windows
• etc.

I am pretty sure the beauty of the site will not overcome the frustration that you accumulate during your stay.

The same thing is true for a business application.  If you have to hop from one part of the UI to another with a long series of clicks; if you can’t get both pieces of information you need at the same time; if you are stuck waiting for a result because the modal window would not let you work on something else while the job runs…  then you are likely to feel as frustrated…

This is the kind of design we need to take into account early on; not after the code is released.  The is the design that makes software successful.

We all admire and will remember forever Steve Jobs for his talent at “user experience”.  He created beautiful designs, so beautiful in fact that he made millions and millions of people want things they did not even need.  We are not all as “insanely great” unfortunately, but we can get inspired to think about the experience from the start.

As a personal story, with Sparkling Logic SMARTS, we wanted to create such an experience.  It is not about the functionalities — although they are fantastic ;-)  It is really about “being the business user” and “thinking like the business user”, to create that unique experience.  It was hard for a tool vendor, but the brilliant idea was to make the tool disappear and the business user become the stage.  Mike’s analogy to a film studio is very true.

Agile leads to agility?

The methodology is meant to add agility in the software development process.  Compared to waterfall, you have more opportunities to adjust to the business requirements.  In that sense it is more agile.

What we have called Agility in the Decision Management space is different though.  Agility is the ability to change the way you do business much faster than software life-cycle.  The idea is to empower the business users to craft how the system processes transactions.

I will actually present in a few days at Rules Fest how Agile methodology applies to Decision Management, introducing a new way of thinking about knowledge elicitation.  I encourage you to come to the session if you are in the Bay area.

Advertisement