Virtual Brown Bag: June 2020 Summary
Posted by claudiolassala in Virtual Brown Bag on July 2, 2020
June was another month filled with Virtual Brown Bag meetings every Thursday. Lots of great discussions on a variety of topics. Here’s a summary and links to the videos. Enjoy!
June 4:
We talked about a bunch of stuff this week! Books, Connecting, F# Conf, WebForm/WinForm, Android crash, Racket, FizzBuzz, The QA’s Role in a Scrum Team. George brought up discussion on resumes and interviews It sparked many comments. We’ll bring it back next week. We have even mentioned FoxPro. 🙂
June 11:
Great chat about resumes! We’ve lost the 2nd half of the discussion due to technical issues, but still, there’s good content in here.
June 18:
We’ve continued our conversation from last week, talked a little more about resumes, and also job interviews, developer challenges, etc.
June 25:
We talked about upcoming free virtual events, Claudio’s “Trusting IT” call for feedback, the “Badass – Making Users Awesome” book, George’s code challenges, using generators, threading/pipeline operator, and the Rocketbook.
Can you help me with “Trusting IT”?
Posted by claudiolassala in Software Development on June 25, 2020
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.
Virtual Lunch and Learn this week: Testing in Agile
Posted by claudiolassala in Presentations, Software Development, testing on June 22, 2020
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 .
Remembering People’s Names
Posted by claudiolassala in lifestyle on June 15, 2020
I have always been bad and remembering people’s name, and that has always bothered me, so I try whatever tricks I learn to fix that. Here are two that have been helping me a lot!
In training, meetings, or similar situations
In the past, there have been situations where I was teaching a multi-day class, and I’d get to the end of it not remembering all of the attendees names. Shame. That was until I’ve picked up this trick from a friend of mine when I sat at one of his classes:
When we’re going around the room doing introductions, I write down people’s names based on where they’re seated. As they talk about themselves (usually answering starter questions, such as “what’s your role, what’s your current skill level, what are your expectations for this class, etc.”), I jot down quick notes close to their names. During the day, before directing a question or an answer at any of the attendees, I look down at my notes and make sure to say their names out loud.
Most people have a tendency to always sit at the very same spot every day, which certainly helps with this practice!
In other types of group gatherings
I’m into Motorcycle Riding. More specifically, riding at the race track. I get to meet a lot of riders at the track, and it can get pretty hard for me to remember everyone’s names. It bugs me remembering people by “the tall dude on the red yamaha” or “the fast guy who cut me off going into Turn 1”.
In order to address that, I’ve added a very simple feature to my Beyond the Track website: as part of the “track day debrief” feature, I’ve included a “People I’ve met” area. This is a free-text field where I jot down people’s names, the bike they ride, the color of their leathers and/or helmets, and any other information I’ve learned about the person (what city they live in, how long they’ve been riding, what kind of work they do, other areas of interest, etc.).
Sometimes, I go months without seeing a person at the track again, but when I do see them, I happen to remember at which track we’ve met for the 1st time, so I can easily find my notes on that person and pick up the conversation where we’ve left off last time.
The most supporting user of my website has thanked me multiple times for this simple feature.
For other types of group gatherings, I’ve been following this same approach, where I take some quick notes about people. I review the notes later in the day and add more to it in order to facilitate recalling these notes at a later time.
Do you have any special tricks you use to remember people’s names and other things about them?
Show me your Spreadsheets!
Posted by claudiolassala in Software Development on June 12, 2020
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!
Answering questions from my Scrum talk
Posted by claudiolassala in Software Development on June 5, 2020
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.
Wrapping up
I saw the tweet below early this morning. What a great way to start off my day!!
The QA’s Role in a Scrum Team
Posted by claudiolassala in testing on June 3, 2020
I remember years ago a person saying that “a QA’s job is to find bugs in the programmer’s code”. I’ve actually heard that from quite a number of people, as early as last year. I remember companies rewarding QA employees based on the number of bugs they find. I believe it’s kind of hard to keep a good relationship between QA and programmers in such environments.
In Scrum, both programmers and QA are developers, because…
- They both run the software and click around to make sure make sure it works. They test it.
- Programmers automate their tests. They write tests.
- QA automate their tests. They write tests.
The nature of the tests they write are different. The programming languages they write are likely different. But they are both contributing to the product’s development. That’s why they’re both called developers.
Yes, each one leans towards different areas of software development, but they’re not working against each other. They’re collaborating. Any and all efforts going towards improving such collaboration should be potentialized. Just a few ideas:
- If programmers are done implementing code, they can offer help with the QA efforts (testing features implemented by other programmers, writing automated tests, writing scripts that can speed up the testing process, etc.);
- If a QA personnel are done testing what’s available, they can offer help clarifying acceptance criteria to the programmers, they can help programmers write the specs for their tests (given-when-then!);
These are just a few thoughts that I’ve been sharing at my “Testing in Agile” talk, which comes from putting that approach into practice with teams I work with.
If you’d like to get more insight into this kind of approach, please check out this great video my friend Daniel posted recently.
Virtual Brown Bag: May 2020 Summary
Posted by claudiolassala in Virtual Brown Bag on June 1, 2020
Lots of goodies shared at the Virtual Brown Bag during the month of May. Here’s a summary (with links to the videos):
May 7: Talks on managing interruptions, Pomodoro Technique, finding opportunities and leveraging them, trust in IT, importance of tests, and a couple more miscellaneous things!
May 14: We talked about Udi Dahan’s Advanced Distributed Systems Design course, C#’s new feature: source generators, Security standards and considerations, Node and NPM, Tribes of Programmers, and some miscellaneous things, as usual
May 21: Arrange-Act-Assert, Given-When-Then, When-When-Then, Refining user stories, Righting Software (book), Architectural book, Software Architecture youtube channel, Google.dev, Azure App Service Static Apps with Svelte + Sapper, Top-Level Programs in C#9
May 28: George’s “challenges”: https://github.com/togakangaroo/daily, https://orgmode.org/, emacs, Org Babel
Looking forward to seeing what April brings us!
Questions to the Scrum adopters
Posted by claudiolassala in lifestyle on May 29, 2020
Here’s a set of questions I’d like to ask every Scrum adapter out there (myself included). Think of how you live your life:
- Do you create a backlog?
- Do you refine it?
- Do you prioritize it?
- Do you plan what you’ll do and how you’ll do it?
- Do you check on a daily basis how things are going?
- Do you review your results?
- Do you look at it retrospectively to see how you can do better?
Answering no to any of the questions above should prompt us to reflect on how can we recommend Agile/Scrum to others, then?
We need to figure out what’s important to our own life, figure out what is valuable to us, where we want to get to, and then set up a backlog. Then we should refine it, by adding more information to it, making it clear to ourselves why those things are of value to us. Armed with information, we can then prioritize it.
With a prioritized backlog in place, we can plan on what we’ll do and how we’ll do it.
Now that we’re doing it, we should check on a daily basis how things are going.
At the end of the day, week, month, year, we should review our results.
Finally, we should look at our results in retrospective and make corrections as needed.
If that’s what we decided to do for work, it should also be what we decide to do for life.
If you need some ideas on how to do that, here you go:
* Organizing my daily, weekly, monthly, quarterly, yearly plans
* Planning and reviewing my day
* My annual reviews
* Bonus: there are several more related posts under the Lifestyle category of my blog
Why are you Writing Tests?!
Posted by claudiolassala in Software Development, testing on May 28, 2020
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
And also…
“People don’t buy what you do, they buy why you do it.” – Simon Sinek
