“We write Code in Agile Teams” vs “ Too much Talk, No Working Code” — Software House Principle
Did Your Boss want’s “Scrum” or “Agile” because it’s the best “IT Principle” to work in XXI. Does “Waterfall” vs “Agile” or “Scrum” is the best way to make “Working Software in Estimated Time Plan” ?
Some companies give the Role of Scrum Master for the Most Experienced player in the Team, some for punishment to work with PM/PO that are “bad” at Team Play. Anyway, the workflow will end like This !!
Stand-up meetings in Scrum (a common Agile approach) are an annoying interruption at best, or at worst one of the mechanisms of “subtle control”, where managers drive a team while giving the illusion of shared leadership. “We should end Scrum and Agile” == “We are developers. We write code.”
Even test driven development, where developers write tests to subsequently verify the behaviour of their code, comes in for a beating. “This is so ridiculous. Do you think you can model the real failures that happen in production? No,” says Meijer.
I love the “move fast and break things” model, where software is deployed and errors fixed as they are discovered. It gives Developers freedom and best production speed for coding. It’s a holy ceremony, when You are thinking about the potential solution for the problem — Please, don’t disrupt US.
Here’s the thing. If you go to developer conferences and hear the like of Kent Beck or Martin Fowler (both Manifesto signatories) speak, you discover that the essence of Agile is less a particular way of developing software, and more an insistence that team members communicate with and respect each other, and that the “team” includes every stakeholder, including the users.
If Agile has failed, it is because of its success. As soon as smart Agile development teams started delivering good results, companies started coming up with tools to help others do it right. Businesses could buy into the illusion that Agile is a tool you can buy, and vendors were happy to profit.
Potential in Software companies come not only when “code works” and everything is “time-to-market”. It is a complex solution. Requirements are the most “holy grail” of all application lifecycle management. Design, writing CODE and at the end System in use are starting from that point. Please , make your SPECIFICATION.
Write good Software — Don’t do additional stuff for PM’s
Please relax, think about your school years — did someone interrupt you while you were writing your essay, just to ask You “What were You doing 5 min ago, what are you now writing and are there any problems ? “ NO !!!
It’s not an easy job to make abstract thinking work when there is a pressure of “deadline” estimation. People like to have it “clean” “simple” to explain but IT Programming is like a “mix of math, mix of english + ortodox grammar”
The End
