Nine years ago I began to manage software development processes, using various methodologies orthodox helped me achieve the goals of my projects.
The acquired experience as I realized something was missing. He felt that achieving the goals with a highly personal effort, but my team did irregularly.
After dozens of projects I started looking for the real reason for success. I realized that this is the nature of the people who work in it, coupled with adequate technical knowledge. For this reason, always consider my team as the "great actor" of a project and always try to build the most appropriate context to get the most out of them, including personal motivation.
I also learned that if you make a successful project must be willing to give way to those who are with you at work everyday. Regardless of hierarchical level, everyone wants to be recognized, everyone wants to propose, everyone wants to contribute to the goal. Here's the hard part, trying to meet these needs. Always try to do it, convinced that it was essential to achieve the goal.
A couple of years ago, I discovered that many of these premises, in which I intuitively based, were embodied in something called SCRUM. I began to read hard, and gradually I realized I had found what it has long sought. A framework that sets down common sense, based on the value they bring people, the link, creativity, constructive criticism, self-teaching and self-organization.
Does anyone think it is a good project manager to make schedules, calculate budgets, enforce orders? If you are or have been playing this role, probably think that nothing of this was fundamental to the success of a project. In my opinion, is a good project manager who manages a project carried out feeling really had control of the project was the manager, but he knows perfectly well that without the team, only with their individual contributions could not get the goal.
From the above analysis the type of leader who proposes SCRUM, the leader who articulates, orchestra, commands, but practically does not appear on the scene. Achieving the professional commitment of its staff embodied in tangible products that add value to the customer. All this, combined with short development cycles, allow correct based on empiricism and always at risk of low cost.
Many times, when talking about agile methodologies such as SCRUM, the project manager think of anarchy and low intensity, when in fact the exact opposite. To practice properly SCRUM required discipline and intensity, sustained over time.
I could have written an article explaining boringly SCRUM, but would go against the essence of this method, for that reason, I invite you to learn SCRUM. Then there will be time to decide whether or not practice it, but not removed from their settings due to ignorance. Think, for something is being used by large technology companies in the world, Google, Yahoo, Microsoft, HP, Novell, SAP, Nokia, Xerox, etc..
Project management is completely overrated. the proof is in continually tends to any technical work mythologized administrative tasks. not believe in any methodology that does not take its parameters to the team, the talent. My experience makes clear that success is in the equipment.
The torvalds when asked how he manages to handle linux Projected always says that the secret is not to get in the way of people who know. He even wrote a manual on project management style, with his characteristic humor.
http://tinyurl.com/2937hwr
/ * Since we always try to cover with written rules lack common sense * /