Agile project management is a growing trend across the globe and enterprises are taking immense benefits by going the Agile way. Today, the successful completion of projects is what differentiates you from your competition. If you are more successful with the adoption of Agile project management, then you will bag more business-critical projects and deliver them as per organizational business strategies.
We all know how Agile is beneficial and we have read so many articles on Agile adoption and its misconceptions, but never we have heard anything about the mistakes made by newly formed Agile teams. What are those mistakes? And how can they be rectified?
1. Fear of Failure:
Fear of failure or Fear in itself is a powerful emotion that prevents people from growing and it is encountered in various forms. Fear makes people make bad decisions and this can frustrate a newly formed Agile team. In the beginning, newly formed Agile teams commit because of fear of failure. As a project manager, you can instead instill trust which acts as a strong counter-acting agent in this case. The team should be trusted to learn, grow, make mistakes and rectify them as a group than just taking directives from senior management.
2. Substandard Communication Channels:
This can be one of the key reasons why mistakes happen when team members don’t communicate on a regular basis. Even when everything is being documented, the best way to find issues or roadblocks is via old-fashioned face-to-face communication. This can be negated by setting up a dedicated workspace for teams where everybody is within reach of each other. Use of the latest communication tools and video conferencing should be made available where teams are located in different parts of geography. Prominence should be given to the quality of information over the quantity of information being shared. Create stand-up meetings which are short and to the point as team members will find it uncomfortable to stand for a long period of time.
3. An Imperfect Team Structure:
Whether it is newly formed or well-established Agile teams, it has two common elements which keep them together. One, the team should be cross-functional and the other be stable. In the case of a cross-functional team, it has all the attributes to complete a project within a specific time and budget allocated. A stable team ensures the team members have enough time to know about each of the team member’s strengths and weaknesses, which in turn helps them to learn and grow together. It also ensures they will benefit by learning across various roles and can help to provide better estimates down the line when they are familiar with the skills of their team members. And once the team is mature enough, they will have well-defined velocities that help in providing better predictions to stakeholders involved in the project.
4. Providing Vague Estimations:
Project managers or scrum masters push team members to quickly give their estimations without knowing their velocity. This creates confusion as estimating the size and scope of the work for a new team can be a difficult task. Getting estimation right for a new team needs time. As a scrum master, you should let the senior management know that it needs 2-3 sprints to understand their velocity and time should be given for this new team to know how they work together. The point is estimation reflects the team’s abilities, and once they have worked on a couple of sprints and user stories are documented, individual capacity comes to the forefront in the form of hourly task estimates.
5. Poor Planning:
There is a huge misconception that there is little to no planning at all in the Agile project management approach. Compared to traditional approaches such as waterfall and others, Agile requires more planning. The major difference is that there is a critical action that is ongoing in Agile instead of a one-time event that is checked at the beginning of the project lifecycle. Newly formed Agile teams hardly spend time planning the entire event. For best results, you should spend at least 20% of your time planning in order to be successful. New team members first need to get used to daily stand-ups, sprint planning, release planning, etc. Team members should get into the rhythm of doing things on a consistent basis so that the team gets adjusted to looking at one or two sprints/iterations ahead with regard to planning.
6. Bad Testing Habits:
Often new or well-established Agile teams think Agile is all about speed. But, Agile is about delivering quality software at a faster pace than meets customers’ requirements. On many occasions, newly formed Agile teams give more prominence to building the software and less to testing the software. As a product owner, it is your responsibility to ensure the completed work has been properly tested and meets the stakeholders/teams’ acceptance criteria. A simple way to combat this issue is to stress developing automation testing. Teams should test every single build until it passes all the tests. Because team members would have worked on other traditional approaches where testing is done at the end of complete coding, they need to change it in the Agile way. Because in Agile there are cross-functional teams, testing can begin immediately after each sprint which helps in the removal of potential bottlenecks at later stages.
7. Not Incorporating Customer Feedback:
Customers are one of your most important stakeholders. Incorporating customer feedback helps you to craft the features and functionality of the product. On most occasions, newly formed teams will not review the feedback given by the customer and fail to accommodate in their planning. When the product is getting built, the team has to check this feedback at various iterations to make sure you are still building something that is meeting customer needs in the first place.
8. Poor Involvement of Team Members:
The biggest mistake made by newly formed Agile teams is not properly involving new team members from the beginning (planning stage). First, they should be involved to participate in planning. Second, ask for input on the proposed work. And finally, gather their insights towards the project. Empowering team members is to help them to take key decisions that impact commitment. If you are not allowing your team to do that, then they will never learn and will shy away from actual responsibility and will just follow along. The business only provides data and does not tell them what they have to do. When the team members have a list of requests rather than a set of directives, the involvement will be much more effective.
9. Lack of Agile Retrospective Meetings:
During the Agile project lifecycle, there will be many meetings that conclude sprints/iterations and releases which are necessary supporting structures in the inspect-and-adapt cycle. Your daily stand-up meetings should incorporate a retrospective aspect. When you end an iteration, include a demo meeting with the organization to show the work that has been completed. Here other teams can provide valuable insights and also gives you and your team much-required recognition in the organization. These retrospective meetings can be included in your team meetings to understand what went well and what went wrong in the iteration and how as a team we can improve upon them.
10. Failure to Address Employee Resistance:
Change is inevitable in today’s competitive environment. If an organization fails to incorporate the latest project management tools and techniques, then they will be left far behind from which recovering is all the more impossible. In an organization, some people may resist the change to Agile. One has to be prepared for such situations by getting the senior management involved from the beginning. As an enterprise, they have to make it clear to the workforce that they support the success of the team than an individual. They should eliminate personal performance metrics and opt for unbiased team assessment. You can address this problem by providing an environment of trust in the midst of potential cultural problems that Agile provides. Take the help of an experienced Agile practitioner on-site who can guide the organization to help negate subtle warnings that may arise during Agile implementation.
