Skip to main content

Home/ Agilesparks/ Group items tagged motivation

Rss Feed Group items tagged

Yuval Yeret

Motivation video - 3 views

  •  
    Al as a coach gives a motivation speech to his team Great to show in any motivation session.
dankoagile

Pulp Fiction - Mr Wolf on Motivation - 0 views

  •  
    Pulp fiction - the cleaner - classic. Great as something to show in a motivation session
Yuval Yeret

Alistair.Cockburn.us | Agile contracts - 1 views

  • Venture-capital financing model This can be used with any of the above contract forms. In this model, the sponsor gives a round of financing for a certain amount of work, and the contracted company must produce results in order to get more funding. The sponsor can cut their losses at any time if they are not getting the results they need. They can presumably alter the terms of the contract after each work period. The result of a work period need not be working software; it could be a paper study, or a requirements document, or anything the sponsor selects. The venture-capital finance model works well with agile providers, since the agile provider is used to delivering useful, working software early and regularly. I find it an odd irony that the venture capital financiers running start-ups that I have encountered don’t take advantage of their own model to the extent agile teams do. The venture financiers let the evaluation markers occur too far apart in time. If they attached funding to monthly releases, that would oblige the start-up team to think through what it really can accomplish each month. The monthly progress would give the financiers a better sense of the start-up company’s real progress.
  • Venture-capital financing model This can be used with any of the above contract forms. In this model, the sponsor gives a round of financing for a certain amount of work, and the contracted company must produce results in order to get more funding. The sponsor can cut their losses at any time if they are not getting the results they need. They can presumably alter the terms of the contract after each work period. The result of a work period need not be working software; it could be a paper study, or a requirements document, or anything the sponsor selects. The venture-capital finance model works well with agile providers, since the agile provider is used to delivering useful, working software early and regularly. I find it an odd irony that the venture capital financiers running start-ups that I have encountered don’t take advantage of their own model to the extent agile teams do. The venture financiers let the evaluation markers occur too far apart in time. If they attached funding to monthly releases, that would oblige the start-up team to think through what it really can accomplish each month. The monthly progress would give the financiers a better sense of the start-up company’s real progress.
  • Bob Martin’s idea Bob Martin of Object Mentor posted an interesting variant to get around this problem: a base fee per story point, plus a lower-than-usual (close-to or below cost) fee per hour. This biases the contracted company’s to deliver early, but gives them some protection in case work proceeds slower than expected. Bob Martin described it this way:”[A]gree to pay a certain amount for each point completed, plus a certain amount for each hour worked. For example, let’s say you’ve got a project of 1000 points. Let’s also say that a team of four has established an estimated velocity of 50 points per week. This looks like about an 80 man-week job. At $100/hour this would be a $320,000 job. So lets reduce the hourly rate to $30/hour, and ask the customer for $224 per point. This sets up a very interesting dynamic. If the job really does take 80 man-weeks, then it will cost the same. If it takes 100 man-weeks then it will cost $344,000. If it takes 70 man-weeks it will cost $308,000. Notice that this is a small difference for a significant amount of time. Notice also that you, as developer feel strong motivation to be done early, since that increases your true hourly rate.” I have not seen that model in action myself, but several people have written in recommending it.
  • ...2 more annotations...
  • Bob Martin’s idea Bob Martin of Object Mentor posted an interesting variant to get around this problem: a base fee per story point, plus a lower-than-usual (close-to or below cost) fee per hour. This biases the contracted company’s to deliver early, but gives them some protection in case work proceeds slower than expected. Bob Martin described it this way:”[A]gree to pay a certain amount for each point completed, plus a certain amount for each hour worked. For example, let’s say you’ve got a project of 1000 points. Let’s also say that a team of four has established an estimated velocity of 50 points per week. This looks like about an 80 man-week job. At $100/hour this would be a $320,000 job. So lets reduce the hourly rate to $30/hour, and ask the customer for $224 per point. This sets up a very interesting dynamic. If the job really does take 80 man-weeks, then it will cost the same. If it takes 100 man-weeks then it will cost $344,000. If it takes 70 man-weeks it will cost $308,000. Notice that this is a small difference for a significant amount of time. Notice also that you, as developer feel strong motivation to be done early, since that increases your true hourly rate.” I have not seen that model in action myself, but several people have written in recommending it.
  • Norwegian PS 2000 Standard contract http://dataforeningen.no/?module=Articles;action=ArticleFolder.publicOpenFolder;ID=1044 “The main feature of the contract for software development is that it provides mechanisms for establishing a common understanding between customer and the developer and a flexible iterative model for development suited for an environment of uncertainties and risks.” ...” Stage by stage, iterative development model securing ability to benefit from increasing understanding of the requirements and challenges Close co-operation between supplier and customer Incentives and sanctions in combination with target pricing Procedures for conflict resolution with an expert as a mediator ” You need to order it (it costs several thousand Norwegian kronor):
Yuval Yeret

How Google Sold Its Engineers on Management - 0 views

  • 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

Challenging Why (not if) Scrum Fails | NetObjectives - 0 views

  • I do believe for Scrum to work beyond the team you need more than Scrum
  • what to add to Scrum making it more effective when it won't readily work
  • lack of team agility is not always the major impediment to Enterprise Agility
  • ...12 more annotations...
  • While starting at the team level with Scrum is often good, you often need to start with the product management team - that is, where product enhancements to be worked on are selected
  • Even when Scrum works at the team level, organizations very often report little impact to the bottom line.  While this is better than nothing (if the teams are happier, that's good), it usually doesn't justify a huge investment
  • in many contexts in which Scrum does not work readily, Scrum has no power to improve the context in which it is in.  In other words, the impediments that one must fix are often outside of the scope of what Scrum helps you do.
  • These impediments are often not even seen or if they are, are often viewed as "just the way it is."
  • certain Scrum attitudes often makes things worse
  • Scrum does little to let management to know how the team works or what impact management decisions have on the team
  • There is almost a religious zeal that Scrum tells you little of what to do
  • While SoS works well for certain types of work, it does not work well when the different teams have different motivations. 
  • the high failure rate is due to the fact that Scrum works in certain contexts but has little ability to change the contexts in which it doesn't work wel
  • One needs to pay attention to where to start as well as see how to change the context.  Separating the team from management doesn't help.  Focusing on only the team part of the value stream - giving little guidance both up and downstream of the team also doesn't help.  Lean provides guidance here (meaning Scrum with the aid of Lean could provide insights),
  • look into using Lean as a context for any improvement in your software development organization
  • While Scrum may be an appropriate choice in many circumstances, other methods may be better (e.g., Kanban Software Development).  Scrum's rapid ascension probably has more to do with its success in the places it easily fits.  Now that it is past the early adopter phase, we may see it having even a harder time as people attempt to scale it.
1 - 12 of 12
Showing 20 items per page