Category: collaboration
Photo (c) Janusz Gorycki
"Still working the old fashioned way with whiteboards, spreadsheets and outdated software?” – I have stumbled upon an agile consulting company's web site with this slogan on the main page the other day. Efficiency! Speed! High Tech! Aren't we all supposed to be after these? Well – not at all times. So yes – our team maintains the old fashioned habits, uses low-tech, old school corkboards, does the planning sessions playing planning poker with actual playing cards (Piatnik brand if am not mistaken). We even sometimes plot the burndown charts manually, with pen and pencil. And we do it for a reason.
Don't get me wrong – the modern, efficient tools are useful. Hell, my company is making money producing and selling them! But – they are not everything, and they are not always appropriate. Use them as a tool, not as a gospel. There are things more important for your team's and project's success than the use of fancy software.
The quality of the team and the caliber of its members is more important than the efficiency of its processes – nothing controversial about this statement really, this fact has been well documented in some pretty classic books on team management ("Good To Great” by Jim Collins comes to mind). And the old fashioned rituals are crucial in maintaining the team spirit and identity. This is because people happen to be wired in such a way that it makes them feel safe and comfortable if they can devote some time every day to repeatable old habits. And teams become better integrated if they have some common habits that they care to repeat every day – as a team. Liturgies and rituals do matter a lot – and there is no reason for these rituals to be overly efficient. That's not their purpose to be efficient.
Bookmark/Search this post with:
This week, I have had the distinct pleasure… the rare opportunity… to attend the PMI Global Congress in Denver, Colorado. I missed the deadline to propose a talk but there are at least 5 agile presentation happening over the course of the event. That is really good news. The PMI crowd is interested and trying to understand what this agile stuff is all about.
This week, I am working the VersionOne booth, so while I have a full conference pass, I will probably not going to make any of the talks… bummer.
Talking to Project Managers
It has been really fun talking to all the folks that have come by to see our software. The people that stop to talk to us have already been exposed to agile on some level, so my perspective might be biased, but there are many more agile friendly people that I expected. Again… people are interested and want to know more.
After my first full day of meeting and greeting the conference attendees, there is one thing I would like to share with the agile community. When you talk to a traditional PM about agile project management, you need to be prepared to speak their language. While teamwork and collaboration are important, that is not the language of the PMI crowd. Empowerment is essential but can be very threatening to someone that is accustomed to being "in control".
I've found that a good place to start is with a discussion of the triple constraints.
Bookmark/Search this post with:
These days, many large scattered development teams work in medium to very large projects all over the world. This is what's going on for most open source project teams and with companies with geographically distributed teams.
This is the world wide collaboration development era. There's the need for a suitable collaboration software that provides the tools, ease of use and scalability that those teams demand.
At my university, we used GForge open source version ( http://gforge.org ), so I looked at GForge AS from GForge Group ( http://gforgegroup.com ) when I joined my current company in Argentina. They have the older open source version and two newer versions, the free Express Edition and the full Advanced Server. This is an enterprise-grade collaborative development management software, brought by the same people that created SourceForge and GForge open source.
Bookmark/Search this post with:
When agile software development is tried in a large corporate environment, it often happens that the agile pilot team or even teams have to cooperate with the old good waterfall team around the corner. It sounds reasonable that the new things (like the agile process) is tried first on the project of not too big importance, that are supposed to add value to the more important activities. For example, an agile team might be asked to develop a web-interface to the client-server system being developed by a waterfall team.
I don't have an experience with a really hard dependency, but I've been in a situation when our dependency on a waterfall team was rather weak. What happened is that the waterfall team tried
Bookmark/Search this post with: