Showing posts with label Team Building. Show all posts
Showing posts with label Team Building. Show all posts

Wednesday, November 19, 2014

Agile SWAT Teams

Create a high performance elite project team is must have for every program or organization.

SWAT teams are the most specialized and experienced team that you can build to be used in extremely complex projects and emergency situations.

SWAT teams are the silver bullet, but beware though that there is only one bullet so better we learn how to do it.

Wednesday, November 12, 2014

Agile War Rooms

War rooms are a very old agile concept and the first big investment on the project success. If your team members consider that the project doesn't not need a war room, project goals are not so challenging, project is not so important or they are not interested on it.
"I'm beginning to think that a project not worth a war room may be a project not worth doing."

We may think that this old concept could be related to the old school management theory, but if you take a min to review it deeply, it's the most agile concept ever.

So, in this post you will find why and how to create a great agile war room from the ground up.

Wednesday, October 29, 2014

Plan your bench

Project bench
We all know that bench costs money, but it doesn't mean you should not have bench, it means you need to manage it wisely.

Every project manager would do anything to get an extra week when the project is in trouble but time is a variable you may not be able to adjust.

Monday, September 8, 2014

Distributed Teams?

Distributed Teams vs Collocation
Building the team is one of the most important factors that will determine the project success. This post is not about how to use the last and coolest technology to work in a distributed team, but to show that although staffing a remote team could be a valid alternative, it hurts the team and we need to learn how to manage it.

Note: there is no need to explain why, just google "team collocation".

Staffing people in remote locations is like going into debt. Yes, I'm using the famous technical debt concept developed by Ward Cunningham. OOPSLA 1992
As a PM you can decide to hire a remote developer and take on that debt, but you also need to think that every day that developer is assigned to your project, you will keep on accruing interests and it will be harder to replace that person/team and recover from it.