By Mohamed Khalifa
Project Management Consultant, Coach & PMI Authorized Instructor
PfMP, PgMP, PMP, PMI-RMP, PMI-SP, PMI-PBA, PMI-ACP, OPM3, CDA
Project+, HRBP, CKM, CBAP, LIMC, CCMAP, CTT+, IPMO-Expert

Since seventeen people met in February 2001 at Wasatch mountains of Utah to discuss and draft the Agile Manifesto, software projects have been the main focus of Agile. Since this time, Agile became one of the hottest topics in the project management world, mainly due to its proven success on software projects and its ability to deliver quick and real value to customers, reduce the risks and increase collaboration between different stakeholders.

After years of using agile methodologies, tools and techniques many professionals around the world started looking at the Agile Manifesto through lenses other than software development. They proclaimed to very clearly see that the Agile Manifesto, principles, tools and techniques can make the same level of success on different types of projects in addition to software development.

In the current turbulent and fast changing world, we need to go back to the basics, back to the reason which made agile successful which is “be Agile, be Adaptive”. If we start referring to the main Agile Manifesto and do small changes in the statements, we will find that they will work fine with projects of different types.

Let us have a look at the Agile Manifesto which requires preference of:

• Individuals and interactions over processes and tools,
• Business value over comprehensive documentation,
• Customer collaboration over contract negotiation, and
• Responding to change over following a plan

The above can work in any project and can be adopted as an organization’s philosophy to deliver fast, reduce the risks, solve the conflict between different stakeholders and clarify the requirements as we work on projects.

To successfully execute non-software projects using Agile, we can use the Agile principles to set clear expectations with stakeholders, bring sanity to project execution, and mine the benefits of Agile.

While this approach may look similar to the principles followed in an Agile software delivery project, their applications are quite different when it comes to non-software projects.

• Define “Working Product or Service” can be used to refer to any deliverable that is produced by the project and brings value to the customer.
• Define “Customer” can help us to define who is the ‘right’ Product Owner.
• Define ‘Done’: Work with the sponsors and product owner to identify ‘done’ for each story/deliverable.
• Measure Business Value: Measuring or establishing the business value of the work done is key for any project.

Since most of the deliverables exist as theories or prototypes, it is important to prepare a business case at the start of the initiative that clearly provides the cost benefit for this initiative followed by articulating the benefits achieved at regular intervals, preferably at the ends of iterations.

Expect the Unexpected: Project scope, objective, and goals are liable to change frequently and drastically. Therefore, go for shorter iterations, joint workshops, paired development of deliverables, continuous expert and peer reviews, and proper socialization of theories and ideas. Having senior strategists, architects, or consultants is helpful, especially if they have a deep experience on the subject matter as well as with the overall organization.

Did you try to apply Agile Mindset in your projects? Is it working? What was good? What was bad? Share with us your valuable thoughts.

Explore IIL’s Agile and Scrum Courses here or contact us at learning@iil.com or (212) 758-0177.