：Agile Needs to Get Smarter

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
          o Knowing when to follow the rules and when to break them
          o Knowing when to be consistent and when to change
          o 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”.