Posts Tagged scrum
“Any tips for getting your Scrum team on board with practicing TDD as a team?”
- It starts with the individual
- Lunch and Learns
- Try it with one small story
- Code Review
- Ping-Pong Pair Programming
- Divide and Conquer
- Book Clubs
Expanding each of those points…
It starts with the individual
A few common situations that prevent teams from adopting TDD include:
- Can’t make time in current project
- Legacy system that makes it very hard to practice TDD
- Team members not willing to try it
- Lack of support from the business
Those situations should NOT prevent an individual to do it.
Practice TDD on your own time so you can build your skills.
If others see you do it, they may join you. If they do, great. If they don’t, you are still growing.
Lunch and Learn
If you decide to take it on your own, offer lunch and learn sessions for your team to share your experiences, struggles, successes.
The purpose is not to wait until you become an expert; share it as you learn.
Make it a recurring meeting.
Write down ahead of time the things you’d like to share (including how and why you failed, and how you’ve overcome it – or not!).
People aren’t showing up or look uninterested? Consider putting it out as blog posts. Why? There are always people out there who will relate to your struggles and successes.
Try it with one small story
Pick one small story, or a small piece of a story, and commit to doing TDD.
You may fail (many times). You may succeed. Either way, share your findings with the team:
- was it taking too long?
- Lack of knowledge? Practice?
- Difficulties with the legacy code?
- What kind of difficulties?
- Too many dependencies?
Work as a team to figure out how the hurdles could be overcome.
Your weaknesses might be someone else’s strengths. And vice-versa.
Share the experience at the sprint retrospective. Figure out the next step and commit to it.
When doing code review, start by reviewing tests/specs.
When writing tests first, consider asking for a code review before implementing it, to make sure you have a good understanding of the problem that needs solving.
During that review, share any difficulties you see. The reviewer might know how to help you. And if not, you may find a clear path ahead of you just by articulating your thoughts and sharing it with someone else.
After done with the implementation, ask for another code review. This time, maybe share how you’ve addressed the difficulties. Also, maybe discuss ways how the test code could be improved.
Ping-Pong Pair Programming
Consider ping-pong pair programming: one person writes a test, the other one writes the implementation. Then swap.
Set a time-box. Do not let interruptions get in the way.
Let others know what the pair is up to so they can help avoid interruptions during the time-box.
Share the lessons learned with the team.
Divide and Conquer
Work as a team.
Divide the challenges so that each team member can focus on learning one thing, and then share the findings with the team.
Here are some ideas on what to learn:
- Test frameworks for the tech stack
- Testing legacy code
- Tools such as Cypress.io, Cucumber, SpecFlow, Selenium, etc.
- How to test code that makes heavy use of libraries or frameworks such as Angular, React, Mass Transit, etc.
- How to write better specifications in Given-When-Then
Run book clubs!
Build knowledge and skill together as a team.
Choose a book that seems to fit the team’s current skills, set a cadence (maybe once a week during lunch breaks?), start reading, and discuss the findings together.
Here are a few books you may want to consider: Recommended Reading on Testing
I have used all of these techniques. Still do.
I pick and choose whichever one works better depending on my current situation. Sometimes the one I pick doesn’t work on a given team. I drop it, and try another one.
Whether the team thinks of TDD as Test Driven Development or Design and whether they use the terms test or spec, that depends on the team’s maturity. Different people, different backgrounds, different ways to learn.
It all starts with one person. Do not wait for that person. Be that person.
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!!