- July 13, 2008
- Posted by: admin
- Categories: Agile Applications, Agile Project Management, Blog
In this era of highest competition and with timing being the need of the game, every organization has to become more kinetic and futuristic to outperform their competitors. To achieve this they need to provide customizable services for every client and respond in zero time, this level of servicing can only be met if an organization has a strongly dependable and motivated team.
In conventional organizations the hierarchical architecture of human resources promote many negative thinking patters and a defensive rather than supportive culture between teams. At some point in our careers all of us might have experienced the rigid, defensive and non cooperative behavior from teams against each other, the main reason being the conflicts of interest.
We have experienced that conventionally whenever a project is initiated the focus and vision of the technical teams and business teams are entirely different; the business teams are focused on providing the maximum profits for the client when the technical teams want to limit the requirements as much as possible while cushioning the estimates to ease the processes. Some of the issues that arise from these strategies are as follows:
Self defense Strategy: The teams tend to get on the defensive side especially if any requirement/functionality gap is identified late in the software life cycle. The outcome of the blame game is often a shift of focus and thus deliveries and project schedule is affected.
Rigidity: Often time developers consider their code as their “brain child” and can’t take criticism against that. This attachment towards code makes them rigid towards understanding the actual requirements and accepting the flaws when the business team pressurizes the technical team to retain the client.
Not owning the project: Since conventionally the business & management teams are the ones communicating with the client and the development team just coordinates with the respective business managers, the development team does not share the vision of the business team. This demarcation prohibits the development team to understand what the solution means for the client and thus they do not feel any attachment to the project.
These scenarios create a negative competition within the organization limiting the performance and grooming of every team member and the energy is wasted in the conflict resolutions rather than improving skills and qualities. Since the developer is asked to concentrate on the technical side only neglecting the business aspects the leader within dies.
The Dynamic Commandments Of Agile ModelThe futuristic approach of Agile development model, in addition to other advantages, promotes a culture of “team work” and “positive” thinking. The theme of agile encourages technical teams to involve with the business teams at all stages and promotes communication of actual technical squad with the client rather than a business manager as an intermediary. This model solves various issues of attitude and improves the team and the team members on the whole by following some guidelines as below:
Developer on the driving seat
In any agile model the technical team is given the driving seat allowing them the space to interact with the client and the stakeholders to understand the technical as well as the business aspects and requirements of the project. This not only increases the understanding but also improves the motivation level of the team.
Own the client/project
Since the technical team is the one in charge of the project they develop a sense of ownership towards the client and the project which is a key to success in any scenario. This improves the relation between the business and technical teams too as now their focus is to service the customer better and create a success story for the organization.
Engage in the process
As the technical team is engaged with the client and business managers while planning and budgeting the project, their thinking patterns improve and their managerial and leadership skills are polished.
Auto training for leadership/management skillsSuch interaction of the technical team and the responsible roles provides an automatic training of the resource grooming their interpersonal and business skills and that in turn is beneficial for the organization on the whole.
Efforts’ worth
The direct appreciations from the client and the demonstration of actual benefits that the product/solution is bringing to the client ,gives the development team a sense of accomplishment and they can see what worth their efforts were.
Self-Adaptive & Organized
Agile models force the teams to be adaptive in order to change the course of their process and activities according to the scenario and requirements. The self organization and adaptive behavior makes team members more responsible in their roles and crafts a good leader out of them.
Are You An Agile Evangelist?
Every organization that wants to be on the Agile platform must create dynamic channels to enable that all the teams are wired and up-to-date on all information. In order to improve your teams, promote a culture of skill development where your team reinvents themselves, are capable of handling unexpected and are given freedom of taking decision and initiatives. Being an Agile evangelist you have to encourage your teams to interact and coordinate with partners, customers and other teams.
For more details on how are such teams are built and managed please read the whitepaper “Building And Managing Self-Adopting Teams”
We being the followers of Agile beliefs have invested our energy in building teams on the agile manifesto and have experienced some leaders and managers out of our technical teams who have managed the projects, retained a happy client and have save the cost of tiresome HR processes to find good managers and leads.
We are still implementing the manifesto to further explore the opportunities it brings to a company, share your experiences and best practices with us to endorse a better team work culture.
I can not download the pdf document. it always blocks.
As I write alos about Agile team compensation, agile team forming and deliver leadership games, I’m very interested in the subject
All you need to do is
right click on the link
save target as
and download 🙂
In terms of motivation. Agile methods as well as Lean Agile improve motivation by:
pushing decision making from “managers” to the actual experts on the front-line, which often results in simple, elegant, and improved results. People like to feel empowered.
improves buy-in as the “workers” are part of the estimating and committment process and not just told to code X in Y hours
improves self-determination and sense of accomplishment as team members are self-directing and grab their own assignments versus being micromanaged on what to do when. Since everyone on the team knows who is doing what, team peer pressure and pride is a better motivator than a PM with some Project schedule watching over your shoulder.
Right now I am reading Lean Software Development and Implementing Lean S/W Development (both by the Poppendiecks http://www.poppendieck.com/ilsd.htm ) and I find them incredibly valuable, even more so than Agile Estimating and Planning.
In my experience Agile adoption hasn’t lead to “thinking radically” (whatever that means). It has simply lead to individuals being able to effectively contribute what they were already thinking when things were done in a waterfall manner.
For example, business analysts will frequently design requirements that engineers downstream either know are hard to implement (because they know the implications of the requirement) or are just plain incorrect for the business (perhaps because they have been with the firm much longer than the analyst). In non-agile approaches, that often leads to an attitude of “that’s their department”, or “nobody listens to me anyway”.
The “transformation” in thought process that I have seen is really a transformation in culture so that opinions and insight that people have had all along are made to matter early in the process.