This is something has been nagging at my mind in the last couple of years. When I started getting interested in eXtreme Programming in 1998 it represented a step up from some of things I was already doing with software development teams. We were using techniques best classified as Rapid Application Development. First eXtreme Programming and then the Agile manifesto represented lightweight methods to get software shipped.
There are two important parts of that last statement:
1. lightweight methods
2. software shipped
The concept of doing the simplest thing to achieve a goal, is an important part of eXtreme Programming. Traveling light (or not carrying baggage from previous experiences) is an important part of being agile. One of the aspects of agile that I always found attractive was the objective of enabling the development team to deal with change in short time frames.
While it may not be fully apparent, from the behaviour of many software development teams, the objective of developing software is to ship a product, a finished piece of working software. This desire to find better ways to get software shipped is clearly not something everyone in the industry shares. that is why we have collections of rules that appear to do nothing than keep people in jobs. Don't get me wrong, I appreciate that in certain situations we need 5 people analyzing the business rules in order to determine how to build software that manages a complex business process. The reality I often see is that the business process is not that complex and the reason the team has 5 business analysts is because the career path for developers in that company is to be promoted to a business analyst role.
I digress...
The reason for this post is to try and make you think about how the actions you are taking are really making you more agile (small 'a'). If your objective is to be able to handle change with as little pain as possible then following a hard set of inflexible rules is not going to help you too much.
Shipping software is a art that is not easy to teach by laying down a set of rules, in many ways it is much more like a creative activity than an engineering activity. Decisions have to be made that are not pure engineering decisions, they are not pure business decisions, nor are the decisions purely design oriented. It is a combination of all of these things and more.
Questions that need to be answered include; is the software aesthetically pleasing to the user, is the software functional, is the time right to release this to the market, etc..
There seems to be this constant flow of software with rules designed to help people become Agile, there are also more and more people professing to have the ultimate rule book for Agile software development.
In my opinion this is 90% bogus, the number of people that have a career telling other people how to ship software and have not actually shipped software in years (or ever!) amazes me.
If you want to be truly agile then drop as many tools as you can, learn to do more with less rules and restrictions, and most of all practice shipping software by actually shipping software!
Subscribe to:
Post Comments (Atom)
3 comments:
Yes, very good. The intent of agile is far more important than a set of rules prescribed by some dogmatists.
Well said Dr. Neil! Here Here! Love your comment about how to ship solutions .. when these same 'teachers' haven't even done it themselves. So typical :(
-Justin A-
Well said, Dr Neil!
I've seen some implementations of agile development that put Kent Beck to shame.
And you're right, agile is just about coding and shipping.
BUT I think you've nailed the biggest problem - decisions are neither technology nor business, so it's a synergy of the two that is required to achieve goals. However, in reality there is a 6 ft fence between the two, and overheads to maintain the interactions via the fence cost more than the real work on both sides of it. The last thing you need is more people on the fence telling how to interact across the fence in line with agile methodology :)
The only real (and working) way to apply agile is to bring that fence down and get business people to work with technology people as a one team. That's why smaller companies are so much more productive - they can't afford the overheads and simply have to deliver.
Post a Comment