It is a design-centric view of Agile, or rather a War weary design centric view of agile.
The main point being that Agile is not a development method as much as it is a way of setting aggressive deadlines. What happens in one Agile project does not predict success for another. Instead the designer needs to be Agile in figuring out how they can best fit in. However, that agility should not extend to your design process. Designs still need to be well thought out concepts not something grown together in piecemeal increments.
The bottom line message (found on the last slide) is to be truly successful in Agile, you need to follow your own design process but be intimately involved in the Scrum process, preferably as a Scrum Master. This is essential for maintaining an overview of what is going on with your design. At the very least, own the user facing stories/requirements in the product backlog.
And Sherlock Holmes and Dr. Watson were meant to personify regression testing.
Agile & UX
View more presentations from Jonathan Arnowitz.
5 comments:
Great post! Nice how you put Agile in perspective.... didn't like wrestling anyways;-)
Jonathan,
I believe what you're describing is Agile 1.0--and you're right, it doesn't work. Fortunately we've moved beyond it.
Agile 1.0: Rapid, iterative process created by software architects. Disregards other players in the software game. Requires high-degree of autonomous, intelligent behavior and co-location.
Agile 2.0: Recognition that other disciplines are required to play the software game--and these are bolted onto the engineering Agile 1.0 process. It still doesn't work very well.
Agile 3.0: Recognition that there are various activities that wax and wane over the course of EVERY design / construction project. Enter "Rational Unified Process". http://en.wikipedia.org/wiki/IBM_Rational_Unified_Process
Agile is the worst software development process known to man--except for all the others that have been tried before.
@Liam Thanks for the thoughtful reply. However as long as current software engineering practice remains more in common with Machiavelli's prince than the written formal processes, i wonder what hope Agile 3.0 or even 4.0 has for success.
What has been your experience with companies utilizing this method?
The company I'm currently employed at switched to an Agile approach mid-way through a classic waterfall model that was going nowhere fast. So it looked more like a RUP / Agile 2.5 process than Agile 1.0. We are way too large and distributed an organization to ever do 1.0.
Ironically, many of the engineers who were comfortable with waterfall absolutely hated Agile. The monthly integrations and focus on producing working code in short cycles drove them bonkers. On the other hand it's better than coding for 2 years and then spending another year (or two) trying to make it all work together.
We are now in the process of formalizing / standardizing on RUP Agile. I think implementation of the formal RUP phases (inception, elaboration, construction, and transition) will be helpful in finally converting the doubting holdouts.
I've never seen a perfect software development process, and I'm pretty sure our flavor of RUP will have its rough edges initially. One key factor in improving the process is to ensure that the leadership team (including Ux) works to smooth out the rough edges so that all of the players can work to the best of their abilities, and the product life-cycle affords sufficient time for proper contributions from everyone involved.
Post a Comment