Home » Teams

Creating an Agile Playground

As all tech companies can tell you, the relationship between business and IT teams is a partnership that is necessary, critical, constantly transforming, and occasionally aggravating.

At Progrexion, we work hard to maintain the secret sauce for keeping our cross functional work efficient, progressive, and fulfilling for all team members involved. About a year ago, our software team made a huge organizational shift to their work flow. Gone were the days of one large project request and here were the days of scoping, sizing and velocity. We officially entered the Agile Development landscape.

As the Product Owner for our marketing systems, there are very clear successes from integrating this new process; as well as new areas that need to be maintained and monitored to ensure the success of the process. If your company transitions to this trendy new organizational model, prepare yourself for both the increased efficiency and the attention that will be needed for people management. Petier Fabrique gave an excellent synopsis on the things to look for with Agile during his recent presentation at SXSW this year.

Here is my Top 5 list of “facts to know” when jumping into Agile – based on our transition to the new model with our Progrexion marketing and IT teams.

1. Respect your sizes.

One of the most common temptations our agile teams face (on almost a daily basis) is to alter story points, once they jump into the work. If the story ends up being more complex or less complex than anticipated, there is inevitably a request from someone on the team to adjust the size, in an effort to more accurately reflect the actual work that was done. The dangers we have seen in changing sizes mid-iteration are:

  1. It detracts from the importance of accurately sizing, in the weekly sizing meeting. This can cause the sizing meeting to lose much of its value, if the team feels that sizes are adjustable throughout the process.
  2. Although the intention is to make velocity more accurate, inevitably all user stories are not reviewed and adjusted after the fact – causing an apples-to-oranges comparison when looking at sizes between user stories.

2. First Contact is key to user story success.

The success of a user story is completely dependent on how well the business user and developer understand the goal of the request being made. For our teams, a “First Contact” is required as soon as a developer begins work on a user story. The “First Contact” gives the developer a chance to ask any questions that might need to be answered, and allow for a short brainstorming period between the two team members. Often the developer provides insights and suggestions the business user had never thought of. This is where the agile method has a competitive advantage over other models – allowing for innovation and collaboration from everyone involved.

3. It is impossible to over communicate.

Our teams operate on a two week iteration cycle, which seems short and manageable. However, it’s very easy for disconnects to be created within the iteration cycle, if the business and IT are not communicating on the progress of the user stories being worked on. With so many moving parts, we find the most success with Agile when all team members (creative, marketing, development, QA, etc.) are giving updates throughout the iteration cycle. Through this communication, the entire team is able to troubleshoot unexpected issues throughout the two week cycle. This ensures valuable time is not lost, and maintains the predictability that is the keystone of agile.

4. Make sure the numbers don’t lie.

Once agile is fully implemented with your teams, it’s easy for the process to hide management issues, IF you are only relying on the numbers. While the agile process allows for definitive resource and workload allocation, the process can quickly unravel if the resources and work load allocation become unbalanced. Oftentimes, a shift in productivity can be missed, if only relying on numbers.  Make sure to do regular gut checks with your velocity (Is the team working through a 5 point user story in a comparable time frame to 5 point user stories, worked on 6 months ago?, etc.) and with the business to ensure the story shown by the numbers lines up with the story seen throughout the business.

5. You’re never “done”.

With the agile process, there are big pays offs to monitoring the process and making small tweaks to any of the areas that are going stale. Are acceptance criteria becoming less specific? Is there a gap between deliverability and velocity? Is team engagement slipping in planning meetings? Is there a rift between the cross functional teams that needs to be resolved? These questions and many, many more will help to get the Agile process adapted to meet the needs of your team.

Just as the agile process is built to allow for flexibility on specific work requests, the process as a whole should remain flexible and adaptable to fit the changing needs of the your business.

Leave a reply