Archive for category Software Development
Notice the title doesn’t say Scrum “Software” Projects, because I believe Scrum can be applied to many different types of projects. Having music and motorcycle riding as the other passions of mine, I find myself drawing comparisons and reapplying learnings where I see fit.
In a talk about building trust through delivering results in Scrum software projects, analogies with hitting the apex at a race track have come up, and I felt I had to expand on that idea. So for this post, I’ll consider a software project, but again, the ideas can be applied to many types of scrum projects.
I’ve only started learning about apices and race lines when I started riding a motorcycle at a race track in 2017, so my comparisons here come from my understanding on the subject as of November of 2020. As I learn more, I may need to update this post in the future.
If you’re a fan of races (motorcycles or cars, it doesn’t matter), you are most likely aware that racers know how to hit an apex consistently and why they should hit them.
Consistency is key; hitting the apex consistently, lap after lap is extremely important. Hitting the top speed on a straightway isn’t as important as hitting consistently high average speeds, which yield fast lap times.
Reaching 200mph on the straight and then running off track isn’t the most efficient way to turn fast laps (not to mention you might crash when you run off). Working crazy hours during a Sprint to deliver a high number of story points isn’t an effective way to turn good quality software and keep doing it lap after lap; I mean, sprint after sprint (not to mention you may crash; I mean, get burned out).
The apex is typically the slowest part of a corner. The soonest you can get to WOT (wide open throttle, which means you’re using the vehicle’s fullest acceleration potential), the faster you can get to the next corner. But then, you also need to know that you will have to slow down in order to make that next corner. If you’re looking down to the speedometer to keep marvelling at how fast you’re going, chances are that you will be running off track. If we keep solely looking at number of story points, we may lose track of where we’re going.
In order to find the proper race line, with the respective apex for each turn, we need to analyze each turn backwards. We need to know what comes after each turn to be able to plan a strategy for getting in and out of the corner as fast as possible; if turn 2 is a slow hairpin, then we may never get to WOT coming out of turn 1. If turn 4 preceeds a long straightway, then we need to make sure we exit that corner as fast as we can, getting to WOT as soon as possible.
However, opening the throttle too soon, may cause us to run wide, creating a need to slow down, before accelerating to the full potential (a process that causes loss of precious time).
In a motorcycle, if we open the throttle too much too soon, it may cause loss of traction. Depending on how we handle the situation, when the bike regains traction, it may send us on a trip to the moon and back. Not pretty. How do I see that in a scrum project? Maybe we’re forcing performance optimizations when it’s not the right moment?
Back to planning the corner backwards: we need to see what’s coming. We need to have a vision. We plan for it. Then we execute it (by riding laps). As we do, we look ahead, through the corner.
We may misjudge how much speed we can take into a corner and brake too much. Next time around, we brake a little less.
We may not have good reference points (brake points, turn in points, apex, exit points) around the track to help us assess our speed and strategies. On every lap, we stay aware of those things, so we can fix it next time. Remember sprint retrospective meetings?
Such approach can only work if we are not going recklessly around the track. If we’re riding without control, we will not be able to evaluate our execution; we won’t learn anything from it. So we can’t improve it. We can’t come up with better strategies.
Only hitting the apex isn’t enough. Racers have different strategies for hitting the apex. If they’re trying to make a pass, they may decide to take an early apex, so they can carry more speed into the corner, hopefully passing the other rider, but at the expense of coming out ot the corner slower.
On the hand, if they’re trying to turn consistently fast laps, they may take a late apex, where they carry less spead into the corner, but are better placed to accelerate harder out of it.
See the riders in the photo below: some are trying to pass, some are planning to pass, some are trying to avoid being passed. Their plan to hit the apex varies based on their desired next result (turn a faster lap to stay ahead of the others, get closer to the rider in front and set up for a pass, etc.)
Each lap is a sprint. One fast lap does not guarantee a race win.
Each race is a release. One race win doesn’t guarantee a championship win.
Consistency is key.
Vision, plans, execution, evaluation, tweaks, repetition, strategies, using them accordingly, focus, flow. Wait, am I describe racing or a scrum project?
Image source: Pixabay
Tomorrow, August 12th, I’m giving a free Virtual Lunch and Learn on one of my favorite topics! You can sign up here.
Code Review: I Mean No Harm!
As part of the work I’ve been doing for many years, I get to do a lot of code review. I usually document things that come up doing a code review so I can share it with other developers in the teams. In this session, I share some of the code I’ve looked at, the reasons why the code raised yellow or red flags in my head, and some possible solutions I’ve proposed.
In May, I’ve given my new talk “Trusting IT: Bridging the gap between Vision and Execution” (you can watch the video at the bottom of this post). I’m now in the process of refining and expanding that content and would love to get feedback from the community.
I’m gathering volunteers to attend a 1-hour onlne session, in which I’ll ask a couple of questions to the participants and gather their feedback. Who am I looking for? IT Professionals, including (but not limited to) software developers, QA, Scrum Masters, and those who work closely to them, such as UX designers and Business Analysts.
If you’d like to participate, fill out this form (email and name), and I’ll send you a link to a survery to help me determine the best date and time to accomodate the volunteers’ availability.
No preparation needed, just show up on time for the session. I’m planning to have it between July 1st and 15th.
I’m giving a Virtual Lunch and Learn talk this Friday, June 26, at 12pm Central Time. You may register here!
This has been my favorite talk for the last three years or so. I’m going through the content and updating it to reflect feedback I got during this time. I hope to see some of you there!
Testing in Agile: from Afterthought to an Integral Part
Many who try to start automating tests end up giving up the practice. Those tests seem really helpful at the beginning, but are abandoned over time. Even the practice of Test-Driven Development (TDD) faces similar issues, with many giving it up.
How do long-time practitioners do it? Or, perhaps more importantly, why do they do it?
Let me share my experiences in this area, starting with unit tests way back in 2004, navigating through lessons learned the hard way, and ending with my current approach to automated tests, code coverage, TDD/BDD, and how I use those techniques to bring together developers, QA, UX, Product Owners, and Business Analysts .
Have you ever seen any business that doesn’t make heavy use of spreadsheets? Right, me neither.
Here’s a technique I often use when working with a new client: I ask them “Show me your Spreadsheets!”
A lot of decision makers base their decisions off this or that spreadsheet. Even when there’s a costly ERP system involved, they normally use the “Export to Excel” feature, and then play with the data to find the answers to the questions they have.
Those questions they’re asking are often the most important part in their decision-making process. I want to know:
- What are those questions?
- Why are they important?
- Does the person have to enter additional data on the spreadsheet? if so, why is it not already captured in the system?
There are also cases where users export some data out to Excel and email the results out to somebody. I ask the users why they need to send that data and how it’s used. If they don’t know, I’ll go ask the recipient, which then may take me to the questions listed above.
This type of conversation of the clients, end users, businesses, help quite a bit in identifying the real business needs and them providing them the best solution (which could be a matter of addressing a workflow, coming up with a process, creating new software or changing existing ones, or a combination of those elements).
So, the next time you’re working with a client, give it a go: show me your spreadsheets!
I’ve had a great time giving my “Beyond the Daily Stand-up: An Intro to Scrum” talk at the Virtual Agile Shift yesterday (check out the conference: it’s going through the end of the month!).
There were great questions asked, some of which I was able to answer at the end of the talk, and some that I couldn’t answer as I ran out of time, but promised I’d post the answers to my blog. Hence this post!
Some of the questions make me want to write a full blog post for each, but in order to keep my commitment to answering them today, I’ll give the short answers now, but I’m saving the questions for future, longer posts.
Here we go!
What are your thoughts on Unified Engineering?
I had not heard of “Unified Engineering” before. When I first saw the question I thought it could be one of those things I knew about, but I just didn’t know that’s what it was called. That turned out to be the case.
A web search didn’t yield many results, but I’ve found this podcast from 2016 that had some references to it. Fortunately, there’s a transcript there and I was able to skim it to get a gist of it. If I haven’t misread it, my blog post from the day before my talk was exactly about that (The QA’Role in a Scrum Team), so those are my thoughts on it. 🙂
What should the Burndown be based on? Story Points? A count of stories? or is it based on hours assigned to tasks?
The Burndown represents the Sprint and it tracks the work to be done within the Sprint. That work is represented by the Sprint Backlog Items (the “tasks”), which are the way the team found to implement the user stories.
It’s very common for Scrum Teams to size those tasks in terms of hours, in which case, the number of hours is used when updating the Burndown chart. I’ve also worked on teams where we’ve decided to only track the number of tasks, instead.
The team decides what works best and has the autonomy to change the approach from one Sprint to the other, based on what the team believes the best approach is.
Is there a formula to calculate the velocity of the team?
It’s very common to calculate velocity based on the average of story points (if that’s how the user stories are sized) delivered by the team in the last 3 Sprints. We average it like that in order to account for fluctuations from Sprint to Sprint. For example, in one Sprint the team may deliver 60 story points, and then 50 on the next one. Why the drop? It could be because a team member was off sick for two days.
Also, as the team matures, the velocity tends to go up. Whenever the team formation changes (for example, a team member leaves and a new one joins in), the velocity tends to drop for a couple of Sprints. Averaging the last three Sprints help manage these fluctuations.
Who amongst the Scrum Team should take down notes for the feedback provided by the stakeholders during the Sprint Review (Demo)
That would normally be either the Product Owner or the Scrum Master, but I always encourage the other members of the development team to also take down notes where they see fit. They may see things that maybe neither the PO nor the SM picked up. It’s a group effort.
Where do Developers document what was coded?
Different people, teams, organizations do it in different ways. My personal favorite approach is a combination of things:
- Write good specs (aka “tests”). I believe there’s a good example at the bottom of this post. I also have a whole set of posts around testing;
- Add good comments to the Pull Request, referring back to the user story it implements. Include a link back to the user story in the tracking system used (Pivotal Tracker, Team System, Jira, etc…);
- Add a link to the Pull Request in the user story on the tracking system.
With such approach, we can learn about things both ways: we may come to the user story to find out what code changes (pull requests) were made to implement the story, or maybe looking at the code changes (pull requests) and figure out what they were made (link back to user stories).
How should the information gathered from a 1/1 conversation between Dev and Business be shared with the entire team?
It would depend on the nature and outcome of the conversation. Here are some ways that could go:
- If a new acceptance criteria has been come up, update the specs/tests;
- If a user story has been clarified, update the user story on the track system to reflect that clarification (maybe a change in the wording?);
- Bring it up at the daily scrum to share it with the team;
- If a more in-depth discussion with the team is needed, book a meeting and share the information there;
- Add comments to the user story in the tracking system;
- Drop a note into whatever messaging system the team uses (Slacks, MS-Teams, email, etc.)
- All of the above?
Pick the ones that work for the team and the business.
Are there agreed-upon roles and responsibilities for the various players? Ambiguity makes it more challenging – especially if Agile is new to the org
The Scrum Framework lists the three roles: Product Owner, Scrum Master, Developers. Within developers, it’s up to the team to define the roles. A development team may start with a hard separation between QA and coder, for example, the QA person tests the work produced by the coder.
As the team matures its collaboration skills, the coder may start helping QA, by teaching them how to write automated tests, while QA may start helping the coders by helping them understand the acceptance criteria better.
The roles and responsibilities within the team may change as per the team’s needs and how it grows in maturity over time.
If the user stories are not completed till we release to production then the burndown will not go down till release is done typically at/after the end of the sprint
This question touches on the Definition of Done (DoD). The idea is to have potentially releasable increments at the end of the Sprint. If the DoD for user stories at the end of the Sprint includes something like “feature deployed to production” and that item hasn’t been checked off, then yes, this story rolls over into the next Sprint. If the team tracks tasks by hours, then the hours associated with deploying to production rolls over to the Burndown for next Sprint.
On the other hand, “deploying to production” may be part of DoD for release. Depending on how the business does things, a release may only happen after a number of Sprints, with an aggregate of features built during those Sprints, so at that point, the release’s DoD should include the “deployed to production” check.
I saw the tweet below early this morning. What a great way to start off my day!!
I don’t think I’ve ever met a developer who hasn’t had to answer this question: “Why are you writing tests?!”. Some have given up the practice because they grew tired of that, others have moved on to places where they don’t have to fight this uphill battle. Fortunately, we also have developers such as my fellow Improver Harold, who believes in and follows the practice, and can articulate explaining many of the reasons why we test from a developer’s point-of-view.
I have heard many reasons why tests are NOT written and I plan on writing individual posts to tackle those at a later time. For this post, I’d like to offer you my thoughts and answer to the initial question.
Such as with most developers, my answer used to be along the lines of “I write tests to make sure my code works!”. That answer evolved into incorporating “…and it also allows me to refactor my code. Look at how clean my code looks now!”.
However, bugs would still show up with my fully-tested code. Other developers would also have trouble working on fixing it because they couldn’t understand my tests.
After several years of that, I started seeing why it was so hard to get people’s buy-in on testing. Did you notice the word I had bolded on the previous paragraphs? Yup, “my”. I was making it all about me.
Many people use the following analogy to justify writing tests: “Doctors scrub their hands before working with a patient, because that’s the right thing to do!”, or something along those lines.
Do the doctors do it for themselves? Nope.
So the short answer to our initial question here (“Why are you writing tests?”) should be: I am doing that for you!
Or, a slightly longer elaboration:
I am doing it to make sure what we are building reflects the needs of the business as we understand it now.
This inversion in the motivation changes the dynamics of the relationship considerably; if our practices bring value to others, we’re way more likely to get their buy-in.
This realization didn’t come to me overnight. As I check out my posts on testing, I realize the first one dates back to 2008 and in it I say it was 2003 when I first heard of unit tests. Maybe my motivation shifted when I went from Arrange-Act-Assert to Given-When-Then. From that, the next step had to be the “No GWT? No code!” approach.
To wrap up this post, I’ll drop the quote I have on my business card:
“What you do matters, but WHY you do it matters much more.” – unknown
“People don’t buy what you do, they buy why you do it.” – Simon Sinek
We normally hear that we should only be writing tests for our code, not someone else’s (external libraries or APIs). For example, if we are writing tests for code that calls out to an API, the test should mock the dependency on the API and only verify that the calls are made as expected and that the results are handled as expected. The test should NOT verify that the API produces the appropriate results for the given the input; that would be testing someone else’s code.
I agree with all of that; for unit tests.
However, I’d still consider writing integration tests against that API, NOT to test someone else’s code, but to document our assumptions about the API.
Why? Because our code relies on those assumptions. That’s a dependency.
What happens if the API implementors decide to make changes that break our assumptions? Without integration tests validating those assumptions, all our unit tests would still pass, but we could end up with either defects or inaccurate results in production (which could go unnoticed for a long time).
Another added benefit from the practice of writing such tests is that, should a new version of the API come out, evaluating risk levels of consuming the new version becomes much simpler: just run the tests against the new version.
Last but not least, say an API offers a large variety of features that could be used; having tests that describe how we use that API makes it much easier for developers to learn the details of how we depend on it. Such understanding, again, helps with both assessing risks when consuming different versions of the API, as well as assessing a potential replacement of the API.
Dependency management is very important!
Several people talk about how having multiple screens makes us more productive. But does it, really?
It’s not the number of screens that matters; it’s how you use them!
Let’s take my current setup as an example:
Those three active screens are the ones I use when doing most of my focused work. Let’s say this is how I use those screens:
Hey, we can see a Pomodoro Timer at the top-left on that picture, so this MUST be a very productive setup, right? I’m afraid not. Consider my current focus is software development work. Let me walk you through the points I’m indicating on the picture:
1. Dead space. Unused real estate. If I’m on my focused time, I should probably not be seeing my exciting track photos, which change every 20 minutes; maybe a solid color would help keep my focus;
2. An email client. My current focus is NOT “email processing”, I shouldn’t keep the distracting email client open like that;
3. A messaging app taking up an entire monitor. Does that conversation pertain to the current task I’m focusing on? If not, then this app should not be there;
4. That is the browser window showing me the software I’m building. That’s the result of my focused work. It can benefit from a little more real estate, no? To add insult to the injury, maybe I’d even have the developer tools open, all squished, docked inside that same window!
5. The IDE. The thing where I produce the result of my current task. The code I’m working on cannot be seen without scrolling horizontally!
So, do the multiple screens make me more productive if used that way? Most certainly not.
Here’s a better setup I believe makes me more productive:
Let me walk you through it:
1. My Pomodoro Timer. Time-boxed task. The time I have left helps me stay focused;
2. A place to drop in notes, screenshots, links, etc., related to the task I’m working on;
3. Any research or supporting material I’m currently using. In that browser window, I make sure to only have tabs related to the task at hand;
4. My IDE. That’s the screen I’m looking at most of the time, so it has to feel comfortable, relaxing, easy on the eyes (not a lot of information or things other than the current code I’m working on);
5. The software that I’m building, which is the result of the code in #4;
6. The Developer Tools (console, debugger, etc.);
7. The terminal (console) window, so I can quickly see if my current changes have broken my local build (also supported by what I may see on #6).
As it has been document on the internets since 2007, I am very specific about how I organize windows and multiple screens. I organize them based on the focused task at hand and I’m always looking for A) better ways to organize it, B) processes and tools to make it easier.
I’ve just heard about the FancyZones in the Windows 10 Power Toys this morning, and I’ll be looking into adding that to my toolbox as well.
You’ve read it right. I have worked with teams that initially said things like “Yeah, we have daily stand-up every other day!”, or “Yeah, we do Sprint Planning, but we don’t to Sprint Retrospective…”.
In order to help out those teams get their mind around Scrum and improve their adoption, I decided to create a talk a few years ago called “Beyond the Daily Stand-up: An Intro to Scrum”. I’ll be giving this talk as a free event on June 4, 3:30-4:30pm, as part of the Virtual Agile Shift.
That’s right, the conference had to be postponed due to the current pandemic, but it’ll still happen as a virtual conference, with daily talks, Monday through Thursday, during the month of June.
Check out the schedule, figure out what sessions you’ll attend, and sign up!