What Not to do When Going Agile

Going Agile can be an exciting challenge, and at times, daunting and confusing.  The list below describes all too common mistakes that lead to frustration and stress for the team.

Whatever your position, use this information to help keep your transition to Agile on track.

1. Don’t think Agile means a ‘free for all.’  As managers, put essential, and flexible work processes in place.  Let the team come together to define those processes.  Always bring the team to consensus, then publish, communicate, and introduce workflows, especially to new team members. Create enough of a framework for the team to rely on expectations and have a cadence to their work and delivery schedule. 
2. Use a tool for stories and defects (like JIRA), and plan how it will be used. This should be done collectively by management, the BAs, Developers, QA, and any other stakeholders who will use the tool to perform their work.  The team needs to understand, capture and express what the tool will do for them. Whichever tool you use, it should provide progress in real time and be automated once the status reporting requirements have been gathered.   Make sure the dashboard view is available to the individuals who want to have access. 
3. Publish the workflow and make it readable. It always helps when everyone has the same notion of the next step. 
4. Have an onboarding plan for new team members, even if they are internal to the organization but new to the project.  Share the shared information.
5. Define what ‘acceptance point’ or ‘acceptance criteria’ means. Make sure they are clearly stated in the User Story.  It is critical for the Product Owner to contribute here as she/he will be the final word for story acceptance.
6. Have a formal time and system in place with the product owner for story prioritization. This is easy to overlook or to misunderstand as something given. 
7. Managers should provide access to and funding for training if it is wanted. Include contractors too, as they will need to be on the same page as the rest of the scrum team. 
8. Leadership should be clear that rapport, availability, and participation is expected of all stakeholders and team members, sometimes at a moment’s notice. 
9. Product Owners need special attention understanding their role. They will spend more time on a weekly basis dedicated to the activities involved in Agile vs. Waterfall methods.  Beyond the initial prioritization and periodic status updates, the product owner will be a critical player in the new method.  They will be involved in continuous prioritization, story refining, and defining the acceptance criteria.  Don’t underestimate that demos and release notes will be more frequent too.  
10. Project Managers are a great asset to the scrum team, although not technically part of it.  If an organization uses PMs, tasks of reporting, tracking, presenting can be funneled to the PM by the Scrum team and the tool.  The PM can be the unofficial team member that keeps all the deliverables accountable and reflect this information in the way that PMs do.
11. Schedule meetings in advance. Elaborations, pre-grooming, grooming, scrum planning, retrospectives, and don’t forget demos! Keep in mind that it is a continuous effort of requirements definition, development, testing, planning, and delivery that occur simultaneously.
12. Set limits when change can occur, for example, if a new requirement is requested the day before scrum planning, set clear expectations that the Story may not be ready for commitment the next day.  Keep the tendency to override common sense in check. If it is possible to include a Story on short notice, Agile will accommodate it. If not, though, it may be best to plan for the next iteration and present a properly written Story.
13. Don’t assume that everyone in the team knows Agile and how to contribute.  Team members can have different amounts of experience in Agile, and even experience in different organizations.  Have a protocol for story development and workflow. Clearly state that while the expectation for each role is described (for example QA will own the QA tasks and activities), also press that flexibility and a willingness to work cross functionally is expected.
14. Don’t use Story Points to equal any of the following: 
    1. Business value
    2. Time measured in hours or days
    3. Productivity measured by points
       Do use the following to estimate:
    4. The level of complexity for the deliverable
    5. Ability of the team members
    6. Capability of the team as a whole
    7. Availability of resources
15. Managers shouldn’t overload the team, iteration after iteration. Agile moves quickly and the goal is to deliver successfully at the end of the iteration. Overloading will just burn out your team.  Try to balance time in a healthy way.
16. Don’t assume that it is easy for people to change the way they do their work. It can be a stressful and confusing experience to move from Waterfall to Agile, especially for individuals who have been comfortably ensconced in their waterfall position for a long time. Anxiety may surface. It needs to be recognized and eased with stability and balance. 
17. Don’t think it will happen overnight. Change takes time. Like the expression, you can’t make a baby in one month with nine mothers, in all cases, it will take nine months. 
18. Plan for defects and bumps in the road. Be ready for workarounds when the unexpected happens. 
19. Don’t miss the chance to cross train. Everybody needs a backup or two, and as possible and as able, team members should be able to back each other up.
20. Don’t recreate Waterfall with the face of Agile stand-ups and JIRA.  The benefit of User Stories vs. cumbersome requirements documents is to streamline delivery of requirements. Use the Story framework to capture requirements at the appropriate level of granularity, and to articulate the acceptance criteria.  Developers need the chance to enhance the Story with solution ideas.  The Quality Team needs to use their method of choice to capture and track testing. The Product Owner needs to keep reviewing and contributing to Stories as they move towards scrum planning and commitment.  
21. Don’t be afraid.  Change can be embraced, even when it is the way you do your work.  Remember that Agile will streamline your delivery, and lift the weight of documentation.  Team members should approach estimation with their best judgment.  Over time, the meaning of your team’s story points will be well understood and estimating will be refined.  Managers need to give the team time to adjust and don’t hold them to velocity demands, at least in the beginning.  
22. Don’t ‘not-talk’ to each other.  The scrum team needs to be open and willing to talk.  The open space for scrum team office designs has this intention.  Conversations should be easy, and information shared willingly.  The best teams understand that each member is needed, and when the members are strong, the team is strong.
23. And perhaps most importantly, don’t be mistrustful of each other.  In an Agile team, the success will be directly mapped to the level of trust the leadership and team members share.  Each person needs to be valued for what they bring to the delivery objectives, and each person needs to be entrusted with their role.

Working in Agile can and should be a challenging but equally rewarding experience.  As professionals, we choose to be part of software development for the unique qualities of creating, building, and delivering technology.  Agile done right, can be the optimized experience of true teamwork.   Work through the transition with patience and tackle each roadblock that surfaces one by one, just like the approach to developing and delivering great software!