What do I mean by low tech tools? Low tech tools are tools that do not require the team to sit in front of the computer to use; simple things like big visible charts or information radiator and index cards. Why is this so important? Because the team already spends a large amount of time sitting in front of the computer developing and testing the software, why make them spend all their remaining time updating and managing user stories, burn down charts, and tasks chained to the that same machine.

Low tech tools have a way of connecting people with the ideas and concepts in a much more clear, tangible, and meaningful way. For example, a team can sit down and write all the user stories on index cards then with some large wall space tape the index cards to the wall to create a product backlog. From that the team can do sprint planning by simply moving cards from the backlog section of the wall to the next planned sprint; all with no dual core’s required!

In a large organization or working with some remote team members the low tech way can be difficult and the organization may require that the planning be documented in a more formal project management or tacking tool. To address this have the PM on the team be responsible for keeping the low tech tools in sync with the high tech tools. They are the ones that need to communicate the status of the project to many different types of stakeholders so it makes the most sense for them to manage the communication; and leave the team to focusing on the code…

1. Meetings should never be scheduled; you should strive to create an environment where meetings just happen. How do you do this? Create open development environments where there are no offices or cubicles just groups of desks with lots of couches and whiteboards. In this environments meetings become organic and happen only when people need to talk.
2. You should never have meetings to communicate status; that is why you use wiki’s and bug tracking tools. People who want status should just pull the status from those tools. It does not matter if you are standing up while you are giving status in a meeting or you call it agile. Status or issues should be an asynchronous activity where the people who need to know should be pulling those from the team, not slowing them down with a synchronous meeting. If there is an issue that needs to be escalated or help resolving then the team needs to get their butts out of their seats and pull everyone together, you should not spend time in Outlook trying to schedule a meeting!
3. You should only have meetings for productive things like brainstorming new ideas, doing use cases, group design, discussing code, or getting the team together for drinking beer.

The first article is just a quick intro into this cool and powerful language, I will be sharing more soon..

http://carlosgabaldon.com/erlang/hello-erlang/

..we can get a portrait of the “normal” world. It’s populated by people who talk a lot with one another as they work slowly but harmoniously on conservative, expensive projects whose destinations are decided in advance, and who carefully adjust their manner to reflect their position in the hierarchy.

http://www.paulgraham.com/kate.html

http://belitsky.info/freelance/carlos-gabaldon/

The interview series provides insight and commentary from notable Sinatra developers, with the goal of facilitating and providing answers to the questions Ruby beginners face on how to learn and master Sinatra.

Satish Talim is a programmer, author, trainer, and speaker. A recognized expert in the field of software development with over 30+ years of I.T. experience, Satish has consulted and trained teams at various companies in India and the US.

http://rubylearning.com/blog/2009/07/21/carlos-gabaldon-how-do-i-learn-and-master-sinatra/

Sinatra-rake-tasks

In my last article I wrote about the cool Ruby DSL web framework called Sinatra which is taking the Ruby world by storm. I decided that another “How to” article on some of Sintra’s other kick ass features was just what Frank would expect.
..

Read More..