Agile vs Waterfall vs Lean Startup : Who Cares About the Labels?

Labels

After reading Shane Hastie’s latest InfoQ article:  Lean Startup or Agile or Lean Startup and Agile?  it became clear how much we’re all getting caught up in labels and methodologies.  My thought:  let’s drop the flag waving, become pragmatic in our approach and recognize that context plays a crucial role here.   What works for Eric Ries and his start-up may not work for the company you work for and the project you’re currently executing.

The Real Value – Techniques & Tools

The value in methodologies like Agile, Scrum,  Lean Startup,  Waterfall and others is in the techniques and tools they bring to the table.  While they are each packaged with a neat title and some intelligent proponents; we don’t need to use these in a take it or leave it fashion.  Be pragmatic and assemble your own toolkit.  I’ll reference Scott Ambler and say “context matters“.  We all need to move towards a collection, library of project and product management patterns that can be adopted within certain contexts.

Innovate 

Lastly, what’s invigorating about these debates is that we’re growing as a field.  We’re rethinking our ideas, and not settling.  This can only be good for software development and those affected, infected by it.  Yes, I meant to say “infected”.  🙂

The Pragmatic Manifesto

This is a manifesto for pragmatic software development.  We are uncovering sensible, common sense practices for creating better software.  We value:

1. TEAMWORK: Working as a team with our customers, our team members, and our leaders to accomplish the product, project and company goals.

2. FLEXIBILITY: Flexibly adjusting our practices and efforts to meet the needs of the product, project and team.

3.  HUMILITY: Accepting that we don’t know everything and we should always strive to learn more and adjust our efforts as needed.

4. DISCERNMENT: Not get caught up in the latest buzz, but think for ourselves, our team, our product and our customers.

5. RISK MANAGEMENT: Realize that “risk” and the management of it, is the greatest determinant of software development success.  This doesn’t necessarily mean we avoid risk.

6. TALENT: Recognize that teams are composed of people with varying strengths and weaknesses.  There are no supermen. Sometimes we shine…sometimes we’re learning.

7. VISION:  Seeing the future and present and crafting solutions that will address both.

If you believe in this manifesto…then do it.  No need to sign up, attend classes, write books or pontificate. Just, live the principles.

Christopher R. Goldsbury

Decline of Written Requirements

Introduction
Requirements managers, project managers, and business analysts will find the most interest in this article. Developers will find a nice challenge at the end.  🙂   In this article, I attempt to show that written requirements are no longer necessary….and a new tool, using new media….is necessary.
Why did written requirements fail us?

Requirements gathering, analysis and management has never been easy.  It’s hard work filled with nuance, half-truths, mis-interpretations, ulterior motives, impressions, imagination, emotion and misunderstanding.  It’s vision crafting.
Getting everyone on the same page to a clear and sufficiently detailed model of the proposed system requires a conductor with the right skills.  Too critical to be ignored, a lack of depth in this area can doom a project.
To help codify that vision the software industry quickly turned to documentation and documentation standards.  But, written requirements have proven to  be an inadequate fit with the abstract nature of software and these flaws became apparent:
  • “That’s not how I read it”
  • Versioning Changes
  • Big complex software = big complex requirements = never read/hardly understood
It was realized by a myriad of software professionals that relying exclusively on the documents and omitting en
gaged conversations to clarify the written word was a mistake. But….spoken requirements and conversations have these flaws:
  • “That’s not what I heard or understood.  That’s not what I remember.
  • Hallway conversations, informal clarifications that aren’t heard by all parties.
  • Complex requirements can’t easily be remembered, conveyed through conversation alone.
  • Change management is non-existent.
User stories attempt to blend the spoken and written worlds and emphasize the continuous interaction between customer and software development team.  They rightfully restored the need for conversations and engaged business domain involvement and got us away from the never ending refinement or versioned requirements books.  They get us closer to where we need to be.  But, they still miss the mark.  Some flaws of user stories and their crafting are becoming apparent:
  • Software and business teams change…..leading to a loss of highly valued historical domain knowledge that may or may not be documented in the code or the story.
  • An awful lot of time is wasted writing these down, editing them, and then clarifying the exact meaning.
  • It’s a fine line.  How much to write?  How much to discuss?  Too little and the story is worthless.  Too much and we’re back to writing all our requirements.
  • Complex business domains and logic need to be documented in detail.  A simple story ( or many simple stories ) with acceptance criteria may not be enough.  Think about requirements for the Boeing 787 flight control system.
  • User stories assume the business owner will be available ( static ) for clarification during much of the project: not a safe bet.
Where are we headed?

With the proliferation of digital video, cell phone cameras, webinars, social media, and whiteboards we have a new set of building  blocks to create the 21st century requirements management tool.  And that is my challenge to the community.  Build it.  Use these pieces to create a new tool for managing requirements that further reduces the risk of interpretation.  Here are some advantages I see:
  • The historical integrity of that requirement conversation ( and its vision ) would be preserved for any future teams to review and understand it….nuance and all.
  • Verbal as well as non-verbal communication would be preserved and could be analyzed later for better realization of the requirement.
  • Whiteboarded artifacts could easily be recorded and saved along with the video.  Adding to a thorough documentation of the conversation.
  • While this wouldn’t completely eliminate the need for clarification of requirements; it could sharply reduce it.
  • Productivity in requirements gathering  and recording could potentially jump helping out the entire software development process.
If you feel you’re up to the challenge…:)….then contact me ( chris@effectivelogic.biz ) and I’ll give you further guidance requirements.

About the Author

Christopher R. Goldsbury is a software development professional who has played the roles of developer, architect, scrum master, development manager, project manager and quality assurance manager  throughout his career.  Chris writes on his experiences and ideas at his blog: http://www.anagilestory.com.