Day 58 — Demystify series 6/7: “Project Agility: Working Fast & Slow”
Published in
9 min readApr 27, 2019
Many teams believe that Agility means always rushing, always pushing; and I beg to differ. In my experience, the truly Agile organization brings their agility to the maximum by adopting different methods, pace, frameworks to suit specific project needs. So, what’s the secret recipe? The true way to optimize project agility is: Changing Gear Quickly.
Agile doesn’t mean teams are always chasing tight deadline, it means that the project team is agile enough to quickly change the way the plan, do, check, and act. What worked when we went fast, and what didn’t work? What made us successful when we took our time, and what made us failed? Analyzing the experience, learn from it and quickly pivot, that’s the true spirit of Agile. In this article, I’m going to introduce the pros & cons of “working fast vs. slow” by breaking it down in the following structure:
- Benefit Comparison: Enhancement
- Benefit Comparison: Prevention
- Agility Criteria: When to Switch Gear
The true way to optimize project agility is: Changing Gear Quickly.
Enhancing, with Fast & Slow
There are many aspects in product design/development can be enhanced through working fast. Similar words can be said in some other areas by taking appropriate time — working slow. Let’s explore a little bit of what I mean by that:
Benefit of working fast
- Team velocity: When a team is passionate taking on a new project, moving fast to score quick wins can help keep that excitement going and maintain that team velocity. Another aspect is that, if you don’t move fast toward the timeline, project can drag. According to Parkinson’s Law: “Work expands to fill the time available for its completion”. When project starts dragging, people tend to loose the sense of urgency, and sometimes that affects their performance.
“Work expands to fill the time available for its completion” — Parkinson’s Law
- Personal/Team growth: A fast-pace project usually force people to think fast, work together, and do things differently. Therefore it boosts their creativity and becomes an opportunity for personal growth and team bonding.
- Time to market: In a mature & highly competitive market where all the competitors are trying to release new features to appeal to customers, time-to-market becomes a key factor for product success. Therefore there’s a need for teams to move fast and test idea quickly in the market.
- Best use of limited resource: when a project is structured in a way that resources arelimited and there’s no work around, working fast can help test the water to see: a. if there’s a legitimate reason to ask for more resource to ensure project success; and b. is there any benefit to continue the project with the current construct.
- Agile organizational culture: When teams move fast and triumph, it becomes a good case study for other teams to learn and think about how to enhance the organization culture to focus on corporate agility.
Benefit of working slow
There are also lots of good reason to take time to work things out. Some good reasons listed below:
- Quality in Details: Certain types of projects are craft focused. For example, if you’re building a fancy yacht for super high-net-worth individuals. In those cases, there’s no good reason to rush and sacrifice the quality.
- Better planning for complex project: When dealing with a complex project in which there are lots of dependencies that need to sort through, rushing to implementation doesn’t bring much benefit. In these types of project, “failing to plan is planning to fail”. An appropriate amount of time dedicate to pre-planning and planning is necessary.
- Research the unknown: When a project is mainly dealing with lots of unknown, or in Eddie Obeng’s definition, a Quest project (like going into a jungle), preparation and analysis are definitely the key elements to determine the project approach.
- Project Dependencies: Sometimes some projects rely heavily on the other area for its readiness. For example, a data-driven product will need the data to be ready; a product in a highly regulated industry will need to fist sort through those legal requirements; a project that involves lots of counter parties will need to settle on contracts and agreement. Without sorting out these dependencies, a project might not be able to come to fruition, or even worse, causes million-dollar law suits.
- Corporate culture influence: When working on a project that’s going to affect large amount of people in a big hierarchical corporation, rushing to deploy only creates unwanted backslash. In a corporation of Clan culture (according to Robert E. Quinn and Kim S. Cameron) which oriented a family-like, focusing on “doing things together”, it will take time to understand the impact on all the individuals in different department, and make a proper plan according to individual’s needs.
Preventing, with Fast & Slow
Benefit of working fast
- Analysis Paralysis: If you’re familiar with the origin of Agile, you probably know that the reason of the birth of Agile is to tackle ineffective upfront analysis, or some call it “analysis paralysis”. By creating working product fast, we can test it out in the market to know if we’re having the right assumption, solving the right problem, or solving it in the right way.
- Project Waste: When a team is seeing the sign that some of the notorious 7 Waste might happen (e.g. Waiting, Over-processing, Overproduction), moving into a fast pace, “Lean” way can help prevent the project from some of these redundancy.
- Scope creep: a quick way to verify if the team is suffering from scope creep is to quickly test it in the market. When the real feedback from users comes back, we know how aligned we are between project scope and users’ expectations.
- Bureaucratic process: In order to avoid unnecessary bureaucratic process, a good way to resolve it is to work fast by limiting the scope, so that less counter parties and departments are affected, hence shortening the approval process.
Benefit of working slow
- Reputation risk: When the project is directly related to brand value, or it’s affecting large clients that’s maintained through relationship, reputation risk is high and there’s no need to rush it. For example, the disaster of Gap’s logo/branding redesign received all kinds of backslash on Facebook and Twitter.
- Performance risk: When the product performance is at high stake (million or billion dollar), and those workflow of “unhappy path” could cause million-dollar loss or even life loss, there needs to be appropriate amount of analysis done before the product release. For example, a stock trading software in capital market usually goes through a “ Fat Finger” test, in order to prevent traders from accidentally put too many zeroes and transact a billion-dollar trade when the intention was a million-dollar one. Other examples can be found like the 3 Mile Island nuclear plant accident, or the false missile alert in Hawaii in 2018.
- Other risk: For example, when dealing with globalization, entering new market in new countries where culture, legal & compliance requirement are drastically different. For example, Nike’s made a million-dollar mistake because the logo design of their sub-brand Air Max on certain shoes resemble the Arabic word “Allah”.
- Project waste: Some of the other project redundancies in 7 Waste (Inventory, Over-production, Defects) cab be prevented with better planning effort. Tech debt in software development, and design debt in user experience design, are possible to be limited if appropriate analysis is done well. For example, a good design system can reduce the effort in designing/redesigning certain reusable components; a well planned modularization effort can reduce the over-production on reusable code.
- Large investment: When working on designing/producing physical product, especially high-manufacturing-cost products like cars, airplanes, a failure can bring down the whole business. A thoughtful plan that’s carefully crafted with thorough risk assessment is imperative to the project survival.
Criteria, for Fast vs. Slow:
Based on what I described above, if we categorize all these pros on cons of working fast vs. slow, there are four criteria categories to help us consider the pace of the project:
- Clarity: How much do we know about customer and competition? How much do we not know about the market and cultural impact? Is there any other similar case we can learn from? If there’s lots of uncertainty, it’d be “better safe than sorry”.
- Risk: Do we know well about the legal requirement? Is this a high-stake project that if we fail it will hit hard to the brand value and company performance?
- Reward: Are we stuck in a place that quick changes need to be made in order to unstuck us? Are we piling up intangible requirement with little or no feedback from users? Getting something out of the door might help us restructure how we work.
- Organizational culture: Are we ready for a change? If so, how are we going to do it without tearing ourselves apart? Think of the scale of the issue, and find place to be nimble and move fast, while remain certain level of stability so it doesn’t become a show down.
Conclusion
- Agility is not about always rushing, it is about changing gear quickly for the situation we’re in.
- Working fast can help unstuck ourselves from bureaucracy and analysis paralysis, however it doesn’t suit the needs of a high-risk, high-stake project. Working slow buy us time for appropriate analysis and preparation, however it needs to be carefully monitor so that we don’t over-engineer or lose the time-to-market.
- Except for the nature of the project, other considerations include team velocity, corporate culture, and long term risk & reward.
How do you choose between fast pace working vs. thorough analysis? What are the tips you want to share? I’m eager to learn from you.
ABC. Always be clappin’.
To see more
The opinions expressed in this article are those of the author. They do not represent current or previous client or employer views.
