In our struggle with waterfall software development and the inherent shortcomings of over-planning, Agile was first eschewed then embraced as a “lean” and “user-centered” approach to faster development and smarter features. But the pendulum has swung to the other extreme, and many of us are feeling the momentum move away from up-front planning, in favor of a misunderstood Lean Engineering practice I’ll call “just-in-time architecture.” This is a bad trend that is only suitable for pet projects.
I’ll say only this about the engineering impacts: Just-in-time Architecture is for those who enjoy refactoring, being stuck with a suboptimal approach or technology, and reporting to stakeholders that follow-on requirements are actually “new features” and will require more work than expected.
What I want to focus on is what a lack of architecture and advanced planning does to the Product team and a software company’s ability to meet the changing needs in a market. Just-in-time may suit straightforward single-track roadmaps, the kind run by garage-level startups. Teams that experience larger, complex, multi-track projects know that estimating is a cruel mistress and published, linear roadmap can become quite misleading just a month or two in. I appreciate what Pavel A. Samsonov contributed recently on Twitter, showing illustrations and explanations of linear roadmaps, what I’d call “funnel of uncertainty” roadmaps, and strategic roadmaps. His thread is a quick and worthwhile read.
If Product teams don’t maintain the discipline of understanding the entire scope of likely functionality, it can be all too easy to follow their Development teams down a slippery slope to “Just-in-time Product Requirements” which we know leads to “No-time-for Customer Discovery and Usability Testing”. I HATE being in that hamster wheel! The urgent feeding of the development backlog for features that aren’t fully vetted is cyclical and un-ending. It’s nearly impossible to get out of. If you’re there right now, stop running and step out of the wheel now. You’re going to need a new wheel anyway. Trust me, this is the only way. Get out of that wheel!
Successful software companies, large and small, need options and sometimes look to pivot. Timing for these changes is critical to meet capacity and sales/market opportunities. Not understanding project scope, benefit, and size makes considering trade-offs speculative and only transiently helpful. We know that we can’t understand all of these things perfectly from the beginning! There is a funnel of uncertainty and it is a function of life and business to make decisions about things before we completely understand them. In short, Agile has nothing to do with Product planning and everything to do with product delivery. If you don’t have the capacity to get ahead of the needs the Development team to plan your roadmap and explore the scope* of the current and future projects, you’re on a hamster wheel and you need to get off. Stop and have an honest resourcing conversation. The success of your product and company depend on it!
*Understanding “the scope of a project” is extreme shorthand for market research, customer discovery, requirements gathering, assumption testing, wire framing, viability testing, nailing value prop, customer pre-validation, etc. I didn’t want to crowd the paragraph with all the things we know go into planning great products and projects.
P.S. Back to the Development side, Simon Brown goes into a lot of detail into software architecture and planning in a YOW! talk he gave on the lost art of software design. This is 45 minutes long and may only be worth watching if your team is struggling.