Thinking that process is a silver bullet that can fix everything is sort of like early economic theories that presumed that accurate predictions of markets can be made without incorporating human behavior. You need to factor in the people and the business culture using the process.
Many, if not most software businesses are conducted in a waterfall way even though the product they are making may be built using an agile process. Think about it. At the beginning of a year most companies create a plan that contains the business goals, budgeting, forecasting, staffing plans and pretty much everything else they can think of. This can create friction between departments and teams, because these yearly plans have dates, quarters, revenue goals, and vanity metrics associated with them.
So why do companies whose products are created using agile methods do all this upfront planning? Agile is about reducing the time spent doing long-term planning, releasing features quickly and refining based on user research and business metrics. Most businesses budget a whole year in advance. Budgeting means allocating resources, setting up project timelines and goals for the whole fiscal year. Each department does this, but every department has a different process in terms of how work and projects are approached. Deadlines can be set months in advance. Don’t forget that sometimes dates extremely relative to a products reception. Up to forty percent of a retail store’s annual revenue is earned during the holiday season. But as we all know often dates are set based on the business expectation when things should be done. A department can be as agile as they want, but if the business goals and deadlines are set in stone then you might end up just running agile sprints within a waterfall process.
The power of agile as well as the meaning of the word implies flexibility, which is why switching an IT department to an agile process alone doesn’t make for a successful software product. For the business to optimize it’s success it needs to listen to the feedback and adapt it’s products, goals and sometimes even budgets. Agile can be used to get feedback faster, but agile doesn’t solve everything. I’ve seen and heard about agile teams letting their own agile process slow them down. While agile is definitely better and faster than waterfall that doesn’t mean it should be continuously improved. This is why the lean startup buzz started, agile alone wasn’t good enough.
Don’t let process and dogma get in the way. Here’s a common mistake, the end of a release cycle might be approaching too fast, which leads to a feature being deployed without a way to measure it’s success. The justification for this might be something like, “It’s always better to release. Agile says we should release as often as possible.” If process is put first then the feature get released and you have no way of learning about how to improve it. Then you’ll have to wait until the next release to add in the metrics. Most agile releases are done every two or three weeks. So if it would have taken two days to add in the ability to measure the feature that’s an additional 12 or 19 days of data that could have been collected. We have to remember to be flexible with our process and use it as a baseline not a rule book.
Continuous deployment to the rescue! Well, not completely. While you will be able to roll out a feature faster, it doesn’t change the fact that the business may impose having a group of features by a set date. I do think it helps, but realistically the business has plans and those plans have deadlines. If the business won’t listen to feedback that feature x is crap, then it won’t matter how many times you release before a product is realized. Make sure to use the benefits of getting data often by releasing frequently to inform the business of your progress towards reaching it’s goals. Sometimes the data you get will mean change the goals of the project. Other times the business may just shift dates or features as needed. The business may learn to be more flexible when they trust that you are working in the best capacity to help them be successful.
The entire business needs to have a learning and listening culture before any process can work. Communication is the key for making processes drive results. Dates and deadlines will never go away, but by working together with different departments and being flexible in our processes we can learn more about why a business needs to reach a deadline. By understanding our deadlines we can prioritize features to help reach the goals of the business and ultimately the users of our products.
Learn about other departments processes, be flexible, question everything and strive create a learning culture. By gaining and giving insights into as many parts of business as you can, you’ll be able to create a better user experience. Remember the user experience of a product is much more then the form and function of the interface. As designers we should try to work as closely as we can with our users of our product, but also with our team mates. Get to know as many people from each department as possible and work with them when applicable.
There isn’t a single process that works for every person, team, department or business. If a particular process has worked well for a certain business it generally not because of the process, but because the culture of that business.
Remember other fields of work done in other departments may have different processes than we do. These processes may not seem compatible with agile, but by being flexible with our own processes we may get departments to work together better. We need to be agile with our agile process.