Between some recent experience using Agile development methods and other recent readings on the subject it is clear to me now that Agile development – done well – is not only about engineering. Engineers using Agile methods can improve their operations, but taking a business approach to Agile can have dramatic impacts, and compound the impacts of any efforts done by engineering alone.
In retrospect, after learning more about Agile processes, I have become convinced that businesses traditionally under-support engineering teams, and expect them to “work their magic” operating in something of a vacuum. And, while the Agile methods themselves are not magic, Scrum processes (and other Agile methodologies) provide a great framework for fixing the disconnection between engineering and the rest of the business. By pulling sales, marketing, and stakeholders into the product development cycle, engineering is equipped with more salient requirements that the market truly values in a process that provides feedback and validated understanding. And, ongoing engagement and feedback through the short Agile development cycles keep the execution on target to provide great new products.
And, by more deeply engaging the broader team, several important, very healthy, and very valuable things happen, which I have seen first-hand. First, as the larger team sees regular progress in development, the creative process becomes more immediate to the team, and the desire to engage increases – which has a very positive effect on the value of the final product. In response to this engagement, the engineering team becomes even more motivated to please their new more immediate customer set – including real customers, the engaged internal team, and business leadership stakeholders, resulting in still higher levels of engagement and productivity. In short, the team becomes more integrated, and mutually invested in each other’s success.
This healthy / high feedback / symbiotic relationship is often in strong contract to the interactions in many companies, where engineering can be viewed in somewhat negative terms – expensive, frequently late, and often missing the mark. Of course, the flip side is that engineering cannot understand why sales and marketing don’t have the promised commercial with completed products, or why new product requirements are always unclear and churning! As business leaders, we really should find such dysfunctional behavior crazy, as engineering is one of our most expensive functions, and the life-blood of tech companies.
The point to take to heart is this: Agile engineering practices can have a very positive impact on product development. In my experience the improvement is significant. But, transformational change happens when the whole team engages, using Agile tools to work together to gather important ideas, transform ideas into strategies, strategies into plans, and plans into efficient and exciting product releases. Short development cycles and fast feedback keeps things on target. But, it is also important for business leaders to understand that while engineering may launch Agile initiatives, the process spells out this cross functional engagement, and engineering will expect business level support. From my perspective, the changes are of huge value – but cross functional leadership is needed to realize transformational improvements.
As you might be able to tell, I am just getting started – I should do the contacts page in a day or two.
Thanks,
Lee House