Skip to main content

Home/ Agilesparks/ Group items tagged facilitation

Rss Feed Group items tagged

Yuval Yeret

Growth Facilitator role on an OpenAgile team | Agile Advice - Working With Agile Method... - 0 views

  • The responsibility of the Growth Facilitator is about more than simply prioritizing New Work goals and tasks. I see the role as contributing to the organizational culture, and helping to build the business in a sustainable way.
  • As Growth Facilitator, I am also responsible for guiding the team toward delivering greater value for our stakeholders. At Berteig Consulting, our stakeholders don’t just include the company’s owners. Our stakeholders include a wide range of groups, including customers, suppliers, employees, and our families, all without whose support nothing we do would be possible. Delivering value to our stakeholders requires that we keep them in mind when we commit to our tasks each week.
  • When I first started, I made goals that were broad, saying for example “to take care of our clients” or “to work at a sustainable pace.”
  • ...2 more annotations...
  • Berteig Consulting can update the Certified ScrumMaster course content so that all CSM course participants receive the best value in the market.” As soon as I made the direction clear, the team self-organized and generated tasks required to achieve each goal.
  • As the Process Facilitator goes about helping the team overcome obstacles, it can become clear that the team needs to address a systemic challenge during one of the upcoming Cycles. The Growth Facilitator then states the need as a Cycle goal in a S.M.A.R.T. format, allows the team time to give feedback, and prioritizes the goal in the New Work list. When the goal is brought to a future Cycle Commitment Meeting, the team breaks the goal into tasks and solves the systemic obstacle that the Process Facilitator identified.
  •  
    Who is the Agilesparks Growth Facilitator? Who's the Process Facilitator for that matter? Interesting reading. Important aspect of managing self-organizing teams in my oppinion
yaelgr

Functional Subgrouping the core method of Systems-Centered Training - developed by Y. A... - 0 views

  •  
    Short description of facilitation tool
Yuval Yeret

Agile PMO Role - 0 views

  • Institute an agile transition team, and have the agile PMO play a significant role on that team. If you are starting on the journey, establishing an agile transition team can be a critical factor in your success. The agile transition team plans and implements the strategy for the organization’s agile transition (using a backlog, iterations, planning meetings, retrospectives and, in general, responding to change) This group monitors and communicates results throughout the organization, and is responsible for removing organizational level impediments. The PMO representative can act as ScrumMaster for the agile transition team. Members should be leaders representing different departments and functions that are impacted by the agile transition. For example, having leaders from development, QA, product development and the PMO is an excellent practice.
  • Establish a “Meta Scrum” that is tasked with mapping projects and features to corporate strategy. As part of optimizing the whole, it is important for there to be a big picture view across products and features. In general, product managers are tasked with defining, prioritizing and communicating the vision and features for their products. When you have a program that encompasses multiple products with multiple product owners and project teams, keeping everything in line with the corporate vision can sometimes be overlooked.   Unlike the Scrum of Scrums--which is tactical, i.e. focused on execution--the Meta Scrum is focused on the strategic planning and decisions guiding the program or programs as a whole. Establishing a Meta Scrum with the PMO representative acting as ScrumMaster to plan and facilitate meetings (as well as reporting and tracking decisions and action items) can add significant value in having a program able to rapidly respond to change while staying true to the corporate strategy and objectives.
  • I like using story points to establish the velocity of individual teams. From a program point of view, however, story points are difficult to use across multiple teams. The nut there is that one team’s story point is not equivalent to another team’s story point. To crack that nut, I use agileEVM to “normalize” to standard project management metrics like the Cost Performance Index and the Schedule Performance Index, as well as the Estimate At Complete in integrated dollars. These metrics can be aggregated across teams to establish progress against the plan for the entire program.
  • ...1 more annotation...
  • Establish an agile CoachingCenter. It is important from an organizational perspective to continue to provide coaching and training to agile teams. Team development and facilitation needs continue after the initial shift to agile methods is completed. In addition, new team members are hired, new practices discovered and implemented. Establishing an agile coaching center of excellence can meet this need.   In order to be successful, the center needs to be a legitimate organization with an assigned budget, staff and objectives. The center can be a located within the agile PMO. The center can develop and manage a central agile library, produce various lunch ‘n’ learns and other programs to infuse agile values and knowledge across the organization, and provide proficient, independent facilitators to teams for various retrospectives and other needs. In addition, the center can help the team gather metrics on their agility and health so that the team can take action if the decide to.
Yuval Yeret

tips on reviving retrospectives from the retrospectives yahoo group - 0 views

  • Has the team made changes that make a difference to them as a result of the retrospective?
  • Has the team explored a variety of different topics/areas, or do they stick to pretty much the same agenda around continuous improvement? What is the balance of change/improvement work vs. working on the product?
  • For example, try looking at technical practices, teamwork, or customer relationships... choose what ever seems most relevant to bound the discussion. That might help the team dig deeper and find issues that have more significance for them (now...I'm sure the other changes were significant at the time).
  • ...14 more annotations...
  • Try a 'speed retrospective'. How quickly can the team get together and find one good, solid improvement to make? Make it exciting and use a stopwatch. I wouldn't do this all the time, but again, what harm to try it once?
  • How about one retrospective where you set yourselves the challenge of generating actions from the "What did we do well" column? In other words, find an action designed to magnify an existing positive rather than remedy an existing negative.
  • How about a 'Show and Tell' retrospective where every team member comes to the meeting with an action item and its explanation already prepared? The retrospective would really be each person presenting their idea in turn.
  • How about a retrospective wherein you challenge yourselves to come with a new approach to retrospectives that is so exciting that people would skip other work activities to attend?
  • I find it very important to revisit the outcome of the past retrospective and celebrate the things the team had been able to do differently.
  • The major thing is to make the changes visible and memorizable for everyone and not assuming that people remember what they decided on in the last retro.
  • Another thing is that I would invite team members to take turns in facilitating the retro. So not always the same person runs the retro (this typically also changes the format and techniques a bit).
  • - Heartbeat Retrospective (google for Boris Gloger)
  • - Temperature Reading
  • - Team Radar Chart
  • - Our project / team / product ship - draw a ship on a flip chart, ask the team what moved the ship forward, what blocked it
  • Just to add a totally different direction: I've made good experiences with having a *long* retrospective every few months. The short retrospectives are great to see the trees and optimize the daily work. A two or even three day retrospective helps the team to step back and watch the forrest instead.
  • It is important to get at least one item done every sprint. If you do the retro, but don't implement any of the actions, this is a tremendous demotivator. Better one thing finished that you can celebrate than 5 unfinished things in the queue.
  • Variety is the spice of life, so some variation is essential to keep the freshnees. Change the moderator, do technical focus once, then organisational, then "improving the fun factor", then go back to a general retro.
Yuval Yeret

Agile Game Development: The Project Manager Role - 0 views

  • The Project Manager works with the Product Owner to insure that cost is always a consideration when evaluating the Product Backlog.
  • "Super Scrum Master"
  • Tracking costs, especially for production
  • ...6 more annotations...
  • Facilitate the Product Owner's role (backlog maintenance and meetings)
  • Among the Project Manager's responsibilities:
    • Yuval Yeret
       
      sounds like what some organizations will call "Program Manager"
  • Tracking project risk
  • The Project Manager on a Scrum project has to be a Scrum expert and evangelist.
  • As each Scrum team on the project evolves their practices, the Project Manager will insure that they are continuing to work effectively with the other teams
  • One example of this would be the application of Test Driven Development and similar practices to build stability. It doesn't make sense for some teams to use TDD while others don't. The PM would have to step in and work with all the teams to insure that practices won't interfere or cancel each other out.
Yuval Yeret

Ideal Training for Enterprise-Scale Agility? « Scaling Software Agility - 0 views

  • training strategy for a significant enterprise that is contemplating an “all in” (immediate and across the entire company) enterprise scale transformation approach
  • for the enterprise, a combination of team-based and role-based training that would touch every practitioner is ideal
  • all team practitioners receive a minimum of two days of agile training, (agile team training for the each team in the enterprise)
  • ...11 more annotations...
  • an additional day or so of training for specialized roles of Product Owner, Project/Release Manager, and Agile/Scrum Master
  • All other executives and managers are invited to attend an overview course on scaling software agility
  • Agile for Teams –Essential, team-based training in a two day workshop
  • philosophy, principles, and benefits of agility, agile methods, iterative and release framework, roles, agile technical practices, and agile management practices (Scrum)
  • Agile Release and Project Management at Enterprise Scale – For Project Managers, Release Managers, Program and Portfolio Managers who have responsibility for helping deliver the product(s) to the marketplace. Topics include differences between traditional and agile product management, iteration framework, multi-level release planning and tracking, the agile release train, planning and executing the release planning event, and measuring enterprise progress.
  • Agile Product Owner in the Enterprise – For team-based product owners/candidates who will become responsible for backlog management, story writing, and iteration and release planning, and who will also be involved in the planning and coordination of larger scale software systems of systems built by teams of teams.
  • The Agile Master In The Enterprise – For potential agile team leads/future Scrum Masters who will be coaching agile teams and who will interact with other teams as well. Topics include: process facilitation, enterprise agility, mastering the iteration, team roles, release planning and tracking, agile leadership, empowerment and conflict management, and integration Scrums.
  • Agile Product Manager in the Enterprise – For enterprise product managers with product, product line, portfolio and business unit responsibilities. Topics include: what’s so different about agile, backlog and prioritization, relationship to product owners, PM’s role in release planning and management, visioning and the product roadmap.
  • Scaling Software Agility – Best Practices for Large Enterprises – For executives and key stakeholders in support, distribution, quality, internal IT, HR and all others whose roles will be impacted by the substantive changes that enterprise agile engenders. Part I – overview of agility highlighting lessons learned from the most common and effective agile methods Part II – seven team best practices of agility that natively scale to the enterprise level Part III – seven organizational capabilities that companies can master to achieve the full benefits of enterprise scale agility
  • The team member doesn’t need a CSM course, but he does need to know how to work in an agile environment.
  • what are the engineering practices need to support agile development? I’ve found that if developers only have their existing tools and practices, then they will continue to specify and develop waterfall-style within the sprints.
Yuval Yeret

Customer's Run: Iteration Planning - 0 views

  •  
    "Customer's Run: Iteration Planning"
1 - 20 of 33 Next ›
Showing 20 items per page