agile2011 - export agile principles - agile alliance · export agile principles adoption of agile...

3
Export Agile Principles Adoption of agile software development methods has failed in many companies. These are some of the common reasons for failure: Product owner is not available or too many product owners who disagree Lack of support from management Environment Teams lack authority and decision making Learning culture Commitment & Motivation Go back to old ways of working But if we look closely, the items above are not actually the reasons for the failure. The items represent what happened or the behavior of people but the reason for failure lies somewhere deeper. All of these items have a connection to people and groups who are somehow outside of the actual software development team. Product owner can be a customer representative, someone who is in charge of the products or a project manager. Managers and executives are the ones that can have substantial influence the environment and culture of the company. They can choose to give or not to give power, authority and responsibility to the teams. They can create, or not create, an environment where teams can self-manage themselves. Managers and executives can drive a change in the company and motivate the employees and manage the interaction between various groups and departments. If there were not enough people in the company that adopted agile, it is easy to slip back to old habit and old ways of working. So the actual reason for the failure to adopt agile software development methods can be that the adoption was not company wide. Individuals could have adopted agile. Software development teams could have adopted agile. But it was not the entire organization. And the partial adoption did not last or it did not benefit the entire organization. People and individuals started to demonstrate the behavior that proves that agile was not successfully adopted. Systems thinking encourages us to think about the entire system, not just individual parts of the system. If agile principles only improve practices and the ways of working in the software development teams, but everything else in the company stays the same, than the benefits are not company wide. And because of this the agile methods and adoption can be seen as failure. In order to ensure that we give the agile software development adoption the best possible environment, we must make sure that the adoption is company wide initiative. We must export or “sell” agile outside of software development realm. Then everyone can have the necessary information which can help in building trust, to have good discussions and debates and commit to the principles and practices (5 Dysfunctions of a team). The more successful the initial “sell” is, the less “reselling” is needed in the future. Development teams do not need to be continuously demanding the freedom and environment they need. “Proof is in the pudding” approach has been a common way in agile adoption. What this approach means is that software development teams have started using agile method and they expect that the results will prove to others that the agile is the way to go. This

Upload: nguyennhu

Post on 09-Nov-2018

219 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Agile2011 - Export agile principles - Agile Alliance · Export Agile Principles Adoption of agile software development methods has failed in many companies. These are some of the

Export Agile PrinciplesAdoption of agile software development methods has failed in many companies. These are some of the common reasons for failure:• Product owner is not available or too many product owners who disagree• Lack of support from management• Environment

• Teams lack authority and decision making• Learning culture

• Commitment & Motivation• Go back to old ways of working

But if we look closely, the items above are not actually the reasons for the failure. The items represent what happened or the behavior of people but the reason for failure lies somewhere deeper. All of these items have a connection to people and groups who are somehow outside of the actual software development team. Product owner can be a customer representative, someone who is in charge of the products or a project manager. Managers and executives are the ones that can have substantial influence the environment and culture of the company. They can choose to give or not to give power, authority and responsibility to the teams. They can create, or not create, an environment where teams can self-manage themselves. Managers and executives can drive a change in the company and motivate the employees and manage the interaction between various groups and departments. If there were not enough people in the company that adopted agile, it is easy to slip back to old habit and old ways of working.

So the actual reason for the failure to adopt agile software development methods can be that the adoption was not company wide. Individuals could have adopted agile. Software development teams could have adopted agile. But it was not the entire organization. And the partial adoption did not last or it did not benefit the entire organization. People and individuals started to demonstrate the behavior that proves that agile was not successfully adopted.

Systems thinking encourages us to think about the entire system, not just individual parts of the system. If agile principles only improve practices and the ways of working in the software development teams, but everything else in the company stays the same, than the benefits are not company wide. And because of this the agile methods and adoption can be seen as failure.

In order to ensure that we give the agile software development adoption the best possible environment, we must make sure that the adoption is company wide initiative. We must export or “sell” agile outside of software development realm. Then everyone can have the necessary information which can help in building trust, to have good discussions and debates and commit to the principles and practices (5 Dysfunctions of a team). The more successful the initial “sell” is, the less “reselling” is needed in the future. Development teams do not need to be continuously demanding the freedom and environment they need.

“Proof is in the pudding” approach has been a common way in agile adoption. What this approach means is that software development teams have started using agile method and they expect that the results will prove to others that the agile is the way to go. This

Page 2: Agile2011 - Export agile principles - Agile Alliance · Export Agile Principles Adoption of agile software development methods has failed in many companies. These are some of the

approach can show to managers (or anyone else outside of the development team) that the methods and practices work, but it does not help others to adopt agile. The Shu-Ha-Ri model describes well the different levels in learning. First level (Shu) is just doing and the “Proof is in the pudding” approach leaves others to this level. They do not advance to the following levels which are understanding (Ha) and owning (Ri). If people would get to the higher levels, they would be

So how should be export agile outside of the software development realm? We must start exporting the agile principles. The agile practices e.g. pair programming or sprint planning are meant for software development and it is difficult for people outside of software development realm. But agile principles that the practices are based on are not meant only for software development realm, but they can be used anywhere. The agile principles can be seen as a paradigm or a point of view about work, value and people.

So what are these agile principles?

• Continuous improvement• Iterations and increments• Focus on people• Self-management• Changes• Limit work in progress• Focus on getting value and removing waste• Planning• Pull• Release often• Perfection is the enemy of good enough• Sustainable pace• Decide as late as possible• Close to the customer• Communication• Perishable knowledge work

And to what departments we should export these principles to?• Sales• Marketing and PR• HR• Management and Executives• Finance• Product• Process• Customer service• R&D

The exporting does not need to limit only to other departments in software companies. The principles can be exported to other industries than IT.

If people outside of software development understand and adopt these principles, it can have several benefits. First of all it helps in the adoption of agile software development methods. Development teams can get the necessary help and support and the environment, when people and groups around them understand how they work, why do they work in this way and what kind of help and support they need. Secondly people

Page 3: Agile2011 - Export agile principles - Agile Alliance · Export Agile Principles Adoption of agile software development methods has failed in many companies. These are some of the

outside of software development can find ways to improve their own work by applying the principles. They can innovate good practices that are based on these principles and the practices and help them in being more effective, faster, produce better quality and find satisfaction in their work.

We should not only coach the development teams, but also other people and groups in the company. First impression is critical. People should not get the image in their head that agile is something only for software development. The first impression should be that it is for everyone. We can have brainstorming sessions to find out ideas how the agile principles could be used in their own realm and environment. Retrospective is a easy principle to introduce first.

Agile and specifically agile principles can become a part of the company culture and not just “the thing” the developers do. From systems thinking perspective the agile principles can transform the entire company so that the company can benefit and improve. The introduction to agile principles can lead to deeper investigation and open new areas of investigation and improvement (Gateway effect).