“Let’s take an agile approach to this project”
Agile has been a buzz word in project management for years. Often misunderstood with simply taking a flexible approach to planning, the term has lost some of its meaning.
Webinar: Configuring SharePoint for Agile Project Management
The term Agile is confused by people defining what is or isn’t Agile. These definitions often focus on a specific tool or common element associated with Agile, which can distort our understanding of the original goals.
Let’s take a step back and explore Agile’s basics.
What is Agile?
Although we see Agile across a variety of industries, it was first and foremost a re-imagining of how software was developed.
During the late 1990s, PC computing became prominent within enterprise. With technological advances came an increased demand for advanced business software solutions.
This meant that the average time to develop and ship business solutions was reduced significantly to about 3 years. However, the rapid evolution of technology and business needs presented a challenge. Developers encountered ‘application delivery lag’ as within those 3 years, requirements systems and sometimes entire businesses were likely to change.
This lead to many projects being abandoned and cancelled halfway through production. It also resulted in stakeholders being disappointed with the final product because their business needs have changed, even if the project delivered its original objectives.
Fidelity to early decisions in a project became a source of major frustration and a blocker for project success.
This prompted a move away from more traditional methodologies such as ‘Waterfall’ where project tasks could not be started until its predecessor was complete.
Progression of Agile
Since its early days at the turn of the millennium, we have witnessed an evolution of Agile. Its philosophies have grown outside of software development and into construction, marketing, and education among other practices, but its principles still ring true.
The beauty (and some would say the shortcomings) of Agile is that its values are broad enough to be interpreted in many different ways.
There are many different methodologies that can be considered Agile, the two most popular being Scrum and Kanban project management. They all follow the same process.
- Teams should understand the end goal
- Teams understand the value to the organization/client.
- Teams know how it will be achieved.
- Project scope can be included but is not rigidly adhered to as change and adaptation are at the heart of Agile.
By interpreting these values for your team process, you can easily enhance your productivity and deliver outstanding, valuable work for your stakeholders.
Agile Manifesto
“In our organization, we strictly adhere to the Agile framework.”
The above statement might not sound ridiculous to some but it doesn’t make any sense.
Agile is not:
- A methodology
- A specific method of delivery
- A framework or process
Agile is a set of values and principles that are clearly laid out in the Agile Manifesto, a document borne out of frustration among software developers in the mid-1990s. The manifesto was drawn up by 17 people who took to the Wasatch Mountains in Snowbird, Utah to discuss the future of software development.
Together they acknowledged that companies were so focused on planning and documentation that the main goal of pleasing their customers was lost.
The manifesto sought to find the common ground between multiple methodologies and at the end boiled down to 68 words.
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.
Twelve principles underlie the Agile Manifesto, including:
- Customer satisfaction by rapid delivery of useful software
- Welcome changing requirements, even late in development
- Working software is delivered frequently (weeks rather than months)
- Working software is the principal measure of progress
- Sustainable development, able to maintain a constant pace
- Close, daily co-operation between business people and developers
- Face-to-face conversation is the best form of communication (co-location)
- Projects are built around motivated individuals, who should be trusted
- Continuous attention to technical excellence and good design
- Simplicity
- Self-organizing teams
- Regular adaptation to changing circumstances
Agile breaks down your product into smaller, more manageable builds referred to as iterations or sprints and must include regular feedback from your stakeholders.
Agile does not make decisions for you but instead gives you the foundation to make better decisions by valuing the above items on the left instead of those on the right.
An example of the team making Agile decisions would be a software developer agreeing to build something for a customer. The Waterfall approach might be that all requirements need to be documented and signed off on before the work is completed. The developer takes the requirements and provides the customer with a final product after a long, single, production cycle.
The Agile response would be to ask “Should we not value customer collaboration over contract negotiation? Should the developers not be regularly in contact with the customer?”
Instead of signing off on all requirements, the developer collaborates with the customer and agree on short builds to ensure that the customer and developer are happy all the way through the process.
Agile Project Management Resources
Configuring SharePoint for Agile Project Management [Webinar Recording]
5 Stages of the Agile System Development Life Cycle
