How To Build Products with Cutting-Edge Technology Using Agile Methodology
During her three years as a software engineer at Carbon Five, Rose Karr has had the opportunity to work on several projects that involve cutting-edge technology. She has found that while working with this kind of tech can be exciting, it also presents a unique set of challenges. In a recent talk, Karr discussed some of the problems she’s encountered and offered suggestions as to how software engineers can combine the scientific method and agile methodology to find solutions to difficult problems.
To begin, Karr raised eight questions that may arise when a team is working with new technology:
- How do we navigate unexplored territory?
- Where do we start when there’s no clear path forward?
- How do we dedicate time to research and planning without losing velocity?
- How do we adapt as our understanding improves?
- How do we make hard decisions?
- How do we answer questions that have never been asked before?
- How do we avoid duplicating work when we don’t always know what we’re working on?
- How do we make sure what we’ve learned isn’t lost after we’ve gone?
Karr noted that scientists have used the scientific method for centuries, and suggested that developers use their own modified version of the scientific method to help tackle tough questions like the ones listed above.
By following the process of research -> experimentation -> assessment and repeating as necessary, software engineers can use this modified “Scientific” Method, combined with agile methodology, to find solutions to complicated problems, Karr explained.
During the research stage, the goal should be to learn as much about a topic as possible by drawing from a wide range of sources. From an agile standpoint, team members should continue doing research until they’ve come up with ideas for experiments, she said.
While in the experimentation stage, developers should figure out which ideas are worth pursuing and building upon. More often than not, Karr noted, it might turn out that there is more than one good idea, or alternatively, there may be no good ideas.
And finally, in the assessment stage, team members should share what they’ve learned, and document their findings.
All of the different stages can be represented in agile stories, Karr explained, which benefit the team by unlocking future work, and usually result in more stories for the backlog.
Karr noted that the “Scientific” Method can be repeated by developers as many times as necessary if their experiments fail. When experiments succeed, the team can move into its usual agile processes and continue to build products.
Developers may sometimes need to repeat the research -> experiment -> assessment part of the process several times before moving into agile processes and exploring their ideas further, said Karr.
“We can do research and experiments when we don’t know how to move forward, and once that research and those experiments give us the answers we need, we can move on to building things,” she said. “And all the while we can track our progress with documents and proof-of-concept experiments and we can manage our work just like any other stories in our backlog. When we break down our problems into smaller and smaller steps with research and experimentation at the start, there is no problem too big or too complicated for us to solve.”
Want to learn more? Join our next Product Development Forum Meetup for monthly conversations about the intersection of product, design, and technology.
