Skip to main content

Home/ Agilesparks/ Group items tagged google

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
Yuval Yeret

How Google Sold Its Engineers on Management - 0 views

hbr.org/...ld-its-engineers-on-management

last-materials

shared by Yuval Yeret on 16 Mar 16 - No Cached
  • A good manager: 1. Is a good coach 2. Empowers the team and does not micromanage (See the sidebar “How Google Defines One Key Behavior”) 3. Expresses interest in and concern for team members’ success and personal well-being 4. Is productive and results-oriented 5. Is a good communicator—listens and shares information 6. Helps with career development 7. Has a clear vision and strategy for the team 8. Has key technical skills that help him or her advise the team
  • Employees with high-scoring bosses consistently reported greater satisfaction in multiple areas, including innovation, work-life balance, and career development
  • high-scoring managers saw less turnover on their teams than the others did—and retention was related more strongly to manager quality than to seniority, performance, tenure, or promotions
  • ...1 more annotation...
  • The key behaviors primarily describe leaders of small and medium-sized groups and teams and are especially relevant to first- and second-level managers. They involve developing and motivating direct reports, as well as communicating strategy and eliminating roadblocks—all vital activities that people tend to overlook in the press of their day-to-day responsibilities.
Yuval Yeret

Scaling agile to distributed teams.pptx - Google Drive - 0 views

docs.google.com/...edit

distributed distributed-teams-list

shared by Yuval Yeret on 25 Mar 16 - No Cached
  • Yuval Yeret on 25 Mar 16
     
    Collection of effective practices
Yuval Yeret

DevOps Manifesto - 0 views

sites.google.com/...devops-manifesto

devops devopsdays

shared by Yuval Yeret on 15 Sep 14 - No Cached
  • About creating visibility between dev and ops
  • Cross-functional teams over organizational silos
  • Products not projects
  • ...5 more annotations...
  • Automation over documentation (and more automation... and more...)
  • creating self-service infrastructure for teams
  • Cross-functional teams over organizational silos
  • Creating products that are owned by the delivery team
  • Delivery teams run software products - not projects - that run from inception to retirement
Yuval Yeret

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

finance.groups.yahoo.com/...1575

agile retrospectives agilesparksblog

shared by Yuval Yeret on 08 Jul 09 - No Cached
  • 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.
1 - 18 of 18
Showing 20▼ items per page