This is a summary of some of the Taste of Agile, Beginner session on a variety of topics.
Q: What are the differences between Kanban / Scrum?
· Scrum works from a Vision based Product Backlog. Kanban backlog can be for completing unrelated work.
· Scrum has Sprint time boxes. Kanban does not require time boxes. It is flow and cycle time focused to determine when work gets done.
· Scrum has predefined meetings/ceremonies performed when the Scrum Guide says they should occur. Kanban has Daily Standup. It has Replenishment (Planning) meeting triggered by available slots in the To Do or Backlog columns.
· Scrum has defined roles. Kanban does not advertise defined roles. It encourages respecting the existing roles, responsibilities as well as job titles.
· Unless you create a “product support card”, the Sprint Backlog is set for the timebox. Kanban has not timebox based backlog allowing new work to be introduced when signal appears on the board.
· Scrum is traditional used to develop work be it IT or non-IT based work. Kanban manages work so it can be used to manage operation or support work. Requests at the company portfolio level. Manage personal work. Manage office work. It is also used for software development too.
Q: If your team is in charge of keeping the lights on (application maintenance). How can you use Agile methodology and be able to use sprints when sometimes the need is urgent? Thank you.
· Use Product Owner to decide what is most important to do.
· Team creates a policy to govern the work.
· Is Kanban a better option since there is not time box requirement?
· If you must use Scrum, a separate card is created to track hours/person effort (FTE)? Determine what portion of the Sprint capacity is required based on past trends?
· Would Scrumban be a better option? No estimating and on-demand planning are removed and Kanban policy, WIP limits, Cycle time practice used to manage work.
· Everything in Agile is about the discussion, that is feedback.
Q: What is Team Velocity? / Velocity?
· Velocity is used as a capacity tool for planning. Velocity is the metric used by the Development Team in determining what product backlog items (PBIs) they will move to the Sprint Backlog or estimate the number of sprints required for a MVP or release plan. This metric is team specific and is never used for other teams or to compare teams. First time team should be conservative in deciding their velocity. 15 to 20 story points is not uncommon.
Q: Velocity, what is the impact if my team is doing both building the application and supporting our production release?
· Your team should discuss and agree on portion of the capacity will be used for product development and production support. Capture data and determine the percentage for both based on historical trends based on events. What has history show our capacity requirement to be following a product release? What has history show our capacity requirement to be three months after the release? Use this to determine what amount of story points can the team deliver. Create a story so your board clearly shows the need for production support.
· It is key to breakdown the user stories as small as possible and clear understanding of acceptance criteria when needing to support production and delver potential shippable product increments. The team balance time to deliver production fixes, time to deliver product, and team support/collaboration with the team.
Q: Velocity, what is the impact?
· Historical trends have shown a team can delivery 20 story points. At the end of the next sprint, the team delivers 25 story point during their two-week sprint. At the end of the next sprint, the team delivers 15 story point during their two-week sprint. What is the team estimate thereafter? In the first scenario, it will be slightly more than 20 based on the velocity in the previous two sprints. In the second scenario, it will be slightly less than 20 based on the velocity in the previous two sprints. In both cases, the team will use the Sprint Retro to discuss why the change.
Q: Generation gap among X, Y, Z and millennials in one Agile Team? How do I approach it?
· Establish open and honest communication. Everyone needs to participate.
· Worked with in their 20s which has a short attention span. They wanted to get started and move onto the next thing. In Agile you need to determine what is most important to focus refinement (decompose work) to get the work defined and ready to be worked on. Make sure they are involved and the work get ready quickly.
· Focus is on “How does the team feel the team is doing.” Never make it about I.
· Reward team.
· Help create a team environment.
· Gauge how well they accept change. Coach as needed.
· Different generations have different perspectives. Their diverse perspectives are invaluable. Tap in to it.
· Stop doing things that do not need to be done.
· All the generations like doing work. They have different approaches. Give them the flexibility to tackle their way as long as they are focused on the same goal.
· Remove distraction and make the work the priority.
· Develop trust and learn to work with them.
Q: How to use Agile to manage team members via virtual meetings?
· Transformation Experts’ website has rebroadcast at its website (teculture.com). Check the resource menu choice.
Q: What should be the next Agile/Scrum certification course I take?
· Begin with a role-based classed for beginners, such as Product Owner, Scrum Master, or Dev. Team. Next you can take an advance class for your role. From there you can consider scaling classes for Scrum, SAFe, or LeSS based on your company or career direction.
Q: How do you start? This is from the May 16 and 30 discussions
· Determine how it would best apply in your environment.
· Try on something small first.
· Identify the participating members. Take them to lunch or coffee and share with them your plans.
· Ask the team if we are 100% effective. How might we more effective? How can we get better?
· Speak with management so they are aware of what is happening.
· Identify the metrics and data capture which would exert influence on management and team to continue.
· If there is a PMO which requires metrics and documentation, do them. Please do not give them an excuse to stop Agile.
· Add more small projects incrementally. Avoid migrating many teams at the start.
· Use Agile experiment thinking (Empirical Process). Test and learn every time box cycle. Define a theory/hypothesis and test it when working with scientist community.
· Ask the group to meet daily. What is going on? Do you need help on anything?
· Set realistic success goal to start. Show results and reflect on the timebox frequently.
· Identify small, incremental changes we can make.
Q: How do you deal with passive aggressive team members including Product Owner and SCM/Coach?
· Determine why this person is acting in a passive aggressive way?
· Establish open and honest communication. What is that they want? See if in the future the person can talk about the issue instead of acting passive aggressive.
· ScrumMaster creates a safe environment where the team member can say what they need.
· Remember that the team is self-organizing and self-managing so they are the first line of defense. They should tell the passive-aggressive person their expectations to see an improvement in their behavior.
Note: The beginner session questions on Scrum and Kanban frameworks are found in a separate entry under the resource menu choice.