Month: April 2019

Posted on

A list of STAR Interview Questions for Managers

  1. Tell me about a time you had to change your behavior to get things done in an organization or project.
  2. Can give you an example of a situation where you had to motivate your colleague(s) to get something done?
  3. Tell me about a time you had to be creative to solve an issue.
  4. Describe a situation where you preferred to delegate something back to your manager.
  5. Give an example of a project where the goals were not clear and describe how you handled the situation.
  6. Tell me what you did to become a better professional last year.
  7. Tell me about a time when you had to rely on written communication to get your ideas across to your team.
  8. Give an example of how you contributed to an improvement.
  9. Tell me about a situation where you used visuals to explain something complex.
  10. Share an example where you stole an idea and tweaked it become useful for you.
  11. Describe how you apply feedback cycles in your work, and how you shorten them.
  12. Tell me a situation where you were not motivated and how you handled the situation.
  13. Describe a situation in a team, where you as a team had to come to an agreement.
  14. Can you give an example where you had to act not in line with the company/team values?
  15. Describe a situation where you helped someone else to become a better professional.
  16. Tell me about a situation where you helped someone in your team or organization not related to your profession.
  17. Describe an experiment you did at work.
  18. Tell me about a situation where the purpose of the organization was not in line with you as a person.
  19. Give an example of how you made a difference in a meeting.
  20. Describe a situation where you contributed to strengthening the relations within a team.
  21. Describe a situation where you contributed to strengthening the relationships between teams.
  22. Tell me about when you gave a compliment to a team member.
  23. What have you done recently that helped someone be happier in his or her job?
  24. Tell me about the last time you provided feedback to team members.
  25. Give an example of a situation where did management activities.

These questions have been copied from this article: https://management30.com/practice/star-behavioral-interview-questions/

Posted on

What are the Values Anyway? The Mark Manson-Inspired Version.

Ask any Agile practitioner these days what Agile values are and he, most likely, will recite you some lines from the Manifesto for Agile Software Development. As him the final line of the said Manifesto and the result might be quite different, but I digress right in the first paragraph.

Ask a Scrum practitioner and he’ll give you 3-4, maybe 5, if he’s real good, values Scrum holds dear.

Next ask a different question, “What ARE the values? What are we talking about here?” And you’ll be lucky if you hear a half-baked off-the-cuff answer. Sometimes it’s just like, “well, values are values, those are what’s valuable.” Duh…

A quite interesting viewpoint and a crisp definition comes from Mark Manson’s “Subtle Art of not Giving a Fuck”. Yeah, ain’t gonna “star” the “u” there.

Read the complete blog post here: https://scrum.courses/2019/04/02/values-giving-f/

Posted on

Predicting The Weather: A Weather Forecast Retrospective for Scrum Teams

Using different formats for your Sprint Retrospective is a great way to help a Scrum Team inspect their process through different lenses and perspectives. The Liberators came across the Weather Forecast Retrospective by Barry Heins and shared their experience and (slightly modified) approach here: https://medium.com/the-liberators/predicting-the-weather-a-weather-forecast-retrospective-for-scrum-teams-9bbb02105ea4

Posted on

How can you liberate a meeting without using Liberating Structures?

There is enough LS which you can use to make your meeting productive. However, if you have the feeling that they are overused or you are bored with them, think about the five elements and create your structure.

  1. Structuring Invitation
  2. How Space Is Arranged and Materials Needed
  3. How Participation Is Distributed
  4. How Groups Are Configured
  5. The sequence of Steps and Time Allocation

An example of a retrospective with a new team:
Situation: we have a team of 10 colleagues. A developer and I had just started on the team.

STEP 1:
Ask the group to create two teams and give them the following assignment per team:

Team 1: take 10 minutes to think of all the reasons why this team is the worst team ever. after the 10 minutes, try to convince me that I have made a bad choice to join the team.

Team 2: take 10 minutes to think of all the reasons why this team is the most impressive team ever. After 10 minutes, try to convince me that I have made an excellent choice to join this team.

STEP 2:
After both presentations, give the next assignment:

Team 1: take 15 minutes to discuss within your team what actions can be made to keep the most positive things that team 2 had mentioned.

Team 2: Take 15 minutes to think of actions we can take to dismiss some of the reasons that team 1 had mentioned.

STEP 3:
After both presentations, ask each one in the group to think about the actions mentioned in Step 3 and take five minutes individually to find out how they can contribute to making those actions a success. You can also participate in this. We then share our contributions. Asked them to memorize their contributions, and get back to them in a few sprints.

The original post from Ziryan Salayi can be found here: https://www.linkedin.com/pulse/how-can-you-liberate-meeting-without-using-liberating-ziryan-salayi/

Posted on

Questions a New Scrum Master Should Ask Her Team to Get up to Speed

  1. How large is your product backlog?
    I do not believe in product backlogs that are larger than what the team can handle in three, maybe four sprints. If the product backlog exceeds this threshold, the product owner might be in need of some support.
  2. What is the typical age of a user story in the product backlog?
    Again, I do not believe in the value of a user story that is 5 months old. And a “but I have been working on it ever since” is an excuse in my eyes.
  3. What is your average lead time from an idea being added to the product backlog to its delivery?
    No one could answer that question in the before-mentioned session. But it is actually one of only three metrics that can provide some insight on whether “agile” has been successfully adopted by your organization.
  4. Does your product backlog contain user stories none of the current team members is familiar with?
    Maybe those should be re-estimated with the current team members to make sure the estimation is still accurate?
  5. How often are you grooming the product backlog?
    That should be done at least once a week depending on the state of the project.
  6. On how many user stories are you working in parallel during backlog grooming?
    Ideally, a team should not be working on more user stories than it can handle within the next two or three sprints. Otherwise, the risk of allocating resources on user stories that may never make into a sprint backlog becomes too high.
  7. How long does the grooming of a typical user story take?
    The grooming should not be taking more than one to two sprints.
  8. How are you creating user stories?
    (Is it a joint team effort with the PO or is the product owner writing the user stories and the team estimates them?)
    There is a tendency to observe that product owners become more a kind “technical writer” of user stories which then get estimated by the team. I suggest, however, to turn user story creation into a join effort of the whole team.
  9. Where are you discussing user stories?
    Only during grooming sessions or also on Slack or via comments on tickets, for example?
    Every team has it own habits, and maybe commenting in Confluence, Jira, Github or utilizing Slack is an effective means of communication in your organization. As long as this happens before a user story is selected for a sprint backlog, this should be fine. Discussing its essentials afterward is a problem, though.
  10. Do you apply a “definition of ready” standard to your user stories?
    That should indeed be a standard. A volatile velocity can at least partly be attributed to the lack thereof.
  11. If so, of what criteria is your “definition of ready” composed of?
    Typical criteria for a “definition of ready” are: The description is available, acceptance criteria are defined, the story can be delivered within a sprint, all UI deliverables are available, all (probable) dependencies are identified, performance criteria are defined, tracking criteria are defined and the story is estimated by the team.
  12. Who is writing acceptance criteria and in what format?
    It should be the product owner in collaboration with the team to create a shared understanding of what needs to be built.
  13. How are you estimating the likely effort of a user story?
    An estimation poker would be useful.
  14. Are you estimating in man-hours or story points?
    Estimating man-hours is betting than not estimating at all. However, I prefer user story points, particularly if the application in question is burdened with legacy code and/or technical debt. Predictability and stakeholder communications becomes easier this way as they are featured with a built-in buffer.
  15. How are you practicing the estimation process, if the team shares different opinions?
    Preferably, you should observe the team’s estimation process in real life. But in case you have to ask: is it a typical vote-discuss-revote cycle? Or: when and how do you pick an estimate? (Examples: 50:50 split, e.g. 3*3 and 3*5 – which one do you take? Or a majority split: 2*3 and 4*5. Or the estimations cover a range, e.g. from 2 to 8?) It is a good way to learn more about the team building state, too.
  16. What is a typical distribution of story sizes in your sprint backlogs?
    This one tries to figure out, where the commitment sweet spot of the team is, based on the sprint backlog composition. To my observation, teams often work in a more successful way, when a sprint backlog comprises of one or two larger user stories, some medium sized stories and a few small ones.
  17. Are you re-estimating user stories at the end of a sprint? If so, under which circumstances are you doing so?
    That should always be done if a user stories turns out to be way off its original estimation.
  18. What was your velocity of the last three sprints?
    The team should know its velocity, how could it otherwise possibly improve?
  19. How many user stories are typically not finished within a sprint and for what reasons?
    If the team is bullish and picked more user stories than it could probably handled at the beginning of the sprint, so be it—nothing to worry about. Also, there are other incidents that might negatively effect the team’s actual velocity, e.g. sick leave or a critical bug a few days into the sprint. If the team, however, is regularly leaving user stories on the board because estimations were wrong, this is a sign for concern. See also: Scrum: The Obsession With Commitment Matching Velocity.
  20. Are you changing user stories once they become an item of a sprint backlog? And if so, under what circumstances?
    Well, making them smaller if the team runs into a problem is certainly not great, but acceptable—if the user story in its reduced form still delivers value. Making it larger after the sprint planning is, however, not acceptable.
  21. What are the obstacles the team is facing today?
  22. What are the dependencies on other teams?
    And if there are dependencies, are you waiting for other teams to complete their tasks?
  23. Define and discuss at least three key team goals for the project.
    Some of the answers may seem obvious, i.e. meet our deadline within our budget, but this discussion can often bring out other goals which are not obvious to the Team initially. It can help the Scrum Master understand Team motivations and dynamics.
  24. What are key success factors to achieve our team goals?
    Defining and discussing key success factors, i.e. minimizing the impact of dependencies, can help identify project-level impediments, risks, and issues which the Scrum Master can begin to address. It also is a good benchmark to review and update as the project progresses.
  25. What do team members hope to achieve with this project?
    I like to get a sense of people’s personal goals for the project in addition to the Team goals we will establish collaboratively. Having this information can help keep people motivated over the course of the project. Some people may want to learn new technologies, be part of a high-performance Agile Team, or have other goals.
  26. What type of work environment do we want to create on this project?
    This question can stimulate good discussion about how Team Members want to interact with each other to achieve the project goals. Often the discussion centers on trust, communication, collaboration, and respect, but it’s good to make sure there is some agreement (or an acceptance of differences) by the team about what is important.
  27. What can we do as a team to make sure that we support each other to achieve our team goals?
    This question can help the Scrum master understand how team members understand the importance of making commitments as a team rather than as individuals. It can also help the team establish informal agreements about the need for everyone to support each other, to take on roles outside their specialty, and trust their team when they need to ask for help.
  28. What should we do when we are not achieving our goals or not supporting each other?
    Obviously, this can be addressed in a retrospective, but having the discussion early can be helpful to understand how team members perceive how these situations should be handled. It can help establish the need for open and honest communication built on trust.
  29. How should we celebrate success for achieving our goals?
    It’s important for the team to visualize and expect success. This discussion can help the team discuss rewards that are meaningful and keep them focused on realizing those rewards.

Original post can be found here: https://age-of-product.com/20-questions-a-new-scrum-master-should-ask-her-team-to-get-up-to-speed/

Other questions you might want to ask when joining a start-up are:

  1. Why are you hiring a scrum master and not a project manager?
  2. What is the leadership style of the startup founders?
  3. What is your current software development process?
  4. Do employees get any regular feedback?
  5. How would you define your company culture?

As listed in this article: https://www.toptal.com/project-managers/scrum-master/5-scrum-master-questions

Posted on

Build-your-own Sprint Planning Canvas!

You know, the Business Model Canvas, the Empathy Map, the Product Canvas: They all have one thing in common: Stacking up all the useful questions into one piece of paper, printable starting at A3 (or larger). Guiding the users through the nescesarry steps towards Awesomeness. (To be honest, if I would have had this brainwave before we started the meeting, it probably would have been a lot more easy to go through the process.)

So here it is, the current version of our Sprint Planning Canvas. As a team, we are still tweaking it to ask us all the right questions we need, so this is only the 0.3 version… But it’s good enough to give you an impression.

Find the complete post here: https://www.linkedin.com/pulse/build-your-own-sprint-planning-canvas-something-inspire-jaap-mintjes/

Posted on

Why the Sprint Goal is not an Essential (Mandatory) Artifact

Although, the Sprint Goal is not defined as an artefact within the Scrum Guide it is an integral part of the Scrum framework. It provides an overarching objective for the Scrum Team which helps them to focus “WHY” is the team invested in the Sprint.

Why do we choose to conduct this Sprint? What is the value we seek to create? Why did we select these items from the Product Backlog and not others? How will we know whether the Sprint was successful in the Sprint Review? Those are the questions we seek to answer with the Sprint Goal and if we have no clarity on those aspects of Product Development then we are missing a key element of Empiricism, and missing a key Inspect & Adapt opportunity in Scrum.

Read the complete article here: https://www.scrum.org/resources/blog/why-sprint-goal-not-essential-mandatory-artifact

Posted on

The many roles of a Scrum Master

Many of you know Barry Overeem’s 8 stances of a Scrum Master. They are brilliant, but they only touch the surface of what a Scrum Master is expected to do.

After an initial brainstorm – with contributions from many community members at Serious Scrum – we identified more than 50 different roles that a Scrum Master might play.

Read the complete article here: https://medium.com/serious-scrum/the-many-roles-of-a-scrum-master-7b7f62742198