Importance of instant messengers (IM) for Agile teams

We need to have good, clear and continuous communication to be able to effectively collaborate with our team in any engagement. The selection of method and tools for enabling the smooth communication depends on the type of information, intended recipient, and project needs. In Agile teams, the importance of tools which enable to communicate is no less than any other teams.

 

Agile teams should be collocated, however if they are not Instant messengers (IM) enable Agile teams to communicate with each other instantaneously in groups and one-to-one communication. IMs are the most popular tools for Agile teams who wish to stay in touch and share stuff.

 

I use Yahoo and Google messengers. Yahoo is particularly beneficial to share files, etc because it uses LAN to transfer files which makes it faster and more effective. GTalk is better for light and speedy talks. You should choose the IM as per your needs and team’s comfort. Most messengers comes with features to save the conversation, this enables to track what was decided and when. Voice chat feature is useful if teams are split across the globe or they do not have a phone on their desk.

 

At the end, I would say that IMs are more effective for small/quick chats. Longer/complex conversation should be done in person or using video conferencing or over the phone (in that order).

 

 

 

 

Has Agile failed? I guess not

Today, I read an article “James Shore: The Decline and Fall of Agile” posted by Chris Sims at http://www.infoq.com/news/2008/11/decline-of-agile.

 

I really liked this part “James thinks it's not all the fault of Scrum, however, as each team must take responsible for its own success or failure. Many are choosing to adopt only the superficial, and easy, parts of Scrum such as short development sprints and daily stand-up meetings, while ignoring harder, yet critical practices such as reflecting and improving. Via this process, teams are empowered to identify and adopt the engineering practices that they need to deliver shippable software every iteration. Unfortunately, many teams fail to take this step.”.

 

I absolutely agree that team must take responsibility of their actions and results. To take this inference further, good team members (self-organizing types) will produce good results wherever they work. We can only create agile teams to the extent of resource allocation, their passion is their own and it cannot be forced to act in a specific way. Taking the Agile route we can enable those who want to (and can) perform.

 

It is not the decline and fall of Agile, but of those who are unable to understand the methodology. Those people practice what they believe to be Agile and when they fail, they blame Agile for it.

 

I have failed with Agile several times, however I learned something new every time. The only learning I pass on is that “you cannot go by the book”, that’s what Agile is all about. Also, Agile has to be XP and Scrum together, one without other leads to failures.

 

Agile is not one size fits all. I am of the opinion that Agile have a lot of good practices which have to be practiced and improved with experience. Methodologies have evolved over decades, the good things don’t vanish, they just change names and evolve for betterment.

Is Agile for real?

This weekend (Saturday, 15^th Nov, 08) I attended Agile Expert Series at Impetus Noida facility. The event was organized by Xebia. Sanjiv Augustine, President LitheSpeed, world renowned & leading agile thought leader was the speaker on the topic Agile Project Management Overview. Luckily for me, I got seating in the front row and was only project manager for the first 30 minutes of the 1hr presentation; this gave me an opportunity to interact with Sanjiv on issues/questions.

During this interaction Sanjiv over-emphasized (or maybe I paid much attention) to the aspect of self organizing teams. He gave an example of developer becoming a designer. In this example, after becoming designer the team member felt superior than others which reduces the communication/interaction within team. My question is, how would this be any different in Agile team (I mean the designer has an attitude problem, not the development/project management methodology problem).

After the presentation, I was thinking about the critical success factors (as per my understanding) of Agile:

<![if !supportLists]>·         <![endif]>Self-organizing teams who abide by their commitments (to customers)

<![if !supportLists]>·         <![endif]>Customer having enough time to spend with the team

The question is: If we live in a perfect world, who needs Agile (Scrum to be specific)?

On Sunday, I spent most of my time looking for more instances of success of Agile with normal teams (not the ones who are self-organizing) and/or normal customer (the one who is available during kick-off, requirements and UAT phase of the project, and maybe on notice of 3-5 days too). Well, disappointed at the results, I went back to my book shelf to look for “Managing Agile Projects”, the most wonderful book on agile project management to look for answers. Well, I am not yet done with re-reading this book. Will post once I find something really interesting. If you wish to read the book buy Managing Agile Projects from Amazon.com

ArgoUML 0.24 released in Oct 2008

For those who don’t know, ArgoUML is a Java based CASE tool. And open source too J

 

 

Feature list

·         Platform Independent: Java 1.4

·         Standard UML 1.3 Meta-Model

·         8 out of 9 Diagrams supported

·         XMI-Support

·         Export Diagrams as GIF, PS, EPS, PGML and SVG

·         Internationalization EN, DE, ES, RU, FR, NB

·         Advanced diagram editing and Zoom

·         OCL Support

·         Forward Engineering

·         Reverse Engineering / Jar/class file Import

·         Cognitive Support

·         Reflection-in-action

·         Design Critics

·         Corrective Automations (partially implemented)

·         "To Do" List

·         User model (partially implemented)

·         Opportunistic Design

·         "To Do" List

·         Checklists

·         Comprehension and Problem Solving

·         Explorer Perspectives

·         Multiple, Overlapping Views

·         Alternative Design Representations: Graphs, Text, or Table, media size, resolution, and so forth.

 

 

Download: http://argouml.tigris.org/

Thinking of writing a book on Scrum

I had a very good time writing my first ever book on any subject. I have been writing sine my collage days but never used Scrum at that time. I enjoyed using Agile principles while writing the book. I am highly inspired by the results and am thinking about writing a “Summarized” series book on Scrum too.

Wish me luck :)