I like when people talk about Agile and different implementations. I like to listen to them, occasionally saying “Mhm”, “Yes”, “Of course”, when I am being presented with a bunch of papers with giant business plan, a year of initial implementation, at least year of development till the product can meet the market and get introduced to demanding client.
Where are we having the principle of people over processes here? Response to change? Software over documentation?
I think this is the time, for all of the agile-hunting lean lovers, to introduce the basic, very first, agile manifesto, on which all the frameworks (yes - these are only frameworks, someones ideas of how to make this four line into five hundred book based on which you will later on sell 600 USD ´worth´ certificates) are based. You have never heard it? Here it goes. I strongly recommend to learn it by heart:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
If you feel like you want to have it tattooed on your chest, or at least agree strongly with this being the core, you can sign here the very original statement.
Now, Jim Highsmith says “We not anti-methodology, in fact many of us want to restore credibility to the word methodology. We want to restore a balance. We embrace modelling, but not in order to file some diagram in a dusty corporate repository. We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes. We plan, but recognize the limits of planning in a turbulent environment. Those who would brand proponents of XP or SCRUM or any of the other Agile Methodologies as "hackers" are ignorant of both the methodologies and the original definition of the term hacker.”. Completely agree. What is the key? Dynamics.
Constant observation of the market (benchmarking will be covered here a lot) and quick response are the key of agility. The customer will not likely change a lot in a couple of months, but what if a solution does? We have to be prepared with that.
I remember when launching eRural (one of the very badly planned relaunches with an important lack of financial planning and estimations by the way. Happens) we were constantly monitoring the core competition. We based some of the UI solutions on the conventions used on other sites, including this one. A week before official beta online, they changed all the layout. We were stunned. I decided then to maintain the same one, change some bits for better UX, and see how it goes. We were past deadline, devs were on the edge of their nerves, we did not have time for massive replanning on core design. The small changes we actually did were relatively simple, but still, we should have been a step ahead. We were not.
Lets now see the 12 points of Agile Software Development, and apply the principle of common sense to make it even clearer:
Leave a Reply.