 There is an English proverb commonly written as, "Silence is golden." I attend many daily standup and user story grooming calls that could be politely described as "golden". A quiet team is often a symptom of a newer team learning to work together. They are still forming. How do you get a tentative team talking during daily standups and user story grooming sessions? Daily standups are easier to solve. These meetings are quick with a streamlined agenda. Calling on each person, in turn, can make short work of getting the daily standup questions answered and people into their day. User story grooming is trickier. It is imperative the team understands each user story. Questions are vital, but sometimes in short supply. We use a couple of techniques to spur conversation and build understanding. We ask a team member how they might build the solution once the user story has been reviewed. This reveals if the team understands the ask. Have you ever thought you knew how to do something, but as soon as you tried to describe it out loud, more questions popped to mind? This is common. When a developer attempts to articulate the solution, additional questions arise which can be discussed immediately. Our team uses planning poker to estimate our user stories. Each developer sends the scrum master their points estimate. Those with the lowest and highest estimates discuss why they voted as they did. The discussion may reveal additional complexities or simpler solutions. Either way the team benefits from the conversation. I prefer to embrace the fuller version of the proverb which is, "speech is silver, silence is golden". Both are valuable, just not equally. The quiet meetings will pass as the team gains confidence. Until then, add a little silver to those golden meetings. Ask questions. Be direct. Call on people if necessary. Before long, you might wish we were a little quieter. Photo by Kristina Flour on Unsplash
1 Comment
 We have a good problem with a customer. Our #servicenow initiative has strong leadership support with rapid user adoption. Such success translates to rapid growth in our team size, user base, and data. This means more feature requests and functionality for our users, but if we're not careful it can also mean a diminished user experience. As the data, users, and team sizes grow, how do we expand our castle while keeping our citizens happy? By using the same techniques we should use from the very beginning. Seek to understand. It is critical our developers and testers understand the solution from the user perspective. Our developers support their code so, when our users experience issues, our developers are made keenly aware. We ask a lot of clarifying questions to visualize how our users leverage the solution to succeed in their jobs. It can also help to have developers and testers shadow power users to spark understanding. When your team understands how their users work, they can improve the user experience and speed feature delivery. Drill the basics. We instill the basics of good coding for every developer no matter their experience. Write efficient queries. Always strive to return the smallest number of records in a query to complete the task. Use conditions aggressively. Comment your code and conduct peer review to train and help each other. Use database indexing. Get familiar with database indexes and how they work. They can improve performance tremendously. Use logging with intention. We use system properties to control logging within our code. This allows us to toggle logging on or off by setting the system property value rather than editing the script. Do your testing. Specifically, performance testing. Large data sets impact performance. If you are not testing in a production-like environment you may be asking for trouble. A test scenario may work flawlessly in a development instance with minimal data, but fail miserably in production with several million records. We maintain one non-production instance with production-like data so we can put our solutions through its paces. This way that inefficient query should get caught before it ever becomes a production issue. How do you keep your citizens safe while expanding your castle? London Tower wall
Photo by Julie Canfield on Unsplash  Recently a teenager I know very well asked me, "So what DO you do?" When I'm asked what I do for a living I am faced with summarizing my job in a way that is understandable to this person. Often they do not have a technical background. Telling someone I develop custom, business facing solutions for companies using a commercial platform as a service (PaaS) toolset gets exactly what you would expect; a blank stare. So, what DO I do? I build castles.
For purposes of our discussion I likened ServiceNow to the insanely popular Minecraft game. In Minecraft my friend can build whatever he wants with a prebuilt set of tools. Farms? Yes. Castles? Sure. He has a platform to work with. So do I. My customers pay me to help build all sorts of useful applications to help their businesses. While he still may not know the details of everything I do he walked away with a better understanding of:
Sometimes, with great customers, I get to build castles, in the sky! What DO you do? Photo by Cederic Vandenberghe on Unsplash |
AuthorChris Halverson is an IT consultant focusing on ServiceNow development. Chris has built a career as a "jack of all trades." By blending his early experiences in tools integration and ITIL process work, ServiceNow became a natural evolution. Chris began focusing on ServiceNow in 2010 working with every version; seasonal pre-Aspen through today! 
Archives |
