21–30 of 85 posts
Isn't a system specified by legislation fundamentally at odds with an agile process? Neither the requirements nor the dates could change without an act of Congress (or in some cases, the President).
Isn't a system specified by legislation fundamentally at odds with an agile process? Neither the requirements nor the dates could change without an act of Congress (or in some cases, the President).
Most of the Legislation on finer points of implementation are simply "In a manner that the Secretary shall designate."
Talk about process all you want, but everyone is just waving their hands around spouting buzz words. A technically experienced (in large scale systems) management team can make sure the project is done right regardless of the process they use.
I suspect that the answer is none.
But if I'm wrong, it'd be interesting to know what tools they tried to use and where there processes worked, if they ever worked at all.
Let's face it- Agile has become a codeword for let's micromanage software developers while increasing the pressure on them to deliver. My theory is that Ken Schwaber and Jeff Sutherland came up with Scrum in order to limit management's ability to screw up software development in corporate settings. That was mixed with some observations about the need for iteration, not doing upfront work when it's wasteful (and it's…
> figure out some way to qualify what makes good software engineering I doubt we'll ever be able to distill it to a formula. People ran successful software projects decades ago, long before any methodologies were formally described. And they have failing projects now, even when they use a supposedly good formal methodology. Instead of another alternative to waterfall, scrum, or agile, I'd propose the following ingred…
The best answer is probably to get people who are experienced in similar projects to manage your project, and has little to do with the process they choose to use.
Let's face it- Agile has become a codeword for let's micromanage software developers while increasing the pressure on them to deliver. My theory is that Ken Schwaber and Jeff Sutherland came up with Scrum in order to limit management's ability to screw up software development in corporate settings. That was mixed with some observations about the need for iteration, not doing upfront work when it's wasteful (and it's…
> figure out some way to qualify what makes good software engineering I doubt we'll ever be able to distill it to a formula. People ran successful software projects decades ago, long before any methodologies were formally described. And they have failing projects now, even when they use a supposedly good formal methodology. Instead of another alternative to waterfall, scrum, or agile, I'd propose the following ingred…
I know there's no silver bullet but those of us who have been through a few projects have a pretty good idea of what's going to work and what isn't. We can tell, well in advance, what's going to work and what isn't both in terms of the technical approach and the management process. Agree?
If that is the case how do we convert that intuition into something that can work in the real world? Is certification the answer? Specialization? How do we recognize excellence?
No, it failed because it was managed by technically inexperienced and/or incompetent people. These people know who they are (the contractors), but they won't admit it. Talk about process all you want, but everyone is just waving their hands around spouting buzz words. A technically experienced (in large scale systems) management team can make sure the project is done right regardless of the process they use .
What I wonder is how many political types are still telling the new fix-it czar, Jeff Zients, what he can and can't do. I.e. right now all features that can possibly be punting into the future should be.
Although he said his #1 priority was to stop sending garbage to insurers, which isn't particularly political at this point, one would hope.
Let's face it- Agile has become a codeword for let's micromanage software developers while increasing the pressure on them to deliver. My theory is that Ken Schwaber and Jeff Sutherland came up with Scrum in order to limit management's ability to screw up software development in corporate settings. That was mixed with some observations about the need for iteration, not doing upfront work when it's wasteful (and it's…
A good product a day late is still a good product. A bad product on time is a world of hurt not just for the programmers, for sales, the users, getting next projects etc. In the end it is good project management and programmers/contractors that can build a solid product, not just deliver on weekly Agile tasks. In the end the quality and product result from where people place their demands. If it is time as the main demand, over shipping a good product, then we know what happens.