InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

Father of Use Cases Says Agile Needs to Get Smarter

Posted by Shane Hastie on Apr 03, 2009

Sections
Process & Practices,
Architecture & Design
Topics
Methodologies ,
Agile
Tags
Culture Change

At the Software Education SDC conference in Melbourne, Australia, and Wellington, New Zealand, last week, Ivar Jacobson, author of the original work on Use Cases, the Unified Modeling Language and the Rational Unified Process, said that Agile development needs to “Get Smart”.

He stated that the information technology industry is very fashion conscious, having a tendency to latch onto silver bullets, and listed the following examples:

  • Fifteen years ago it was all about OO
  • Ten years ago it was about components, UML, Unified Process
  • Five years ago it was about RUP and CMMi
  • Two years ago it was about XP
  • Today it is about Scrum

All have good elements – but none is what we need, what we need to do is to Work Smarter. He says “Being Smart is an evolution of being Agile”:

  • Agile means being flexible and adaptable
  • Agile provides simple/lightweight starting points
  • Being Smart is knowing when to go beyond agile
    • Knowing when to follow the rules and when to break them
    • Knowing when to be consistent and when to change
    • Knowing when to grow and when to shrink

According to Jacobson “Smart is Agile++”. He continued to give examples of a number of smart (and unsmart) practices and approaches he has recognized over the years. Some of the Smart and Unsmart practices he identified are:

  • Unsmart with People – viewing processes and tools as more important than people
  • Smart with People – recognizing and understanding that software is built by people, not with processes and tools!

    “A fool with a tool is still a fool but a dangerous fool”
  • Unsmart with Teams – Teams organized into stove-pipe groups with separate responsibilities (requirements, analysis, design etc)
  • Smart with Teams – Cross functional, small (ideally 10 or less people) self organizing teams with the right mix of skills to undertake the work.

    “A software team is like a sports team with all needed competencies to win”
  • Unsmart with Projects – Trying to follow a waterfall approach
  • Smart with Projects – Build a “skinny system” to demonstrate that you have eliminated all the critical risks, then add more capabilities on top of that skinny system as needed.

    “Think big, build in many steps”
  • Unsmart with Requirements – Trying to define all the requirements up front (a constant in software development is that requirements WILL change)
  • Smart with Requirements – Base early decisions on lightweight requirements and detail as and when needed – requirements are negotiable and priorities will change

    “Design your project for requirement changes”
  • Unsmart with Architecture – no architecture is as bad as trying to design everything up front
  • Smart with Architecture – just enough architecture to build the skinny system, architecture must result in executable code

    “Start to build a skinny system, add muscles later in small steps”
  • Unsmart with Testing – having two classes of people – developers and testers. Unsmart projects testers are “the cleaners in the software world” – picking up the mess left by the developers
  • Smart with Testing – the whole team is jointly responsible for quality and testers are first-class citizens

    “Whatever you do, you are not done until you have verified that you did what you wanted to do”
  • Unsmart with Documentation – slavishly filling in a document template because some process rule says it has to be there
  • Smart with Documentation – recognize the “law of nature: people don’t read documents”. Document only what is absolutely needed

    “Focus on the essentials – the placeholders for conversations – people figure out the rest for themselves”
  • Unsmart with Process – continuously latching on to the latest fad, and trying to change everything you do in response to the newest rule book
  • Smart with Process – Don’t throw out the baby with the bathwater:

    1. Start with your existing way of working
    2. Find the pain points
    3. Change one practice at a time

    “People don’t read process books, so focus on the essentials, people figure out the rest for themselves”

 The key element to becoming Smart is to focus on the people, as Jacobson says, and “it all comes down to you”.

Shane Hastie is an agile coach, trainer and consultant working for Software Education in Australia & New Zealand

  • This article is part of a featured topic series on Agile

Related Sponsor

In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!

15 comments

Watch Thread Reply

It sounds like Devoxx 08 by David MARTIN Posted
Links... by Jim Leonardo Posted
Re: Links... by Amr Elssamadisy Posted
This is just plain old Agile, I don't see any ++ by Curt Hibbs Posted
Re: This is just plain old Agile, I don't see any ++ by Edward Garson Posted
Re: This is just plain old Agile, I don't see any ++ by Rob Elliot Posted
Re: This is just plain old Agile, I don't see any ++ by Amr Elssamadisy Posted
So I've been dumb all this time? by William Pietri Posted
Clarification by Shane Hastie Posted
Re: Clarification by Alexis Hui Posted
Re: Clarification by Jim Leonardo Posted
Re: Clarification by Mark Levison Posted
Re: Clarification by chuang johnson Posted
Agile is not a silver bullet indeed, but... by Roberto Fasciolo Posted
Alec Sharp blogged on the same conference by Shane Hastie Posted
  1. Back to top

    It sounds like Devoxx 08

    by David MARTIN

    It sounds to be the same presentation Ivar Jacobson did at Devoxx 08. Can anyone confirm ?

  2. Back to top

    Links...

    by Jim Leonardo

    Is it me, or are the links a little fouled up?

  3. Back to top

    This is just plain old Agile, I don't see any ++

    by Curt Hibbs

    I hate to sound critical of someone of Ivar's stature in our industry, but I fail to see how any of the Unsmart/Smart examples are Agile++. They all look like standard Agile to me.

    Am I missing something?

  4. Back to top

    Re: Links...

    by Amr Elssamadisy

    Yes the links are fouled up - we'll get right on them.

  5. Back to top

    Re: This is just plain old Agile, I don't see any ++

    by Edward Garson

    +1

  6. Back to top

    Re: This is just plain old Agile, I don't see any ++

    by Rob Elliot

    Agreed - all the smart/unsmart points look just like my understanding of Agile

  7. Back to top

    Re: This is just plain old Agile, I don't see any ++

    by Amr Elssamadisy

    So, are we missing something? It is hard to dismiss someone like Ivar, at the same time, I agree with this sentiment.

  8. Back to top

    So I've been dumb all this time?

    by William Pietri

    Like others, I'm not seeing what else Jacobsen is suggesting. Even after skimming the recent articles on his blog, it's not clear to me. Is it possible he hasn't seen any good Agile teams in action?

    I've read things from a number of yesteryear's luminaries that make me suspect that they're opining on the Agile movement mainly from what they hear and read, rather than from the kind of direct experience that informed their earlier work.

  9. Back to top

    Clarification

    by Shane Hastie

    I suspect I missed some of the essence of Ivar's message in my summary of his talk. He made a strong point that much of what he is saying is indeed Agile as it is intended to be, but that he sees a lot of organisations trying to implement Agile by rote, thus repeating the mistakes of the past.

    Agile isn't a silver bullet and he was encouraging his audience (in the Wellington conference mainly government and large company business analysts and project managers) to think carefully about the people factors and not expect to get the benefits by somehow applying a methodology recipe out of someone's book.

  10. Back to top

    Re: Clarification

    by Alexis Hui

    Agree, I think Shane has uncovered the motivation behind Ivar's talk...

  11. Back to top

    Re: Clarification

    by Jim Leonardo

    What's most interesting is that he is pretty much saying plainly and clearly "Waterfall is terrible".

    I've been part of an organization that has been trying for several years to pass off waterfall as RUP, these statements coming from Jacobson will really help me make my own case.

  12. Back to top

    Re: Clarification

    by Mark Levison

    If that's the case how is Ivar any different than James Shore or any one else talking about bad/mediocre agile implementations in recent months?

  13. Back to top

    Re: Clarification

    by chuang johnson

    I think the point Ivar talked is not about Agile at all, it's about people. "Focus on people" is the smart way.

  14. Back to top

    Agile is not a silver bullet indeed, but...

    by Roberto Fasciolo

    I've just blogged about this in my blog: believerdiary.blogspot.com/2009/04/agile-or-jus...

    Besides what I've blogged I'd like to add that I think the way Ivar used for expressing that Agile is not a silver bullet is maybe the wrong one, as people could easily get the message that "Agile is not smart".

  15. Back to top

    Alec Sharp blogged on the same conference

    by Shane Hastie

    Alec Sharp (one of the conference speakers) blogged about the same talk here alecsharp.com/

Educational Content

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.

Interview: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.

Beauty Is in the Eye of the Beholder

Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.

Architecting Visa for Massive Scale and Continuous Innovation

John Davies examines Visa’s architecture and shows how enterprises have architected complex integrations incorporating Hadoop, memcached, Ruby on Rails, and others to deliver innovative solutions.

Max Protect: Scalability and Caching at ESPN.com

Sean Comerford unveils ESPN.com’s architecture, what components are used and why, and the current changes the website goes through.

The Seven Deadly Sins of Enterprise Agile Adoption

Are there repeated patterns of failure on Enterprise Agile Enablement efforts? Sanjiv and Arlen discuss Seven Deadly Sins to avoid when adopting Agile in an enterprise.

Questions for an Enterprise Architect

Erik Dörnenburg answers: What is Enterprise and Evolutionary Architecture?, discussing 4 issues: Turning strategy into execution, Ensuring conformance, Where do the architects sit? Buying or building?

Wrap Your SQL Head Around Riak MapReduce

Sean Cribbs explains what Map-Reduce and Riak are, why and how to use Map-Reduce with Riak, and how to convert SQL queries into their Map-Reduce equivalents.