Has Agile jumped the shark?

The Agile community is in danger.  As someone who has been around Agile for a very long time I find myself asking; Has Agile abandoned its core premise and begins a decline in quality that is beyond recovery. First the punch line.  Go to Wikipedia and search for “Jumping the Shark”. http://en.wikipedia.org/wiki/Jumping_the_shark   Here’s an excerpt;…

4

Just when is it good enough?

In theory, software development is precise.  Some even argue it’s a kind of engineering.  After all it’s just ones and zeros … processor gates and electrons.  Personally, I disagree. Software is an ethereal manifestation built by people for people.  It’s barely bound by the laws of nature and rarely if ever viewed by any 2…

0

Who cares about your Agile development processes?

I find myself thinking that the software industry is far too focused on impressing itself instead of delivering solutions to people.  That somehow it’s all about us.  It isn’t.  In recent years we have pasted the tipping point where the means, methods, processes, and techniques we use to build bigger, more challenging, more complex things…

0

Requirements aren’t evil, we are.

Requirements aren’t evil, we are.  Really.  We, the software developers of the world are solely responsible for the problems of our industry.  It’s not the process, methodology, or whatever school of thought is winning today’s beauty contest with its sleek bikini elegance and wholesome customer love.  It’s not the ever more sophisticated tools that promise…

4

10 analogies for creating software (that aren’t building construction)

Software has long suffered with the analogy of building construction. While it is certainly handy, and generally well accepted, I would like to propose my top 10 alternative analogies for software development.  10- Politics Creating software is like being an elected official. You get into it to do something, achieve something, and participate in something…

0

Requirements are tools not weapons

Consider these requirements; · The system shall properly calculate the taxes due at the time of payment. · The system shall properly display the location and speed of inbound projectiles. · All users will only be able to change data appropriate to their role. They are a clear example of poor communication and are likely…

1

Fighting the Fear, Uncertainty, and Doubt

There are a few reoccurring themes in project recovery;  Hold Fast, Don’t Flinch, Lead calmly, and of course the old stand by … decide slowly but act quickly.  Troubled projects are ripe with Fear Uncertainty and Doubt (affectionately known as FUD).  Our job, like it or not, isn’t just creating and delivering a solution but…

0

It’s just software …

It’s just software … really, it’s just software.  It’s not as important as your family, or your health.  It (generally) doesn’t kill people or change lives.  That kind of thing is left to real people.  I will concede that those real people may be using software to help them kill people or change lives but…

0

Agile versus Formal modeling

In response to a recent discussion over at Yahoo on the requirements Engineering list, a question was posed as to why “just enough” was ever okay when creating a model.  After all incomplete models or improper use of a modeling standard has to be bad… right?  I believe there is another perspective on modeling to…

1

A risk-reward scale for evaluating project practices

So you’re seeking to improve things. You tried to implement a “best practice” or twelve … how did that work for you? I am convinced that problems addressed by a well known practice will not always result in a well known and positive result, and it seems I am not alone.  In a survey of…

1