Why bother about requirements? – I am Agile!
Again I was triggered by a post I read on the glorious source of infinite stupidity, the internet 😊
This story triggered me this time:
“Requirements were hard enough to manage in the bad old waterfall days. Here, mr XXX will take you through how you can do it, and keep your job, when working with agile.
On a recent project, Stories with unclear requirements were ending up with developers. It was a pain point. Time was spent trying to clarify missing pieces meaning less time to write great code and meaning developers ended up under even more pressure to get things done”.
I can just say WOW!
Just to start of on the right foot here, I am a firm believer of requirements being the way to clearly specify and manage a complex problem and turn that into a hopefully correct (not so complex) solution, satisfying all relevant stakeholders.
And clearly, the “bad old waterfall” could create an analysis paralysis and a heap of useless documents in the dark ages of engineering, even if those people managed to travel do the moon and get us into the age of computing, but that could have been just luck and a lot of late hours I guess…
But getting back to the Agile folly in the beginning. These people DON’T want to write things down because the want to “write great code”. I guess it speaks for itself?!. They rather have a dozen of sprints than try to work proactive. It better to do something and potentially do it wrong (having an imaginary sense of speed and progress), then taking it down a few notches and examine the problem before they develop the solution. It seems that these agile evangelists never heard about the 80/20 rule?!
Back logs are reactive and story boards and yellow stickers are the most documentation these guys (and girls) want to do…
I am so glad that the coders have compilers saying “syntax error” before the code get into the SW system itself. Unfortunately, people don’t have this function and garbage in equals garbage out and its manifested by lack in functionality, bad quality and a lot of frustration.
Going Agile is great for small, isolated and not so complex tasks where the developers can sit as a team in a room and “write grate-isch code” and have a fun work environment and getting instant feedback from the users. I don’t question that, but I am sooo glad that complex and safety critical systems uses more rigid and “robust” development practices. By the way, what happened to Rational Unified Process, RUP? I thought it was a great attempt to become less stuck with paperwork and more “light on the feets”.
Again, requirements in any shape and form; natural language text, models, user stories, personas, even as I saw the other day pictures and drawings on a white board, is there to illustrate and COMMUNICATE a need and put focus on solving the right problem in the right way. The biggest issue is that humans have one compiler each (our own brain) and syntax errors are introduced when we think that we understand, guess and interpret things based on our own experience, logic, motivation, drivers, culture, language, etc.
So, please, please STOP being digital, saying “I am Agile” (most popular) or “I am NOT Agile” (old dinosaurs). The real systems engineer says, “it depends” what processes to use and it should not get in the way of trying to develop a CORRECT, COMPLETE and CONSISTENT understanding between all parties involved and I am a strong advocate of doing so before I start to run to manage the resources and risks, but that’s just me…