Given that my family has relocated to the Orlando, FL area to be closer to grand parents, I have enjoyed getting to connect with the maker and technology communities of O-town. In particular, I have had the opportunity to connect with a very special group, Agile Orlando. During these coffee meetups, Scrum masters and agile leaders gather to informally discuss leadership practices and innovations in their processes. It’s a very energizing opportunity to share what works and doesn’t work. I really enjoy the “lean coffee” format of the meeting. (Learn more about Lean Coffee here)
On a personal note, it has been awesome to reconnect with my former scrum master and friend Ken Nordquist. I would say that Ken helped inspire me to deeply learn about Agile and Scrum. During a previous engagement, Ken served as our technical manager and impressed me with his ability to focus and energize the team with Scrum. Like many organizations, we had silos. Ken found ways to inspire unity through pair programming, peer review learning sessions, and fun Scrum rituals. I feel blessed to join the Agile Orlando community which he helped organize. If you’re in the Orlando area and want to take your Agile team to the next level, make sure to check out Agile Orlando on meetup. (https://www.meetup.com/Agile-Orlando)
Here’s a few ideas that I found helpful. Hope that you find them helpful as well.
Agile business analyst: In my previous teams, I have never had the pleasure of having a business analyst(BA) integrated into my team. In some ways, I feel like I have served as a BA to help increase the clarity of user stories. Based on some of the stories shared at the team up, I can see benefits of hiring for this role. The following blog post from AgileModeling.com expands on the idea of having a BA on the team. ( http://agilemodeling.com/essays/businessAnalysts.htm )
Design sprints: One team talked about their practice of using design sprints to increase requirements clarity. From the scrum guide, we know that the product owner should be working ahead of sprint planning meetings to make user stories very clear. In my experience, achieving clarity of requirements is not easy. Our coffee team talked about using design sprints to groom the backlog in a cross functional manner. I guess the term “design sprint” is another name for grooming the product backlog in advance of sprint planning meetings where the development team needs to take action on stories. At this one shop, their design sprint team included a UI designer, product owner, QA engineer and technical leader. QA leaders also appreciated having more lead times for test case creation or test automation.
This blog by Sarah Ford post outlines related ideas to this concept: https://blogs.msdn.microsoft.com/saraford/2010/02/04/how-agile-works-my-program-manager-cheat-sheet/
Definition of ready: At the present time, I’m really focused on thinking about user story clarity. Our coffee team reminded me of the practice of “definition of ready.” Here’s a post on the topic: https://www.scruminc.com/definition-of-ready/
Product owner sign-off: During my previous experience, I have used Sprint review sessions to engage the product owner in “VER/VAL” activities. Some other teams leveraged a practice known as product owner sign off. From our discussion group, some of the teams integrated product owner sign off into their “definition of done.” I can see that this practice would reduce the stress of formally organizing a sprint review. I thought it was a cool idea. For more information on this practice, check out MountainGoatSoftware.com.
Intentionally pay down technical debt every sprint: Consider allocating a 10% to 15% of your sprint to paying down technical debt or investing in test automation. Technical debt can slow the business down. In our coffee group, it was mentioned that Ebay had accumulated so much technical debt that it had become hard to ship new features without breaking many other things. It took one year for Ebay to pay down their technical debt to help them move their business forward. According to the Scrum guide, all team members are empowered to add stories or defects to the backlog. With that in mind, one team intentionally tracked technical debt stories in their product backlog using a work item tag.
Cool retrospective question: Did we introduce any technical debt into the product?
What leadership practices are positively transforming your teams?
Photo credit: https://www.flickr.com/photos/iadmedia/
Leave a Reply