Two action items from my retrospective today) And how cool to come home today to this video. I'm going to use the "continue list" idea, and add one item to it at my next retrospective
we had this continue list and we decided to get rid of it, after almost 1 year I'll suggest using it again, as a reminder of the good practices to follow.
Hi Mike! Thanks for the video. I don't know if you have a specific video on this topic, but I would like to know some tips for a team starting on a new project and using agile for the first time. Let's say, for example, a small team with one developer, one project management, one business analyst and few stakeholders. How should they start? This is my case right now. We are starting to create a system for managing work with legal documents creation, digital signature of files, collaborative work and integration with other existing systems. We started with the business analyst (my role) creating prototypes in Figma and having online meetings attended by the stakeholders, the project manager and the business analyst. But we're not sure when the developer should start working in the project and what should be our next steps or if we have missed a mandatory step. Do you have some tips? Thanks a lot!
Hi Gil, I don't have any specific videos on getting started yet but will add that to my _video backlog_ . To give some guidance here, though, the dev should start asap. I would have literally had the developer working either the same day as the first meetings with stakeholders or within a few days at most. Instead of prototypes in Figma, talk together about what is needed and have the dev start. If the dev isn't getting a picture of what's needed for a specific feature, mock it up with paper or use Figma then. The big key here is to try to overlap work as much as possible. If too much is up in the air at the start, OK, go a week without the dev. But at that point, the dev can start setting up the basic parts of the system (logging in, error handling,, the basic database, or whatever is clearly needed).
Two action items from my retrospective today) And how cool to come home today to this video. I'm going to use the "continue list" idea, and add one item to it at my next retrospective
Fantastic. And I'm glad you had a retrospective today.
We usually pick top 2-3,but the continue list seems like a great way to see how far along the improvement continued after identifying them.
I hope it helps your team!
we had this continue list and we decided to get rid of it, after almost 1 year I'll suggest using it again, as a reminder of the good practices to follow.
That's great. I hope it's helpful.
Hi Mike! Thanks for the video.
I don't know if you have a specific video on this topic, but I would like to know some tips for a team starting on a new project and using agile for the first time.
Let's say, for example, a small team with one developer, one project management, one business analyst and few stakeholders. How should they start?
This is my case right now. We are starting to create a system for managing work with legal documents creation, digital signature of files, collaborative work and integration with other existing systems.
We started with the business analyst (my role) creating prototypes in Figma and having online meetings attended by the stakeholders, the project manager and the business analyst.
But we're not sure when the developer should start working in the project and what should be our next steps or if we have missed a mandatory step. Do you have some tips?
Thanks a lot!
Hi Gil, I don't have any specific videos on getting started yet but will add that to my _video backlog_ . To give some guidance here, though, the dev should start asap. I would have literally had the developer working either the same day as the first meetings with stakeholders or within a few days at most.
Instead of prototypes in Figma, talk together about what is needed and have the dev start. If the dev isn't getting a picture of what's needed for a specific feature, mock it up with paper or use Figma then.
The big key here is to try to overlap work as much as possible. If too much is up in the air at the start, OK, go a week without the dev. But at that point, the dev can start setting up the basic parts of the system (logging in, error handling,, the basic database, or whatever is clearly needed).
@@MountainGoatSoftware Thank you so much for your response and advice, Mike!