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

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 ?

   Reply

2. Back to top

   Links...

   by Jim Leonardo

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

   Reply

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?

   Reply

4. Back to top

   Re: Links...

   by Amr Elssamadisy

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

   Reply

5. Back to top

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

   by Edward Garson

   +1

   Reply

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

   Reply

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.

   Reply

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.

   Reply

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.

   Reply

10. Back to top

    Re: Clarification

    by Alexis Hui

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

    Reply

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.

    Reply

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?

    Reply

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.

    Reply

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".

    Reply

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/

    Reply

• Older >