In this episode, we explore the use of NoEstimates approaches in a regulated and governmental environment.
When Craeg and his team was called in to the Social Security administration, they were asked to help the Office of the Inspector General (OIG) assess the use of software development methods in an environment where the teams were adopting Agile methodologies, but the overall governance still followed the old school, linear (aka waterfall) methodologies.
When the OIG is involved, it usually means that the organization being audited needs to prove that they are taking good care of public money invested in their processes. Therefore the challenge was to ensure that the teams were both following the Agile practices they said they had adopted, as well as taking the necessary actions to ensure proper use of public funds.
In this episode, we cover how Ben found his vocation for the Scrum Master role, and the techniques he applied to break into the tech industry and the Scrum Master role.
Changing industries is never easy, but changing from non-tech to tech and to a completely new role, like the Scrum Master role is even harder.
For many of our guests, the Scrum Master role has been a calling, a sort of vocation that becomes obvious once you start. For our guest in this episode, Ben Mills, the vocation to be a servant leader and to help others overcome struggles was already there. And that vocation was what attracted him to the Scrum Master role.
People before anything else
When Ben started to learn more about the Scrum Master role, and eventually after taking the Scrum Master certification course, he understood that the role called for a mindset that put people before anything else. Their relationships, the collaboration, their ability to solve conflict, etc.
At this point Ben, at the time a Pastor, started to apply what he had learned in his own team. Ben had been a project manager before, so organizing and following up was not new, but the role of the Scrum Master and the process of Scrum called for something else.
Breaking into the tech industry and the Scrum Master role
For aspiring Scrum Masters, it may not always be easy to first break into the tech industry, and later into the Scrum Master role. Ben shares with us some of the tips that helped him, and still help him to grow his network, and find the right people to ask questions.
In the end, the perspective that people are the critical link in the success of teams can bring insights and prepare you for the role.
But perhaps, one of the stories that influenced Ben the most, was one story of his own. When he was starting out as a project manager, and learned an important lesson about transparency. Listen in to find out what that story was, and how it can transform your work as a Scrum Master.
About Ben Mills
Ben is a scrum master, a project manager and a Pastor. That’s a very unique journey that he is sharing with us.
He’s starting his career as a scrum master and is sharing his journey with us on this BONUS episode.
Raphael has been a guest on our regular show, and in those episodes, we approached the topic of Agile applied to Business Intelligence projects. In this episode, we dive deeper into the concepts and ideas that Raphael mentioned earlier, and we learn how Business Intelligence projects can be delivered incrementally, and in an agile manner.
Slicing User Stories to enable incremental delivery
We start this episode with a practice that is critical for Agile teams: how to slice User Stories to enable the delivery of incremental value to customers. We discuss several strategies that Raphael uses to be able to deliver valuable functionality even in the first week of a project.
Taking into account that usually, BI projects are executed by larger, and more traditional firms, his approach brings clarity and ensures that the team and the customer are able to evaluate the product from the first week. This practice is critical in collecting feedback from customers early on and avoiding producing products (dashboards, in this case) that no one will use.
In Raphael’s perspective, the focus should shift from “sizing” stories to understanding what might be a good experience for the customer: customer delight; and then validating those assumptions directly with customers by delivering possible solutions very early on.
As a way to apply #NoEstimates, Raphael started to apply the concept of “timebox” (limited time) to each of the User Stories being developed. His own rule is that a User Story should be developed within 1 or 2 days at the most, which pushes the teams to focus on what is critical to provide value to the customer.
Timeboxing User Stories to validate assumptions
In this episode, we also explore how Raphael came to the realization that User Stories need to be timeboxed, rather than estimated. He shares a story of a project where the team produced a dashboard that did not get used by the customer (they had metrics). That was a transformative point in Raphael’s approach, leading him to focus on early and often delivery. Which led to the #NoEstimates heuristic that a User Story should be given a timebox.
Raphael Branger is a Certified Disciplined Agile Practitioner and a pioneer in adapting agile methods in the context of data and analytics projects. He works as a Principal Consultant Data & Analytics at IT-Logix in Switzerland with more than seventeen years of experience in business intelligence and data warehousing.
In this episode, we interview Andre, Fabian and Aleksandar, team members at one of the Runtastic App teams. At the time of recording, they had 5 months of experience with #NoEstimates at the team level, and that led us to explore how they applied #NoEstimates; what prompted them to change their way of working; and many other practical questions related to the use of #NoEstimates approaches in their product development work.
This is a BONUS episode on the topic of #NoEstimates. The Agile Wire podcast hosts Jeff Bubolz and Jeff Maleski interview Vasco Duarte.
Some of you might have heard about #NoEstimates, and want to know more, and for others, it might be the first time you hear about it. Either way, in this episode we talk about the origins of #NoEstimates and why you may want to consider it when helping your teams.
This is a shared episode with a fellow Agile podcast The Agile Wire, where hosts Jeff Maleski and Jeff Bubolz interview Agile practitioners. Both Jeff Maleski and Jeff Bubolz have been guests here on the Scrum Master Toolbox podcast.
About Jeff Bubolz and Jeff Maleski
Jeff Bubolz is a speaker, trainer, and agile coach. He has been a Product Owner, Scrum Master and Development Team member. Jeff has worked with enterprise companies to small start-ups. His goal is to end human suffering in organizations, by nudging people to be the change they want to see in the world.
Jeff Maleski is passionate about working with and building up both individuals and teams using ideas from Jurgen Appelo’s Management 3.0 and Dan Pink’s Drive. When leading project teams, Jeff strives for empirical based planning and forecasting, continuous learning, and delivering high quality software products that exceed expectations. Jeff believes in leading by actions and focusing on building relationships with others.
Scrum Masters often have to face cultural anti-patterns when working with teams, and the organizations they are part of.Those cultural anti-patterns are being amplified by the move to #Remote work due to the #covid19 situation.
What can we do? How can we get ready?
Here are some tips to get you started or to help you further adapt to this new reality.
Lack of transparency is even worse when #Remote
There are many Scrum Masters that come on the Scrum Master Toolbox Podcast and share stories that relate to a culturally-engrained lack of transparency. This lack of transparency takes many forms:
Team members don’t share their struggles in the Daily Standup because they perceive that as a sign of weakness (for example)
Product Owners don’t share the reasons why certain changes are brought into the Sprint, perhaps because they themselves don’t know
Other teams we collaborate with don’t share changes to a dependency we have on them
Whatever symptoms of lack of transparency you experienced when working in the same office, those symptoms will only get worse when our organization moves to #Remote work. Some of the reasons are:
Individuals are less engaged and motivated due to the stress, or being distracted by the presence of children while they work, or because they don’t see (and therefore don’t take into account) their colleagues during the day
Sudden tasks or priority shifts are communicated to individuals, and the rest of the team isn’t physically present to witness that change
Now that we’re distributed we miss out on all the spontaneous collaboration that used to happen.
Tips for Scrum Masters to increase transparency and foster collaboration
As Scrum Masters, we must be deliberate about improving transparency and collaboration in #Remote teams. Our domain of expertise is collaboration, and we must keep adapting to enable collaboration at all times. Here are some tips, that may help you improve transparency, information sharing, and collaboration between team members and with other teams:
Have a collective retrospective with the teams on which your team has regular dependencies
Discuss with the Product Owner how to share changes to the Sprint so that all team members are aware and can share their possible impact on the work they have to finish
Move to a shorter Sprint. Agile is about creating more, and faster, feedback loops. As we go #Remote those feedback loops are even more important. Shorter sprints provide more transparency (problems are found faster), makes the amount of work smaller which helps with clarity (shorter stories), and with identifying and solving process problems in the team, and across teams
Have 2 daily check-ins
Quick tip for #Remote#Scrum Masters: Have 2 check-ins / day. One at the start of shared work hours, and one closer to the end of shared work hours. Make the second an “informal” check-in (e.g.: ask each team member to bring their favourite drink and enable video).
Integrate more often. If you are integrating with dependant teams at the end of the Sprint, consider bringing their work into your daily build pipeline, or assign specific team members on both teams to work on integration from the start of the sprint
Track dependencies on other teams just like you would a User Story. Understanding of dependencies will grow during the Sprint. Make sure you are covering that dependency on the Daily Standup if nothing else to learn that “everything is proceeding according to plan”
Create an URGENT Slack/Teams channel, so that team members can always explicitly ask for help to solve a problem they are facing. When #Remote, even waiting one more day can make the problem harder to find.
When we are #Remote, collaboration and cooperation are harder to achieve, and transparency can be a critical trigger for that collaboration to flourish. Consider what you can do as a Scrum Master to improve collaboration. Every day.
Stay Safe, #StayHome
More tips, and more insights from the Scrum Master Toolbox Podcast
Rainer Tikk writes this guest blog post about what Product Development looks like from the perspective of a leader of a software organization in a mid-size bank. He’s the Head of Software Development at LHV, an Estonian bank betting on IT as a competitive advantage.
To a non-IT person, developing an IT solution might often seem like a mystical activity that boys with ponytails (and some girls) do in a dark basement somewhere. Moreover, software development, in general, is an expensive activity altogether and often takes more time than it really should. And even if there is money available to pay for the software development, more often than not, it’s almost impossible to find a developer to build the stuff you need.
The financial processes of companies can defeat their own efforts to become more agile. It’s simply impossible for an organization to be adaptable if their project processes require all projects to be specified up-front and funded months ahead of their starting date.
Tackling the financial process changes in our organizations is one of the make-or-break aspects of helping organizations become Agile and adaptable.
In this episode, we talk about Lean and Agile Financial Planning (PDF article download), an approach that tries to adopt Agile and Lean thinking in the funding and financial processes of an organization.
The reason why Lean and Agile Financial planning is a core aspect of Agile transformation in enterprises
When we get started as Scrum Masters, especially those that have a Project Management or Management background, we tend to “enforce” Scrum. As our understanding progresses though, we start to learn that there’s a lot of value in helping teams learn by themselves, help them feel confident and take over the process.
In this episode, we discuss that change in our approach to the Scrum Master role, and a lot more!
Doug has been an agilist since before it was cool, as his first agility client can attest. He is currently the Director of Agile Development & Coaching at Wisconsin-based Flexion inc., leading agile teams that serve both private and public sector clients. His current hobby is thinking beyond agility, to antifragility.
Ben is a project manager with experience in developing digital services and products for worldwide clients. He’s learned some very important lessons and shares some of his key insights with you in this special episode, where we dive deep into the project manager role and the project management world.