The Agile Manifesto written in 2001 in essence is a set of four values and twelve principles.
“We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
“That is, while there is value in the items on
the right, we value the items on the left more.”
The twelve principles of agile include:
- Customer satisfaction through early and continuous software delivery – Customers are happier when they receive working software at regular intervals, rather than waiting extended periods of time between releases.
- Accommodate changing requirements throughout the development process – The ability to avoid delays when a requirement or feature request changes.
- Frequent delivery of working software – Scrum accommodates this principle since the team operates in software sprints or iterations that ensure regular delivery of working software.
- Collaboration between the business stakeholders and developers throughout the project – Better decisions are made when the business and technical team are aligned.
- Support, trust, and motivate the people involved – Motivated teams are more likely to deliver their best work than unhappy teams.
- Enable face-to-face interactions – Communication is more successful when development teams are co-located.
- Working software is the primary measure of progress – Delivering functional software to the customer is the ultimate factor that measures progress.
- Agile processes to support a consistent development pace – Teams establish a repeatable and maintainable speed at which they can deliver working software, and they repeat it with each release.
- Attention to technical detail and design enhances agility – The right skills and good design ensures the team can maintain the pace, constantly improve the product, and sustain change.
- Simplicity – Develop just enough to get the job done for right now.
- Self-organizing teams encourage great architectures, requirements, and designs – Skilled and motivated team members who have decision-making power, take ownership, communicate regularly with other team members, and share ideas that deliver quality products.
- Regular reflections on how to become more effective – Self-improvement, process improvement, advancing skills, and techniques help team members work more efficiently.
Understanding the above values and principles are the key to agile transformation. They seem like plain common sense, but are they applied to projects? So how do we go about applying the values and principles.
In my experience agile transformation has to be handled very carefully and one misstep can undermine the entire process.
Transformation needs to be driven from the executive level and PMO buy-in is a must. Agile is not a buzz word to be thrown around unless the principles and values are truly active within an organization.
I have seen companies claim to be agile by using the agile phrases and terminology, with no true understanding of what is behind it. Teams reporting to management that they are running agile, and management not having the knowledge or understanding to even challenge the statement.
The concepts must be understood, accepted and embraced by all members of the organisation to be fully beneficial.
Agile bootcamps for all
Sure this is sometimes not feasible and can be costly; but for all management levels and the PMO at least; I would say this is a definite must.
Enlisting the support and resources of the change management team can assist introducing the transformation in a way which works for the organization.
Communication an interactions is a value of agile, those impacted by the change need to understand why are we doing this.
Select a small project with a willing team to be your showcase. Invite other teams to view progress and ceremonies. Advertise, share and share some more. Share team feedback with the organization.
I have seen in large organizations when doing this, the curiosity of the other teams and the willingnes to get onbaord with this new process is a lot more positive.
People naturally dont like change and upheaval, the IBM developer who has been coding in the back corner from a 50 page spec; without so much as talking to anyone for the past 10 years now has to attend a 15 minute stand-up each day and report on his work. Or worse attend a review ceremony and show case his work. This is not an easy adaption for him. Do not throw him in at the deep end.
Do not try save a project in trouble by switching to agile. This could prove disastrous to the agile transformation.