At the end of 2015, I set an intention to give back to my local Agile community and share the ideas that had helped our Agile teams succeed through speaking. I was fortunate that this happened relatively quickly, and just over a year later, I set an intention to speak at a conference.
My inspiration came from amazing speakers who had shared their great ideas and I knew that not only did I share their passion, I just might be able to reach that level of mastery. I wrote about my journey to become a great speaker in a previous post. It's been a journey of discovery and many surprises, the biggest one that it takes a LOT of confidence and TONS of work to do this.
The agile community is full of passionate, incredibly smart people. Every conference has hundreds, if not thousands, of submissions. I found the key to being selected is to look around the community and find a common problem that doesn't yet have a well-known solution. As a result, I just completed my first conference speaking event at Agile and Beyond 2017.
For example, Agile values Working Software over Comprehensive Documentation. Teams that know how and what to document using other methods frequently struggle to find a solution in Agile.
I myself struggled to help the teams find a simple solution for the old practice of documenting Design. We tried several options, and then through the gifts learned from Ron Garton of Agile Coaching Network, found an extremely simple solution to look at the common Architecture Layers during backlog grooming and draw out the existing system elements we're going to leverage as well as new elements we need to build to satisfy the conditions of the user story.
This method uses Draw.io, a free Flowchart maker and Online Diagram Software, but it could be built using any Flowchart software. While the technique is valuable, what the team gains from it is the true gift. The technique sparks the conversation between team members, not only about how to build the user story, but also, how to validate it, whether there are any dependencies that need to be considered, whether the team needs to research the new solution if they've never used it before, and it can also be retained to increase future domain knowledge for that system and new team members.
Quite a lot of value for a simple diagram!
What do you use for your team's Agile Design?