Agile practices have gained tremendous popularity in the past two decades. The various derived methodologies and frameworks such as Kanban or Scrum have been successfully used in numerous projects in and even outside of the software development industry.
However, as it often happens, the popularity of a tool doesn’t always go hand-in-hand with its proper usage. In fact, agile project management isn’t an exception in this respect.
I’d like to point out and talk over some of the most common mistakes pertaining to this issue. My article would examine the principles of the agile project, and what your team must establish in the structure of their organization. Our stories will examine cross functional issues, the importance of documentation, and how to avoid failure in a scrum environment.
Daily agile teams and 'status reports'
Daily team stand-ups are a good place to sow the seeds of change, as they can become the first source of agile mistakes. These are often called 'dailies', 'stand-ups', 'morning roll calls' or 'daily scrum' when used within that framework, and are used most often out of the whole agile tool-box. Quite true to their names, one can say, but this means that they can cause a project manager to commit a common mistake, as they under-deliver, or become 'misused and abused' most often too!
It doesn't take a company scrum master to know this! In its defined purpose such a meeting is a communication opportunity for the team, where we feature problems that be identified before they become too disruptive to the business.
Give purpose to your meeting
Being a short, timeboxed event it also promotes follow-up conversations. Unfortunately, quite often daily stand-ups become a mere 'sort-of' status report or update to the project's management, where team members simply 'confess' to what they’ve been working on so far. This causes daily meetings to lose their value and revert to time-wasters, where working hours burn into oblivion, far from benefiting the work at-hand.
An effective agile project requires teams to follow through on their activities, and provide insights into next steps.
You didn’t plan this during the sprint planning
Perhaps the most impactful issues stem from incorrectly prepared product backlog items. PBI’s that aren’t broken down correctly into smaller parts make it much harder for management and developers to accurately estimate time needed to implement them. Organizations of all shapes and forms face this issue.
As such, underestimated items are pulled into a sprint backlog during agile planning and worked on accordingly. But then, the inevitable happens, they don't become completed the iteration's end, being pushed to the next one instead. When this occurs, time and again, it essentially invalidates the purpose of setting a goal, since it’s rarely achieved.
Make the process digestible
Items which are properly broken down to their smallest parts (which should still provide sensible customer value) are much easier to be evaluated correctly by the development team. This greatly improves planning accuracy and chances for achieving the set goal.
“Earth to management, I can’t hear you!”
Communication is the key to success, and together with openness is one of the pillars of the agile software development process. But what happens when a team member fails to communicate effectively? This has been partially talked over when teams discuss daily stand-ups but there are also other instances when lack of information flow may prove disruptive.
For example, a certain functionality to be implemented in a current iteration might be worked on across several traditional environments: iOS, Android and Web. Whenever we encounter any platform-independent problems, developers might tend to solve them on their own, within their own code-base, neglecting to inform a product owner or project managers of their discovery and/or solution.
Avoid repeat errors with transparency
This usually results in the same work (solving the problem) being unnecessarily duplicated whenever another team member attempts to tackle yet-another traditional obstacle. Again, organizational hours are unnecessarily wasted, endangering the goal.
“Let me dump this project on you...”
What Quality Assurance professional doesn’t love verifying developers' work? But even though testers command legendary powers, even their best performed work is time constrained in an agile project.
Work assigned for a sprint should be correctly estimated not only for coding but also for testing. It’s not really an agile practice when developers keep their finished work in code repositories and only release test builds of software late in the game.
Consider a gradual release
Such conduct doesn’t leave much margin for QA and any bug-fixing resulting from tester scrutiny might not be finished when the bell rings. Releasing testable builds gradually throughout the project, as the specific items are being completed, will usually end up in a more efficient team work translating to a better increment.
Agile retrospectives in perspective
Held at the end of project management tasks, retrospectives are intended to help to identify and complete the development process for future interactions. It is supposed to be achieved by reflecting on projects with the scrum master, product owner and others within the organization.
Project management teams must consider the features of their agile processes. This means determining which feature was successful during the analysed time period, and which features could be improved.
Iterating and Improving Agile Teams
The most responsive agile teams are in a constant state of training, where teams evaluate a traditional process or methodology, and determine its need for increased agility, or even complete change.
However, failing to act upon the gathered suggestion and feedback (and it does happen, for whatever reason) turns such a meeting into a missed opportunity, leading to team members losing faith in its progress and questioning the notion of agile project necessity.
Any improvements derived from retrospectives have the potential to greatly influence a project's success, so organizations and team members should always strive to deliver them in future iterations of their agile projects.
Terminology won't guarantee agile projects
So, at the end of the day, your agile software project work divides into sprints with their goals. Meanwhile, the agile team holds planning sessions, daily stand-ups and even retrospectives and review meetings - that sounds all good! But can managers and their agile teams actually subscribe to these changes?
That's to see, but I hope it’s clear for all organizations that it’s not the terminology that matters, rather the understanding of these agile processes. Examine the business case for your agile practices, identify related benefits, understand their function and to what degree they impact the end user. Implementing these practices incorrectly won’t bring many (if any) benefits and can actually be detrimental, as evidenced by the previous examples.
Your Next Steps to Agile Success
Be sure to search for the above practices as form of training to continue implementing in your project management tasks. So, as you adopt agile, keep to this advice and methodology to adopt stronger agile project management skills, bring focus, and develop value to your customers and stakeholders.
With that said, an agile project requires commitment and team dynamic, but there's a world of information out there. Feel free to read our other articles for more information!
