Top Ten Ways to NOT Screw Up With Agile
Agile, applicable to product development across a range of industries, is becoming an increasingly spotlighted methodology – so much so that it may be difficult to fathom not reaping the numerous benefits of agile. A word of caution must be extended because of the seeming inability to screw up with agile. It is possible for agile to not result in success, but is also possible to avoid this scenario.
What ensues is the detailing of the top ten ways to avoid screwing up with agile, such that you can be one of those who implements agile successfully and reaps the rewards.
- Take team meetings – with everyone included – seriously.
This point cannot be emphasized enough. It is too easy to be lax with who attends meetings, with the thought that if some or most team members are in attendance, then the information from the meeting will be conveyed to those absent. This mentality clashes with agile implementation. Despite the repetition of daily meetings and the time invested in them, they are important to successful agile implementation, for meetings allow issues to come up and be addressed, and for everyone to be on the same page regarding progress on the project.
- Do not forego the PO role.
It may be tempting to view the Product Owner role as one that can be doubled up, in that the PO could take on development tasks in addition to their PO duties. The PO, however, should be fully committed to PO duties and only those. The PO has their hands full with handling the requests of stakeholders, conveying the project requirements to the development team, and ensuring that the final product fulfills requirements. To have the PO take on development work would draw their attention away from these significant duties and potentially tarnish the quality of the project.
- Define what “done” entails for your organization, and make sure everyone is on that page.
One development team member’s definition of “done” is different from that of another. This necessitates that everyone, including the Product Owner and the development team members, is clear on what entails a completed story. If there are different definitions of “done” floating around, then matters become complicated and work may be hindered, as people continue to adjust the quality of tasks according to their definition of “done” instead of addressing other product issues. Not having a single definition of “done” also interferes with measuring velocity.
- Estimate stories in relation to other stories, instead of in relation to time.
It is important to measure stories in terms of points, a metric that enables comparison of stories and which is crucial in the measurement of velocity. Estimating stories in relation to one another – relative estimation – is more effective in agile than estimating the amount of time to complete stories – absolute estimation – as the latter requires consideration of multiple factors, including individual team member differences in productivity, chances that the work goes according to plan, and the time to complete each stage of a cycle. Agile emphasizes flexibility and relative estimation provides that. It also prevents the team members from rushing their work to fit a time estimate.
- The Product Owner should loop in stakeholders consistently throughout development.
This point is related to the PO’s thorough fulfillment of their duties. Some PO’s may think that it is sufficient to meet with stakeholders to discuss the product’s development merely at the beginning and upon completion of the product. POs should touch base with business stakeholders throughout the development process, after each sprint is completed. This helps to ensure that the stakeholders will not be unpleasantly surprised upon product completion.
- If using agile, be consistent.
Either completely transition to agile or do not, but do not combine some agile components with non-agile practices. This is detrimental to productivity and the work result. Some may think that it is harmless to adopt some components of agile, while forgoing other parts of it, such as skipping the PO role or having the PO be a mixture of PO and other duties. This complicates matters and prevents everyone involved from benefitting from the full potential of agile.
- Establish clear goals for each sprint.
Not establishing clear goals for each sprint is a sure way to screw up agile. Agile is more open-ended than other methodologies, but in order for it to work well, there cannot be ambiguity in establishing the goals of each sprint. Without clear goals, development team members will have issues focusing, and the ambiguity can lead to a lower productivity than if they had clear goals from the get-go.
- Product Owners cannot forget that they are one with the development team.
It may be difficult to remember that POs are not management in the traditional sense, but with agile, it is a vital point to have in mind. POs cannot impose new tasks upon team members, as doing so would interfere with the project at hand – with negative consequences to the project being completed with agile.
- Make use of the ability to measure team velocity.
Measuring and knowing your team’s velocity is a relatively simple process that will provide useful information for achieving success with your agile project. Not measuring velocity hinders the ability to estimate what to establish as sprint goals.
- Development team members are not entirely on board with agile – due to a lack of adequate information.
Another way to ensure that the benefits of agile will not be reaped is to skip agile training for development team members. Agile training is an important factor in swaying team members to accept, and be informed about, agile and the work process that they will soon be a part of. Without adequate training on agile, team members may not be equipped to fully contribute and may not perform as well as if they were fully knowledgeable about agile and its benefits.
Agile is not a magic bullet method, despite its numerous advantages and its vast potential to boost product development. If the above ten aspects are not taken into play, then it is possible that your agile implementation will not yield the full potential of agile. On a positive note, following the ten points is relatively simple and will help to ensure that your agile efforts are met with success.