Loading ...
Sorry, an error occurred while loading the content.

53994RE: [scrumdevelopment] Re: Size of team a barrier to SCRUM and Agile

Expand Messages
  • Steve Ropa
    Jan 27, 2012
    • 0 Attachment



      This is an awesome answer.  I would also say it goes in the other direction, in that many developers seem to think that management is somehow an easy refuge for the semi-competent.  I have struggled for years with the culture in our world(development I mean, not just agile) that once someone becomes a manager they somehow get a lobotomy, or become power mad. 


      I would also say that your ps describes the toughest situation.  The manager who used to be a developer is part of the development black box to the rest of management, and part of the management black box to those in development. 

      From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Malcolm Anderson
      Sent: Thursday, January 26, 2012 3:20 PM
      To: scrumdevelopment@yahoogroups.com
      Subject: Re: [scrumdevelopment] Re: Size of team a barrier to SCRUM and Agile



      "Why on earth is this so difficult for people to comprehend? "


      It all comes down to "Anything I Don't Understand Is Easy To Do"

      To most managers, "Development" is a magic black box that they don't understand. 
      All they want is for the magic box to move faster.

      The trick is leading a manager type to comprehension without letting them think that you think they're an idiot.

      This is even trickier when you don't think they're an idiot, they'll often think you do anyway.



      In large companies, the magic black box called "Development" includes any manager who used to be a developer, tester, or anything else remotely technical.
      This extends to scrum trainers and coaches.

      On Thu, Jan 26, 2012 at 7:16 AM, woynam <woyna@...> wrote:


      Even if you *could* multitask without any overhead cost, it would *still* wind up costing the business in lost value.

      Ron and several others have posted examples *numerous* times that demonstrate that implementing multiple projects in parallel *guarantees* that all but one project will be delivered later than if the projects had been addressed serially.

      A project delivered later is *lost value*. Are businesses aware of this? If not, why? You need to have a conversation with the business that clearly explains that they can have Project A in 2 weeks, or they can have it in 12 weeks. In possible world can they have 6 projects in 2 weeks, but we can certainly give them 6 projects in 12 weeks, with the corresponding loss in value.

      Why on earth is this so difficult for people to comprehend?


      --- In scrumdevelopment@yahoogroups.com, Seyit Caglar Abbasoglu <scabbasoglu@...> wrote:
      > Some interesting stuff about multi-tasking
      > http://www.codinghorror.com/blog/2006/09/the-multi-tasking-myth.html
      > It seems Human can not multi-task complex jobs. She can only context
      > switch, and it's really costly.
      > The last statement is pretty effective :
      > " Whenever possible, avoid interruptions and avoid working on more than one

      > project at the same time. If it's unavoidable, *be brutally honest with

      > yourself-- and your stakeholders-- about how much you can actually get done

      > under multi-tasking conditions.* It's probably less than you think."

      > Perhaps your CIO should know about this.


      Malcolm Anderson
      Scrum Coach & Agile Engineer

    • Show all 24 messages in this topic