“We want to be Agile…”
“We want to take an Agile approach to delivering…” It’s a phrase heard frequently from organizations as they take on complex digital transformation implementations. Agile is a popular term that gets project teams excited. There’s excitement in the promise of a speedy delivery and return on investment—one that allows flexibility in scope, requirements and discovery. Unfortunately, all too often, that excitement fades quickly and is replaced by anxiety of promises unfulfilled.
Why Agile?
According to the Agile Practice Guide, developed jointly by PMI and the Agile Alliance and published in September 2017: “More mature organizations are increasingly prone to being highly complex and potentially slow to innovate, and lag behind in delivering new solutions to their customers…speed of change will continue to drive large organizations to adopt an Agile mindset in order to stay competitive and keep their existing market share”.
When an Agile project fails to deliver on promises and benefits of the delivery framework are not realized, organization leaders can be quick to characterize Agile as a flawed idea. In many cases, after closer review, the cause of failed Agile projects is not because of the idea, but rather the execution. In fact, when Agile projects are executed with a solid understanding of Agile principles the results can be realized, as advertised.
Understanding Agile Principles
Many organizations have grown familiar with the concept of Agile projects, which is certainly a good starting point for moving in the direction of project delivery. However, in order to take the next step of realizing the promises of successful Agile endeavors, one needs to understand the principles that support this framework.
The following outlines the “12 Agile Principles”. These are commonly understood within the practicing Agile community. Organizations are well-served to ensure project teams are knowledgeable in these principles and adhere to them when determining how to tailor an Agile approach to meet their project(s) business objectives.
(Source: https://www.agilealliance.org/agile101/12-principles-behind-the-agile-manifesto/)
Top 5 Principles in Becoming Agile
Witnessing trials and triumphs of small- and large-scale Agile projects, below are five key principles that organizations should give close consideration to in order to realize the promise of successful Agile execution. Related “Do’s and Don’ts” are offered based on practical experience.
|
|
Top 5 Principles |
How To Apply |
|
1 |
Highest priority is to satisfy the customer through early delivery of value |
Do's
-
Maintain focus on customer business objectives and what products/features drive value
-
Prioritize efforts on what can bring the most value the soonest
Don'ts
-
Devote time to delivering complex project artifacts that could be better spent delivering valued functionality
-
Back-load delivery of high-value functionality for fear of complexity/risk…take them on early!
|
|
2 |
Working software is the measure of success |
Do’s
-
Measure a project’s productivity based on fully functioning products (you know it’s done, when you see it working)
-
Focus efforts on activities that demonstrate working software and/or remove roadblocks in the way of its delivery
Don’ts
-
Spend time and effort measuring partial completion (e.g., % completion of in-progress items)
-
Hold traditional status meetings. This can lead to the infamous “we’re almost complete”
|
|
3 |
Welcome changing requirements |
Do’s
-
Recognize requirements become clearer when solutions are demonstrated against use cases
-
Understand marketplace developments can be addressed by accepting new requirements
-
Keep open dialogue between business and delivery teams to trade; accepting new value-add requirements with de-prioritizing previous requirements for sake of time and cost
Don’ts
-
Reject value-added changes simply because a pre-dated milestone has passed
-
Introduce unnecessary bureaucracy as a deterrent to change
-
Accept changes without challenging value proposition (in a simple manner)
|
|
4 |
Practice the art of simplicity |
Do’s
-
Accept simple solutions that satisfy business needs
-
Place value on what has demonstrated to work well enough
-
Remember that a simple solution can be enhanced later
Don’ts
-
Delay demonstrating work functionality for the sake of perfecting it
-
Fill idle time by gold-plating work functionality. Use additional time to pull-forward efforts that have not started
|
|
5 |
Build motivated teams and trust them to get the job done |
Do’s
-
Create simple status tools (easy to interpret and update) and make them publicly visible. Allow teams to spend more time delivering than report
-
Empower project team to make delivery decisions based on a trusted understanding of business-valued objectives
-
Support a self-organized team that knows what it takes to deliver by allowing freedom to make internal decisions
Don’ts
-
Attempt to micro-manage by adding layers of reporting/approval that detract from time spent delivering
-
Pull teams from agreed upon delivery cycles to attend management/status meetings
-
Slow delivery progress due to cumbersome decision processes
|
