41–47 of 47 posts
But it seems to start with the implicit assumption that Agile is good, and non-Agile is bad, and the information is some almost off-the-cuff notes on their own particular definition of Agile.
Warning in the article: > "Meeting requirements is treated as more important than getting something useful into the field as quickly as possible." I've got a bad feeling about this. It seems like the kind of attitude that leads to last Friday's Crowdstrike update.
I see where you are headed, and certainly unscrupulous entities will it as an excuse to cut corners, but I think they are talking about the case where someone produces something that will clearly not work, while still meeting the letter of requirements. Having good requirements is important, but making them is iterative as well, and having to treat software developers like an evil DM when you are casting the wish spe…
This document has no teeth. It is more simple than this … does it have fixed scope and fixed timeline ? If so it’s not agile.
It is part of an effort that will have impact. Remember that the US federal government is the largest IT spender in the world. This is part of their efforts to move agencies internally I using a carrot first. Now that the GAO officially released an agile audit guide, the stick is in place. GAO Agile Assessment Guide https://www.gao.gov/products/gao-24-105506 Note that in the public sector, appropriation committees ha…
Earlier quoted context omitted.
Share the link, not just the PDF, to give more legitimacy ;)
I strongly dislike it on one count. It actively promotes using the choice of tools as a marker for "true agile". They go so far as to reword the first item to exclude any references to tools. I have seen plenty of groups using all the right tools, full of individually skilled developers, producing garbage late to schedule. The reason is that they did not interact with each other in a way that lead to success. They dr…
Earlier quoted context omitted.
I strongly dislike it on one count. It actively promotes using the choice of tools as a marker for "true agile". They go so far as to reword the first item to exclude any references to tools. I have seen plenty of groups using all the right tools, full of individually skilled developers, producing garbage late to schedule. The reason is that they did not interact with each other in a way that lead to success. They dr…
Reminds me of a slide made by armchair architect in the previous company I worked for :)