When your users aren't agile!

For many years, if not decades companies have hammered their IT organizations to move faster. However, in the past decade as more and more technology companies have come to the forefront of our society, traditional companies are salivating over the perceived pace at which those new technology companies can move. These companies are the Google’s, Facebook’s, PayPal’s, AirBnB’s, SalesForce.com’s, and WorkDay’s of the world. Headlines that CIO’s, CEO’s, CMO’s read over and over again include words like Agile, Speed to Market, Sprints, Continuous Development and Development Operations (DevOps). When you dig into these headlines, they often tell stories of small, nimble teams working on revenue producing products. In addition, these innovations are happening in companies that have rooted their culture in test and learn development approaches and failure is celebrated as just another learning. The disservice to these stores is when a CIO, CEO or CMO turns to their organization and says, “Why can’t you (IT) be like them?”.

A simple answer to that question is because Users aren’t often Agile. Putting a mirror in front of any of these “C”-level executives or frankly any executive who asks the above question is a requirement to moving faster. The question IT needs to be asking of these leaders or their organization as a whole is “Are you and your users Agile?”. Meaning, can you accept less than perfect applications, can you dedicate resources to make decisions in minutes and hours instead of days, weeks or even months, can you change your business processes and are you willing to invest in continuous development. To move fast in any organization requires a cultural shift, not just a shift in IT practices.

What does it take to be successful at Agile?

For any Agile initiative to be successful, there are several pre-requisits that you must consider. First is fully dedicated resources to the effort from all key stakeholders (i.e. Business, Vendor, and IT). If any one party is unable or un-willing to commit their resources 100% to the effort, an Agile approach will struggle to be successful.

Second, the team size should be limited to between 10–20 individuals Agile teams can be as small as 2–4, but should not be bigger than 10–20. The smaller the team, the faster they are often able to go. However, note that really small teams may struggle as there simply is not enough diversity in thought to work through issues expediently.

Third, 98% of all decision-making should be able to be made by the team regarding scope, schedule, and architecture. This usually requires a single person assigned as the decision maker (or tiebreaker) within the team. Every time a decision has to go outside the team, momentum is lost. This is usually the hardest hurdle to overcome when leveraging an Agile approach. Corporate leadership has to be comfortable succeeding decision making authority to the team and assume the team will do what is best for the company. If leadership can not give this authority there are two additional choices, assigning someone from leadership into the Agile team or deciding on a different approach. Remember to be on the team, they need to be 100% allocated. If your leadership is able to accommodate this than by all means, have them play that role.

Fourth, failure must be accepted. Agile teams never get it right out of the gate and the company needs to set its expectations as such. Agile embrace the test and learn approach, where requirements are quickly enabled, used by the users and feedback is then taken to improve the experience. Rarely does an Agile project get any one requirement right out of the gate. Instead of pointing fingers, wavering on support of the approach or team, jumping up and down in frustration, leaders simply need to be express support, empathy and encourage the team to keep moving forward.

Why is Agile beneficial?

Go back to when you were in elementary school and had show and tell in class. The best thing about show and tell, is it was easy to get the class to understand why you were so passionate about that match-box car or teddy bear. The class could see and touch your item. Fast forward to Agile, the best part of Agile is you get to show and tell your work to you users. Just like when you are in class, your users can see and interact with your work and give you real-time feedback. That is the magic of Agile development.

Why is Agile so hard?

There are many ways to answer this question, but lets focus the answer from the perspective of your users. Agile is hard in many ways because so many of our users are trained in the traditional approach of traditional Software Development Life Cycles, mainly a waterfall approach. Now your users won’t use those same words, but we have trained them to that engagement approach with IT. There are several challenges we have to overcome to ease the path for Agile delivery.

Requirements. Our users are trained to spill out their requirements to be captured in a word document and process flow. They are asked to give us every possible requirement they have, we are then expected to rationalize these requirements and remind them of what they can afford. Through negotiation, we end up with a list of requirements that the user expects at the end of the program.

Instead, Agile keeps things at a high level and then builds requirements in a more fluid manner, ultimately showing the users small bits of requirements at a time. Users have to learn how to envision the end product while evaluate bits and pieces. There is often no upfront agreement on all requirements. As users give feedback, requirements shift and change. The uncertainty and unpredictable nature of Agile can make users uncomfortable.

In addition our traditional approach to development has trained the users that they are only needed for a limited amount of time, up front to define requirements. Agile asks our users to engage continuously and in an ideal setting, engage permanently by joining the Agile team.

Funding. Due to funding processes at most companies, IT comes once to solve a business problem. The users are then asked to live with the solution and then go fight for additional funding if they need to tweak the solution after using it. This sets up a nasty cycle around how requirements are captured, where users won’t let go of any requirement because they re afraid if they do, IT won’t be around to adjust the solution due to funding constraints.

Agile, doesn’t solve all funding issues, but because the show and tell / test and learn philosophy of Agile, users get into the solution from the get go and can give real, actionable feedback. They can see and touch the requirements and understand the tradeoffs when making decisions future requirements. The Agile team can then adjust the solution and again show and tell the users for additional feedback along the way.

The caveat to this funding discussion is that at some point your money runs out. The state of your solution has to be something that can go to production and delivers the expected value to your users/business. In order to do this, a disciplined approach to prioritizing their requirements through each sprint is important. One lessoned learned is don’t put your users reporting needs in the final sprints, move them up in the cycle or better yet, embed them in each sprint.

Perfection. Traditional software development life cycles created this dynamic between IT and their users that solutions will be perfect or near perfect fits to the business problem. Our users have been trained to accept nothing less than everything they want, because if they don’t, they have no idea when they will get funding to address unmet requirements. We have to retrain our users to accept being done more than being perfect. In addition, we need to train our company cultures that development on critical business applications should never be done. Instead they should have continuous development, similar to how many companies invest in their products on an continuous basis. Agile enables continuous development in a frictionless way by engaging users early and enabling them to interact with the solution along the way.

The final question that you need to ask is what do you need to do to make your users more Agile? As your leadership may be enamored with the concept of Agile or getting to market faster with solutions. You need to consider the cultural and behavioral changes that may need to occur across the organization. Without addressing these, Agile won’t get traction in your organization.