The Woke XP Practitioner's Guide To Sprint Planning & Story Pointing
A Quick Intro To XP
Extreme Programming (XP) is a software development methodology that emphasizes close collaboration between customers, developers, and testers. It was first introduced in the late 1990s as a response to the traditional heavyweight software development methodologies of the time, which were seen as slow and bureaucratic.
XP is based on the idea that software development is an inherently unpredictable and constantly changing process. To deal with this, XP emphasizes iterative development, continuous testing, and continuous feedback. The goal is to produce high-quality software that meets the customer's needs in a timely and efficient manner.
Some key practices of XP include:
Overall, XP is intended to be flexible and adaptable, with the goal of producing high-quality software in a collaborative and efficient manner.
I personally have had the great fortune of working with many high-functioning XP teams, and it is by far the best in my opinion in terms of building software both efficiently and collaboratively.
The [S]crummy Status Quo
Many companies and teams that follow the scrum methodology. Probably if you chose any software team at random it would likely be some variation of scrum, where the work is broken into different size pieces of work called stories. Each story is assigned to an individual who opens a pull request which is then reviewed and approved by one or more other people on the team.
Sure, scrum does technically work in the sense that progress can happen in building the software, but each woke XP practitioner will tell you that scrum is not the way. Scrum seeks to minimize the amount of human interaction for engineers, making it extremely difficult for organic mentoring to happen
The Key Difference- Pair Programming
Pair programming is a software development technique in which two programmers work together on a single computer to write code for a software project. One programmer, called the "driver," is responsible for typing the code and implementing the design, while the other programmer, called the "navigator," reviews the code and offers suggestions and guidance. The two programmers switch roles frequently, typically every 30 minutes to an hour, in order to maintain focus and prevent fatigue. Pair programming can also be done with both engineers driving and navigating at the same time, for example by each having a mouse and keyboard plugged into the same computer or with remote pair programming tools like Pop or Parsec.
The Sprint Planning Meeting
In all flavors of agile, even XP, there is some type of cadence, usually once every one or two weeks, where we have meetings which I like to call the "agile ceremony" meetings. Other key agile meetings include retrospectives and backlog grooming meetings. Usually, a product owner, business analyst, or project manager will prepare stories (little virtual index cards representing and explaining blocks of work to be done) within some type of work tracking software. The key purpose of sprint planning is for the engineers to make sure they understand the work that is coming next!
Planning Poker
A very common game to ensure understanding of a story is planning poker. Everyone is sitting at a table with a card (traditionally numbered in the fibonnaci sequence, but sometimes with "t-shirt sizes" instead). Everyone makes their choice in secret. Then all players reveal at the same time so as to not be influenced by the choices of others. While unbiased answers are a positive aspect of planning poker, we believe that it would be even better without the numbers!
The Points Are Pointless
The key issue with using sizes is that the focus of the meeting is drawn to the sizing rather than to the main objective of ensuring that the engineers understand and can handle the work that is coming next! The traditional scrum system uses a fibonacci or "t-shirt sizes" scale to quantity the size of a story. It sounds nice to quantify to the size of stories, but unfortunately too often precious meeting time is spent consolidating disagreements about whether something is a 3 or a 5 or why Johnny always points a few points higher than everyone else or how you are even supposed to quantify "size, complexity, AND effort" into just one number... The truth is the points are completely pointless, and if your scrum instincts want to say, "but what about our velocity number!" to which I would say, "yep, that's pointless too". You'll know if you're getting stuff done because stories will be getting closed and because you'll be getting closer to and reaching the goals of what you wanted to build in your software.
Recommended by LinkedIn
Pairing Drives Accountability, Not Points And Deadlines
Points are too often used as a way to shame stumped engineers who are too afraid to ask for help as managers will say things like, "this is only a three-point story? Why is it taking you so long?". Or worse, it's used as a measuring stick to pit engineers against each other. This makes engineers even less likely to collaborate, and in extreme cases has incentivized colleagues to sabotage each other! and Of course, the woke XP practitioner will always take the us mentality, the collective code ownership, and trusts the inherent accountability booster of having engineers constantly pair programming.
A New Set of Estimation Cards
Inspired by other "non-numerical estimation cards", so gags and some for real, I have been working with the awesome engineers at CacheHeap, and we have created our own designs for planning poker estimation cards. Yes, these are really meant to be used for sprint planning!
Here's how it works: each person at the table gets three cards: a thumbs up, thumbs down, and question mark.
With only these three cards teams can quickly and efficiently add stories that all engineers confidently understand from their backlog to their active sprint (which may or may not be a formal change to the story). The key here is that the focus is on getting the engineers to make sure they understand the work that is coming next!
Assigning People To Stories? Not So Fast!
It may be tempting from a managerial overseer point of view to assign engineers to individual tasks right in the sprint planning meeting. While this can give engineers a heads up on what exactly he or she can expect to be working on, it's often inefficient- leaving engineers either with too much work piled on them without a pair or sitting with no story to pick up in the sprint. Instead, the woke XP practitioner will prefer to assign one story to one pair when they begin working for the day. One or more engineers can be rotated between pairs at any time. This ensures that no one will feel too burdened since 1) they have a pairing partner and 2) they can always rotate off if they feel they are not contributing. For extremely uninterested copy-and-paste types of work it can be ok to code alone once in a while, or a lone engineer can join an existing pair to turn pair programming into mob programming!
Are You As Woke As We Are? Let's Chat
While XP may not be the most popularly practiced method of software development, we woke practitioners certainly believe it is the best one! I love chatting with other engineers and people in the tech space so feel free to reach out. While I do actually believe the content here I did try to write it in a very over-the-top, click-baiting kind of way. If you are a passionate scrum advocate feel free to try to poke holes, troll me, and give me some creative criticism. I can handle it.
Where To Find Woke Folks
No no, this is not a sponsored post, but I would just like to shout out to a few excellent software consultancies in the NYC metro area and beyond who really understand XP and how to apply it well. Check out all of them if you are looking to bring in an engineer or product manager who can be a thought pioneer, instilling these values across the team, and transforming everyone in your organization into woke XP practitioners!