Q&A with Scrum Masters

Editor's Notes

• #2: LINDSAY Hi All – I’m Lindsay and I have Courtney here with me and we are Scrum Masters at Turning Technologies. If you are not familiar with us, we are a technology company based out of Youngstown, OH. Our company makes audience response technology, which is more or less a fancy polling app used in training and learning environments. So if you listened to our talk at the last Atlassian Summit, I’m going to reiterate some of the issues we have run into in the past while transitioning to Agile, and then open the floor up to Q&A so we can talk through some of your issues. We may not have all the answers, but we do have experience on how we have handled particular Agile situations, including what has worked and what hasn’t worked for us.
• #3: LINDSAY Turning WAS initially a waterfall shop and we made an Agile transition about 4 years ago. It really took us 3 years to get decent at it. During that time, I personally was transitioned into the first full-time Scrum Master role the company ever had, so I dealt with a lot of the growing pains first-hand. Some of these included team members handling dual roles instead of having one person designated per defined role, executives dictating our roadmap and overriding Product Owner decisions, teams that lacked self-organizing skills with little guidelines on how to handle or communicate issues, and ill-defined processes that were rarely followed or enforced. I’ve often stated that transitioning to Agile is easy on paper, but hard in real life.
• #4: LINDSAY A few of the challenges we faced when making this transition to agile to a team-based environment included: No documentation or processes Poor team communication Now there were plenty more, but these are just the two that commonly rise to the top. Putting some specific processes and tools in place can really help minimize these pitfalls, so I’ll quickly go over what we have found has worked and what hasn’t, and then let you ask some questions as well.
• #5: LINDSAY A LOT of problems can be solved with proper documentation. Literally, our rule of thumb is to write EVERYTHING down and that includes: Meeting notes, including action items that are actually assigned and able to be checked off by the owner Process - processes often start with documentation. Something about putting on paper/writing it down solidifies it, and it forces people to follow it if you have reference to it. Whenever a question arises about a process, you can simply refer to the documentation. So write it down and try it! Policies and templates - HR forms, finance policies, company-themed templates, sales presentations – all of those items should be housed in the SAME platform, all under the same roof, so that all documentation lives in one place – so find a tool for documentation that works, and enforce it
• #6: COURTNEY The way we effectively achieved organization, collaboration and transparency at Turning was through the standardized Atlassian suite of tools, which includes Confluence for documentation. Benefits include: Organization It allows for spaces to house all documentation that is specific to a topic or department – we refer to this as a large container for your organization Collaboration All the editing! We are constantly adjusting documentation and the ramp up time for learning - the Confluence editor takes minutes to master – if you’ve ever used Microsoft Word before, you can get the hang of Confluence Collaborative editing is an amazing feature that allows the page to be open and edited by multiple people at the same time Transparency:  Having everything housed in Confluence once again opens up the door for transparency among your organization If you start documenting processes, technical notes, meeting notes, etc. your can quickly and easily get everyone on the same page by having those details documented out
• #7: COURTNEY Once you have your documentation tool and start enforcing it, this is where your processes can really flourish. Start with a process and make sure you ADAPT – I can’t emphasize enough that Agile – it is not one size fits all. You need to continually inspect and adapt your processes until they are fully efficient and effective.  Even when you think you have mastered the processes, you will STILL improvements you can make, so keep an open mind and be willing to embrace change. At the end of the day, you have to do what works best for your organization, so Agile may look different even from department to department. For example, our sales and marketing teams are using Scrum, while our development teams are using Kanban.  Pick what works best for the team in order to get them into a high-performing state. In order to quickly spot some of the changes you can or need to make, be sure to utilize your retro meetings.  Often just asking a question as simple as “what can we do better?” will open up a world of ideas that can really enhance your processes.
• #8: COURTNEY Now onto another top challenge – communication. Communication issues happen in every relationship, including your team environments.  This can be really challenging too when you’re making a big change such as transitioning to Agile, or different flavors of Agile like Scrum or Kanban.  During those changes, things may be lost along the way, so you’ll need some tools and processes to help you find issues that may fall through the cracks.
• #9: COURTNEY Make sure that everyone knows the appropriate method of communication for different scenarios.  Lay it out step-by-step and document it – in your central documentation space like Confluence – so that everyone can refer back to the appropriate processes.   <Review bullets> If you have ever put together an Incident Response Plan, you’ll know it is essential to detail out when to communicate and through what channels.  For every type of communication, make the plan and work the plan regularly. All comes back to following the proper process.
• #10: COURTNEY One other way to communicate is through passive communication.  Systems like Jira make development information plain and simple.  Development on a specific project is broken down into issues. Team members are then assigned the issues, which are visible on a board in various statuses which allows everyone to know exactly who is working on what.  Each project is open so development teams can even see each other’s issues so you even know what other teams are up to. In order for this information to be accurate, however, Jira - or whatever tool are using - HAS to be kept up-to-date.  At first, we had to constantly hound the developers to update their issues, but our persistent nagging paid off, because we rarely have to bother them about issue statuses.  Updating and adapting processes can be as simple as this - we recently created a filter of issues that haven’t been updated in 3 days, and this is sent to us daily. This allowed us to automate part of this process and be immediately alerted when issues may not be accurate.
• #11: LINDSAY In addition to putting your plan together, another piece of the puzzle is your Scrum Masters. Your Scrum Masters should be the Eye of Sauron for your development teams – they should be all seeing and all-knowing. Scrum Masters should be involved in all team meetings, taking notes and following up on action items. It may sound tedious, but taking good notes that provide context of a conversation and any decisions made are invaluable. We’ve lost count of how many times developers have thanked US for thorough documentation. But, if your Scrum Masters are going to be all knowing, then you have to be able to scale. Essentially, you need at least two Scrum Masters to work your teams – and may need more depending on the size of your development group. For us and for now, having 2 Scrum Masters to approximately 30 developers divided between four teams is manageable. There are going to be overlapping meetings, random projects that fall out of the scope of the day-to-day, and general everyday chaos for which your Scrum Master team will need to tackle with more than one set of hands. If you are going to scale successfully, you need a team. And when it comes to scaling, don’t forget you’ll need dedicated resources driving the teams – AKA one product owner per team. Their full-time role is Product Owner, not developer/Product Owner or Software Director/Product Owner – just straight Product Owner. That’s also a reason why we are able to get away with having just two Scrum Masters as well – we have a great group of Product Owners who truly own their products and direct the teams appropriately. That rule of thumb actually applies to any position in the Agile process – at least one person per role AND not anyone who is dual-wielding jobs. THAT ultimately leads to a communication breakdown when you don’t have enough people to truly tackle Agile-defined roles.
• #12: LINDSAY So, we’ve talked through a few of the big issues that we’ve encountered when making an Agile transition. So, now we’ll open the floor to any questions you may have! Nothing is off limits, so feel free to ask us whatever is on your mind. Alright, let’s open the floor.
• #15: I think that wraps up today’s session. If you have additional questions you can reach us at any of the above email addresses. Courtney and I run an Atlassian User Group in Youngstown, as well so feel free to ping us about our group too and we’ll be happy to tell you more!