My responses ended up being included in an article at AngelList (November 6, 2019). Extent of verbatim quote highlighted in orange, paraphrased quote highlighted in gray. Above image from cited article.
The responses I provided to an "anonymous" media outlet series of queries on September 17, 2019, and the journalist's follow up questions on October 1, 2019:
Media: I'm working on a couple of articles as part of a package of 101-type primers aimed for early career software engineers. The topics are on SCRUM METHODOLOGY and PAIR PROGRAMMING. They will include insights from experienced engineers.
Here are my questions: SCRUM--1. When is it used? (Is it a regular project management framework or only used in specific cases?) 2. Could you describe an aspect of scrum you learned while on the job (this could include anything salient / the most important thing you learned about scrum roles or events.) 3. What is some advice you can give to a novice engineer joining their first engineering team about scrum?
PAIR PROGRAMMING--1. When is it used? (Is it a regular way to work or only for complex projects/training purposes?) 2. Could you describe an aspect of pair programming you learned while on the job (this could include anything salient / the most important thing you learned.) 3. What is some advice you can give to a novice engineer joining their first engineering team about pair programming?
Gfesser: My response to you here focuses on the first primer article you've mentioned on Scrum, and the questions you've listed as part of your inquiry on this topic.
I'm certified by the Scrum Alliance as a Certified Scrum Master (CSM), as well as by scrum.org as a Professional Scrum Master (PSM), have led many projects as Scrum Master while simultaneously leading architecture and development, and have written extensively on the topic on my blog.
The Scrum framework has been used for a variety of use cases, even though it's most widely known as a framework used for software development projects. However, it also seems to be commonly referred to as a project management framework, but it is actually intended to be used for developing and delivering products.
While the Scrum Guide ( https://www.scrumguides.org/scrum-guide.html ) refers to Sprints as projects, in practice this can be a misnomer because project managers have no place within the context of Scrum. While it is easy to draw the conclusion that project managers should manage Scrum projects, since many do, Scrum is really intended to focus on product management, and there is a big difference between the two.
A product, such as a software application or data platform, has a lifespan for which a Product Backlog is relevant. For the duration of a product's life, it will either be built out, maintained, or extended with the addition of new features over time. While a Sprint is time period of up to a month for which such work is carried out, outside the context of a Sprint there are no deadlines and no rigid planning. This is because what needs to be built has a tendency to evolve over time, and the exercise (Sprint Planning) to determine the work to be done each Sprint is a chance to change direction as needed rather than marching toward a distant deadline. Focus is on whether what is being built and delivered is actually on what is wanted and will be used, rather than on meeting a deadline.
The most important thing that I've been reminded on the job about Scrum is that it is a framework that leaves many implementation details to the practitioners actually using it. For example, user stories are brief descriptions of features to be built out for a given product, but the Scrum Guide does not actually mention user stories. Additionally, when building out a product from the ground up as I have done for clients on many occasions, it often makes sense to write stories focused on laying the foundation, typically used by system (non-human) users. Unfortunately, many Scrum Masters do not have strong technology backgrounds, and so taking such an approach is not natural for them. Don't get me wrong: focusing on human users often makes sense, but it is not always the best approach and can lead to a fractured architecture if not carried out well.
The key piece of advice I would give a novice software engineer is to make sure they take the time to understand what their firm or client means when they use the term "Scrum", as this term has come to be used very loosely in industry, with many assumptions being made on all sides as to what it actually means. While novice software engineers may not have the ability to influence changes in how their work is carried out in the context of a project or product, I additionally recommend that they pay attention to how their firm or client intends to actually carry out the work, rather than focusing too much on documentation, since in many cases I've seen work derailed by executives who do not understand Scrum and instead focus on deadlines. If anything, I recommend that the term Scrum not be used if the simple structure of the Scrum Guide cannot be followed.
Lastly, novice software engineers should keep in mind that practices such as use of story points are intended to help the Development Team manage their time and what they are able to take on for a given story. Story points in particular seem to catch many novice software engineers by surprise, who tend to automatically start relating these points to time, as in 1 story point equals 4 hours, or something like that. This isn't the purpose of story points, since 1 story point can mean different things depending on whom is working on the functionality. And story points are intended to be relative within the context of a given Development Team, which over time will come to understand their velocity, or how many points of work can be done within a given Sprint. A different Scrum Team, a different velocity: velocity cannot be calculated for a specific developer, since their work on a given product within a given context needs to be taken into account.
Media: Thank you for your responses to the Scrum article. I’ve received the draft back from the editor, who has asked for a few additions.
Would you be able to share a few, brief examples about how you have used a Scrum event in an actual project? I am looking for practical examples for the list below, though you can choose to share your experiences about only a few of them:
- A sprint
- Sprint planning
- Daily scrum
- Backlog refinement
- Sprint review
- Sprint retrospective
Gfesser: All of these meetings you've listed are called Scrum ceremonies. Scrum is light on meetings, but requires these ceremonies each Sprint (except backlog refinement, which isn't an official Scrum ceremony, but an ongoing need for any product being built).
There is a lot to write about with all of these ceremonies. I'll cover Daily Scrum and Sprint Retrospective, because as a consultant I've seen frequent issues as to how these are carried out at clients.
(I've put a lot of thought into Sprints in the past, and you can read how I related these to my running career here:
https://www.erikgfesser.com/weblog/2016/
08/
scrum-a-runners-perspective-400-meter-run-relay-development-team-product-backlog-sprint-velocity.html ).
Daily Scrum is a simple, straightforward Scrum ceremony. At least it should be.
Daily Scrum is an exercise that I have organized on a daily basis to understand what developers have been doing since the last Daily Scrum, what they are planning to do until the next Daily Scrum, and whether there are any blockers (i.e. any impediments which prevent or delay work from being done). That's it. I've enforced Daily Scrum to be a daily touch point that is not intended for discussion. If discussion is needed, I take it offline with whomever it might apply. I've also enforced the start and end time. For example, I had a VP on my team once (whom I still called a "developer", as all individuals are called developers on a Development Team), and the first time he arrived for Daily Scrum they were late, so I excluded him from the meeting. While he wasn't happy about this, I assure you that he was never late again.
Like Daily Scrum, Sprint Retrospective is also a simple, straightforward Scrum ceremony.
Sprint Retrospective is an exercise I have organized for the end of each Sprint, essentially to understand what went well during the past Sprint, what didn't go well during the past Sprint, and what can be done the next Sprint to improve subsequent Sprint execution. The two issues I have typically seen are on the opposite ends of the spectrum: developers on a Development Team either sharing not enough or too much. Developers new to Scrum, or developers who have not seen Scrum successfully executed in the past, often do not share much. From my experience, this seems to be because they are either nervous about doing so, or because they have grown ambivalent from past experience and don't see the benefit. So what I've done is encourage developers to share their opinions, making sure that opinions are relatively anonymous by having developers write their thoughts on sticky notes posted to a board. I've seen some Scrum Masters put developers on the spot when they offer criticisms, and this will typically close them up from further sharing with the team. While a lot of feedback during Sprint Retrospective is a good thing, not following up to act on this feedback can also tend to close up developers because they will think that their feedback is not being addressed. I've followed the typical practice to have developers vote on items to address in subsequent Sprints, to help ensure that the items receiving the most votes are granted the highest priority for follow up and improvement.
Media: If possible, I am also wondering what happens if a team doesn’t use something like Scrum—does a project become harder to manage? Does a team lose track of things?
Gfesser: Keep in mind that Scrum is not project management. If anything, it is akin to product management.
Developers sometimes talk about something called "pure agile", which in practice is largely a myth that doesn't mean anything. The problem with simply following something like the Agile Manifesto is that it doesn't provide much substance, and developers will always have their own preferences as to how work should be carried out, sometimes leading to conflict. Some developers have even gotten to the point where they don't want to follow any process. The problem here though is that I've learned there is always a process, but it's a matter of whether the process is actually communicated. Scrum offers a very light framework which provides a lot of flexibility as to how things are carried out. As long as there is a decent level of agreement as to how things are to be carried out, it can often be successfully executed. However, not every firm is going to be successful with Scrum, and I've seen firms fail. There are dozens of frameworks out there, so firms just need to choose the right one. That said, "hybrid" frameworks between Scrum and traditional Waterfall, however, typically do not work out. Generally speaking, frameworks which enable a team to get their work done are going to be the most successful. Prioritizing the catering to management, however, is either typically not successful or leads to team stress, and team stress is an impediment.
The lifecycle of a product can be long, often multiple years. Making use of a Product Backlog for the life of a product, and a Sprint Backlog for the duration of any given Sprint, is crucial. Remember, one of the main purposes of Scrum is to make sure that what is being built is actually wanted and is actually going to be used. Product priorities change over time, and it is important to track these priorities. Just also remember that within a Sprint, the Sprint Backlog does not change unless the Development Team gives approval to do so. If changes are introduced to a Sprint without Development Team approval, it will additionally add stress and lead to dissatisfaction, and means that Scrum is no longer being followed.
Media: Thank you again for your thoughts. I had one more question for clarification. Would this sentence be correct? You had framed it as what you had learned from Scrum overall, but I was wondering if it would fit in this section:
Gfesser said that of the most valuable things he’s learned through backlog refinement is that it “leaves many implementation details to the practitioners actually using it,” rather than leaving the developers to solely imagine how the product will be used.
Gfesser: I'm not sure which "section" you're referring to. My original statement was the following:
"The most important thing that I've been reminded on the job about Scrum is that it is a framework that leaves many implementation details to the practitioners actually using it."
I'm not sure why a connection to backlog refinement is being made. I don't think this sentence would be correct.
Backlog refinement isn't a principle concept in the Scrum Guide. While there is room to execute this activity in different ways, I don't think it's a good example of loosely defined implementation details.
See all of my responses to media queries here.