Archive for June, 2020
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!
Claudio Lassala's Blog 