Technoetic

Kevin Brady claims they are in his recent blog article “AGILE /SCRUM Fails to get to grips with Human Psychology“. After reading his article, it seems it should have been named something like “Agile Methods Do Not Cure Dysfunctional Organizations”. I believe the latter is true. I think agilists understand this at some level and that why they focus so much on the “agile attitude”. My belief is that this “attitude” is a psychological prerequisite of a potentially agile team. Agile methods can’t reliably create this psychological state, but they definitely require it. Without an agile attitude (focus on business value over politics, people-centric, empowering, …), it’s not surprising that organizations would experience the Orwellian effects that Brady describes — no matter what software development process they chose to use.

However, it also appears that Brady has a limited understanding of the agile methods he criticises. Continue Reading »

Agile coach and trainer Mishkin Berteig recently wrote a blog article called “The Seven Core Practices of Agile Work” where he highlighted the importance of effective (“powerful”) communication. I agree. In my experience, effective communication is often the most important factor in project success. However, my views about the nature of effective communication are different. Berteig wrote:

To Communicate Powerfully, a team needs to prefer in-person communication over distributed communication. Synchronous over asynchronous communication. High-bandwidth over low-bandwidth communication. Multi-mode communication over single-mode communication. — Mishkin Berteig

These suggestions sound agile on the surface, but it could also be just a different variation of the “process over individuals” perspective. Continue Reading »

James Shore wrote an interesting blog article called “Voluntary Technical Debt“. He and Dave Woldrich are developing a commercial service called cardmeeting.com to support distributed agile teams. Shore describes how he and Dave cut corners with their initial implementation, intended to be a “spike“, because of time pressure to demonstrate the software at the Agile 2006 conference. In other words, they intentionally created technical debt to meet a marketing deadline. The team is now taking the time to repay that technical debt — with interest. Shore reports that the debt has caused delays in developing new features but he believes he made the right decision.

I’m not questioning whether this was the right decision or not. However, this is a classic development pattern for non-agile teams. Continue Reading »

People sometimes ask me why I write open source software in my spare time without being paid for it. It’s an interesting question that I sometimes also ask myself. There are quite a few reasons and I thought I’d describe some that probably also apply to many other open source developers. The following is a list of potential benefits of participating in an open source project as a programmer, designer, writer, community builder, community support or similar roles.

1. Acquire New technology Skills. Is there a programming language or library you’ve been wanting to learn but is considered too leading edge to use in your day job. You could either start an open source project or join an existing project that uses the technology. You’ll learn the technology better by applying it to real problems instead of just reading a book and studying simple examples.

Continue Reading »

As I described in a previous post, I created a very experimental version of XPlanner using Ruby on Rails. A few people have expressed interest in the code so it’s available for download. Remember, this was created about a year ago with an older version of Rails (0.10 or 0.11, if I remember correctly). I might be a good idea for somebody to create a RubyForge project for this code, but I personally don’t have time to manage (I might contribute, though).