Overall, it has been a good conference, with some sessions better than others. These are a genuinely nice group of folks that really do get community. For the most part, egos have been checked at the door and the sessions are extremely collaborative and open. Being just two days into it (it started on Sunday, talk about non-traditional), so far it is pretty interesting how much of this I, (along with my team) am already doing.
ü Moderate upfront design & architecture - check
ü Pragmatic modeling – check
ü Staged delivery – check
ü Living backlog of defect, features and work items – check
ü Automated builds – check
All of these things are typical of agile, adaptive or evolutionary practices, but this is only part of the puzzle. For example, thanks to one of my top mentors, Juval Lowy, I have learned how incredibly valuable earned value tracking is to the success and progress of a project. I adapted an excellent example of this into what I call an Earned Value Schedule (EVS). The ability to predict (quite accurately, I might add) how much a widget is going to cost (in man-hours) to implement and communicate that to the business is extremely powerful. As a result, senior management loves earned value tracking and it makes my job of answering “how are things going“ much, much easier (not to mention accurate). The value of an EVS cannot be underestimated and I would be hard pressed to give it up.
At the same time, there has been some low hanging fruit that is ripe for the picking as well as some new concepts that really make me go “hmmm.“.
That said, I am blown away by how hard the concept of agile seems to be for some folks. Either I am oversimplifying, or I just don't get it myself, but what I am confirming is that the big difference between what I would consider a mature software engineering approach and “agile” is the formal acceptance or instituting of the latter within an organization. I must ask myself if this formal acceptance is necessary to be successful?
For example, agile teams function through the collaboration and interdependence of:
- The customer
- The developer and or architect
- The business analyst
These roles are all somewhat overloaded, because the customer might be a stakeholder or a department. The developer/architect can be a part of the larger IT contingent (testers, release teams, etc). Finally, the business analyst is probably just that, or a team of analysts along with a PM or two.
Regardless, this all seems pretty straightforward, doesn't it? What's so difficult to grasp here?
Does the customer need to know that they are working with an agile team? Shouldn't we always serve the customer and try to balance features with resources and quality?
I am rambling, so I am signing off until tomorrow...
?>