Firstly I should say that I am definitely PRO the use of Agile, and definitely PRO the use of SCRUM. I am also VERY much PRO AGILE, without total SCRUM. You'll see what I mean:
I have recently been looking at the job-boards as I decided it was time to move. Now, along with the usual technology buzzwords on the buzzword list, is the now almost ubiquitous requirement for Agile, or SCRUM, and slightly less so, Kanban or XP.
It seems that every job wants Agile. That's pretty good but what do they want and what does it mean?
Some companies I guess are very serious. They are prescriptive and formal with SCRUM. For those it can be applied to everything - ordering the coffee or creating their next geo-stationary satellite. Others are just 'kind of' in the space. They like bits of it, do bits of it, and are doing ok. How do you apply this SCRUM thing to the web-site dev team or perhaps the team doing the cargo shipping management system. The teams have different cultures and dynamics, different feelings, perhaps a different attitude to their trade.
I'm not sure a lot of people know what they are talking about when they talk about Agile. For me, Agile is a general set of ideas that benefit and tend to create successful software projects. I think that Agile is a type of thinking.
A place to start is the Agile manifesto. I'm sure this site will change over time, I hope so, but my first feeling when seeing this is not a good one. Before I even get to the merits of the text and the list of luminaries in the list of Authors, I'm thinking what a hideous thing to look at. I'm also thinking that it has a bit of a self-righteous feel to it. The Principles is where you should end up really. That's the meat and veg of the site. Forget that it looks like a prayer for some religious order.
The Principles behind the Manifesto
We follow these principles:
Our highest priority is to satisfy the customer through early and continuous deliveryof valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity--the art of maximizing the amount of work not done--is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.Link to the manifesto
This is the heart of it all. This for me, after years of fiddling with projects, is not only the fashionable thinking of our time, but it's the best chance of success.
What about SCRUM, DSDM...? Well for me, these are not what Agile is about. They are ways of playing at Agile for sure, but they're not what Agile is? For me, in a sense, they take away some of the agile ethos, yet they do deliver good projects. I'll explain.
Objectives of Agile
I think that the objectives of Agile are things like quick thinking, quick reactions, the stuff in the principles. It is about getting the right stuff done for the client and knowing that all of us, clients and project producers, will constantly be making mistakes in our understanding and communication.
Methods of being Agile
I think the SCRUM, the XP and the DSDMs of this world are the methods, the prescribed and prescriptive methods to go from the tools and techniques to the result. The result is the product developed by using the objectives.
Techniques for using in our pursuance of Agile
The tools - well I think they're things like TDD, Unit testing, User stories, DDD.
I think the three previous sections are a bit general and debatable, and probably a bit wrong. In a few weeks, if I review what I have written here. I may well change it but I think the principle is correct.
People say that the Agile thing started around '86 when Scrum was first mooted. I don't think it was used then though. It was much later.
I remember using DSDM in the late '90s, and then XP. I'm sure I didn't hear the term Agile though. One day it suddenly became very trendy to talk about Agile. It was an invented term to group these new ways to develop software. Kanban arrived in 2004, a few years before that the manifesto was created.
At one end of the Agile spectrum is the philosophical, the cultural aspect of developing software. At the other end is where the philosophical approach has been distilled and implemented with tools to become a prescriptive process. The prescribed process is something losing it's free spirit. Sounds a bit hippy, but the free spirit is dangerous. In the hands of the careless it is another lost project. In the hands of the lazy its an excuse. That is why we need SCRUM. SCRUM is therefore good. A force for good but it is not, in itself, the thing that is AGILE.
No comments:
Post a Comment