Agile methods grew up around technical practice, with roots solidly planted in the fertile ground of software engineering. Certifications in Scrum all require understanding of engineering practices, and the more senior level certifications require both in-depth understanding and practical application. The message would seem to be that Agile practitioners must be Software Engineering practitioners.
However, non-technical teams are adopting agile methods as ways to better organize – or, more accurately, self-organize – in increasing numbers. As the language and history of agile is so strongly steeped in software engineering, applying agile methods in a non-technical setting requires some translation to be applied in a non-technical team.
This doesn’t have to be difficult. Let’s try translating the language of a few key agile principles and practices for a non-technical product team.
The key measurement of success is a working product: An agile team focused on software development measures its progress primarily by the delivery of working software. But regardless of composition, every team must have a mission, a goal, a raison d’etre. This must be the primary focus of the team’s efforts. Whatever that focus – a published book, a new ad campaign, an online marketing program, or even a new cookie recipe – the most important outcome is a working product.
Form a dedicated, cross-functional team: Agile software development teams must include all functions required to bring the software to the end user. These teams often include design, UX, development, QA and business analysis skills, so the team is self-reliant and solely dedicated to the project at hand. Enabling the agile team to be self-reliant is key to success, as managing dependencies is a key constraint on success of any product development – regardless of the product type. In the case of a textbook, for example, the development of that book may require several subject matter experts (authors), an illustrator for examples, a designer for page layout and flow, and an editor to bring it together. In an agile authoring team, these very different functions work side by side and concurrently to produce their book in sections rather than in sequence. Whether technical or non-technical, ensure your agile team includes all skills needed to bring your product to fruition, regardless of organizational constraints.
Set goals, understand constraints, and then break your work into manageable chunks: Agile practitioners center their efforts on goals. Once the product goals are clear, any constraints or dependencies are identified so they can be resolved or mitigated. The agile team then defines the work required to achieve their goals and breaks the work down into smaller pieces. This process of breaking the work down – or backlog refinement, in agile parlance – is an emergent and evolving process. This means the work being done first is broken down into the smallest possible chunks while the work being done later can remain in somewhat larger chunks for the time being. In any event, the highest priority work, the work to be done “next” in the product delivery sequence, is completed in small pieces and in short time frames. It’s simpler to manage the work in smaller pieces and, delivering small bits of incremental product builds momentum and confidence. This is a winning formula for software and non-technical teams alike.
Engage Customers and Stakeholders throughout the Product Development process: These small and manageable pieces of work are then shown to end-users and stakeholders as they are completed. Agile software development teams frequently demonstrate working software, sometimes in prototype form, to gather feedback and input continuously. Often the end result ends up looking and functioning quite differently than the original vision – but the product is poised for success, as the end user needs are already incorporated into the product. Just like their engineering brethren, non-technical teams can organize their work in a similar fashion, and achieve the same benefits of continuous learning and stakeholder involvement as their product is created. Any agile team should focus on validating their work with end consumers early and often. Continuous end-user / customer validation throughout the creation process, and ongoing stakeholder involvement, means there are fewer surprises as the product evolves and iterates toward success.
Ensure team participation and communication, and give them the tools to self-organize: Despite the trend toward a fully flexible, work-from-anywhere workplace, countless studies have proven that there is no substitute for face-to-face communication. Whether the product is technical or non-technical in nature, the best agile product development teams are co-located, not only in a single physical building but in a single room / area of the building. When this is not possible, the team agrees to shared work hours that apply in all locations, and are available on video chat for all team activities and throughout the agreed-upon shared work hours. Enabling continuous communication with a partially or fully distributed team is a major headache, but is critical to the success of the product development effort as well as to engendering the essential atmosphere of self-organization. For this reason, non-technical product teams need the same level of face-to-face communication, and when they are not co-located, they must make every effort to learn to use video-chat for all team interactions.
I’m not the only person with aspirations to bring agile methods home from the office. Bruce Feiler gave a TED Talk in 2013 on his own experiences in using Agile Techniques to help his family manage their time.
As Agile methods become more widely adopted and success stories continue to mount from software product development, it is only natural that the non-technical teams in your organization may want to adopt these methods as well. While using agile for non-technical teams will require some creativity, as well as some translation and adaption, you will find the benefits of spreading this product discovery and delivery culture throughout your organization will yield benefits that make any additional effort well worth it.
Written by Christine Novello
Leave a Reply