The History of Agile

history-of-agile-timeline

The timeline above contains some key moments in the history of agile, and some other interesting events taking place at that same time for reference.

  • 1970 – Waterfall Model was created (by Winston W Royce.) Interestingly enough some of the risks he called out have been realized and are much of the reason we saw agile come into existence.
    • “I believe in this concept, but the implementation described is risky”.
    • “The required design changes are likely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything…. are violated. Either the requirements must be modified, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a 100-percent overrun in schedule and/or costs.”
  • 1970 – Also, Gas is 36 cents per gallon. Wut?!
  • 1990 – Jeff Sutherland and Ken Schwaber conceived the Scrum process in the early 90’s.
  • 1991 – Also, the release of Nirvana’s Nevermind signified the start of the Grunge era that would dominate the music scene up to the mid-90’s.
  • 1995 – Scrum is codified in 1995 in order to present it at a conference in Austin, Texas (US) and published the paper “SCRUM Software Development Process”.
    • Scrum was first tried and refined at Individual, Inc., Fidelity Investments, and IDX (now GE Medical). These weren’t simply startups with greenfield development efforts.
  • 1995 – Also,  OJ Simpson was found NOT GUILTY!
  • 2001 – In February 2001, Jeff and Ken were amongst 17 software development leaders creating the Manifesto for Agile Software Development. – Their goal was to take all the good things they’ve learned and create a “charter” for others to use. By this time there had been many variations of agility that evolved.  The manifesto was taking the best of the best and boiling it down to principles rather than a framework or methodology.
  • 2001 – Also, Lord of the Rings comes out in Theaters

Key Takeaway: Agile is not a flash in the pan, and is something that has been evolving for 20+ years. I believe we are even starting to see Agile become more of the “norm” in Software development. Agile as a mindset opens up the door for so much more than just SW Development.  What do you think will be the key points in time for agile 20 years from now?

Advertisements

“That’s Not Agile”

right_way_and_wrong_way_sign-other_zps8c090af3

If you work in an organization that utilizes one of the many agile methodologies, you have probably heard the statement “that’s not agile”. It could be about a proposed process change, or a critique of an existing way of doing things. It baffles me to no end when people get lost in the weeds about if something they want to try as a team is agile. This is unfortunately very prevalent in Agile Coaches and Scrum Masters who have a lot of experience.  Since agile is an emerging idea that is really starting to catch some momentum, some who have been advocates for a longer period of time can be standoff-ish about how to do things.  This should be a huge red flag, because there are so many variations of agile and not every organization is the same. You can know all the right things, but completely fail at helping a team adopt agile. That is why it is very important to be flexible, and not have a “better than” mindset.  The principles of agile/scrum are meant to be a guide, not a law that must be perfectly adhered to.  I’m not suggesting you should throw all caution to the wind and try any and everything, because “everything’s agile!”  No.  What I am primarily addressing is the way in which this topic is approached.

So, who’s right?  Maybe saying “that’s not agile” can be valid.  Or maybe we’ve lost sight about what agile is all about.  Let’s just take a quick peek at the Agile Manifesto for a refresher on what it’s all about:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

To be brash: If someone tells you “that’s not agile” and it’s something that could enable one of the 4 agile main points of the manifesto, I would seriously question how well they truly understand agile.  And agile by nature is something that I believe will continue to evolve as people uncover better ways of doing things. (sound familiar?)

If your organization is looking for an Agile Coach or Scrum Master or you are just trying to improve your skills in that realm, here are some suggestions for what not to do, and what to do.

  1. Don’t try to impress anyone with your agile credentials.  Do try to identify things that have been successful on similar teams/organizations.
  2. Don’t be preachy when trying to present new ideas.   Do suggest ideas with a humble and flexible attitude.
  3. Don’t rely solely on past experiences of what worked for other teams.  Do spend a lot of time listening to people’s needs an challenges.
  4. Don’t react when people are critical of agile.  Do find a way to tie what people want back to agile principles and show them how they could enable those things.
  5. Don’t press your own agenda.  Do thoroughly understand how you can support management’s vision.
  6. Don’t treat the agile principles as a law.  Do use them as a guide for making continual improvement.
  7. Don’t be too critical of a team’s existing processes. You never know how much hard work they have put into building what’s there. Do make a point to try to build on existing foundations, and position it as an improvement rather than tearing down.
  8. Don’t be too quick to judge what will work best for  a team.  Do ask a lot of sincere questions and follow the breadcrumbs of how things became the way they are.

 

Hopefully the next time you want to say “That’s not agile” you can remember the big picture and help your teams find the very best solution.  What things are important to you as an agile proponent in these regards?  Do you have any good stories to share?