In the last decades, the word Agile has easily been the go-to for software development projects. The agile method for software development and delivery is particularly prevalent because it gives room for changing requirements and iterative short cycles which happens to be effective in a world of fast-paced innovation.
So what is Agile? And how can it be applied to software development projects for higher chances of success?
Agile refers to the framework and values which can be represented in the agile manifesto, however, scrum, kanban, extreme programming are derivatives of this framework. (More on these on another post.)
Now we know what the agile principles are.
For a more straight forward approach to understanding what the Agile Project Management Method could look like, I have made a list of the 12 agile principles and how I have applied them on my IT projects to achieve project success.
Intelligence is the ability to adapt to change.Stephen Hawking
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
I conduct a sprint review where the development team shows a demo of new features to the key project stakeholders. Sprint reviews typically happen at the end of each iteration which is 2 weeks.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. –
During the sprint review, the development team takes feedback from the product owner/customer and prioritize them for future sprints. This feedback could be in form of change to the requirements or additional features.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
My projects are usually delivered in 2 weeks sprints at the end of each we present a demo or working software to the customer for feedback.
4. Business people and developers must work together daily throughout the project.
I facilitate daily scrum calls for 15 to 30 mins daily to get reports on completed, in progress, and scheduled tasks. I also take note of impediments so I can address them after the call. Everyone on the delivery team is required to be on the call.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
I also make it point to motivate my team during weekly internal status calls by reminding them of the client’s vision and the big picture. I trust them to deliver on their task and enable them by removing any blockers to their success.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
I encourage teleconferencing calls for each team member does a video share. I have used Zoom, Webex, and Skype. All 3 platforms have excellent communication and collaboration functions
7. Working software is the primary measure of progress.
I make sure to measure progress by the working features that have been implemented and this is reflected in the teams’ Burndown chart.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
2-week sprints ensure that the team is maintaining a constant pace. Also, with a definite pace, stakeholders also know when they will be receiving a demo of the work done so far. This allows the development team to receive feedback frequently instead of backtracking several weeks on mistakes.
9. Continuous attention to technical excellence and good design enhances agility.
I know the importance of having a solution architect in software development projects. There should always be someone on the project who is knowledgeable about architecture and solution design and how the new system will fit the existing enterprise environment. Failure to have this covered could result in issues during integration
10. Simplicity–the art of maximizing the amount of work not done–is essential.
Constant planning is very critical. As the PM, I always want to make sure I am paying as much attention to the product backlog (work not done) as much as the work being done.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
I allow the team to pace themselves and determine the duration for the task. It reduces pressure and increases productivity.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
I conduct sprint retrospectives at the end of each sprint to reflect on what we did we all and didn’t do well as a team with plans for improvement.