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

54936Re: Looking for Advise on Standup, burndown, and tracking progress

Expand Messages
  • tony_t_tubbs
    Apr 16, 2012
    • 0 Attachment
      Right, I know it's the real, true, actual SCRUM definition. I meant to say that you personally evangelize it well, that you personally don't waffle from it. I am aware that you do not stand alone either, so didn't mean to imply that this was your point of view and yours alone.

      We feel there is a real chance we can get done what we need to get done by years end. Especially if things go a planned, but we all know that rarely happens though. Still, we do not expect a worse case scenario either.

      You would also be correct in saying the company wouldn't implode or explode, but there is a chance this new division could. Probably not this time, as there's great potential here, but we will not be forgiven indefinably either. It truly is important for the life of this division to get to market in a timely manner.

      Otherwise, you've given some good thought to think about. Hope I can come back by years end and say we made it, or are at least still in a job.

      Thanks again,
      TT


      --- In scrumdevelopment@yahoogroups.com, RonJeffries <ronjeffries@...> wrote:
      >
      > Hi TOny,
      >
      > On Apr 16, 2012, at 3:19 PM, tony_t_tubbs wrote:
      >
      > > I read these forums often, and know you consistently in evangelizing this point of view. I completely agree that going doing things this way will undoubtedly lead to a better product and code base in the end.
      >
      > It's not my "point of view". It's the real, true, actual definition of Scrum. (It is also my point of view as it happens.)
      > >
      > > We have raised concerns, and made requests. These have gone all the way to The Board. There's no time or budget there to help us out. As such, we've reduced scope to the minimum it is believed the market will accept (we all believe do diligence was done here). At the same time there is a race to market, and end of year is a key date for that. At the end of all that the situation is that A, B and C must be done by June 1 so that D - N can be done by Dec. 31. M - Z have been postponed to be completed through 2014.
      >
      > OK ...
      > >
      > > I guess I'm saying we as a team and PO are in agreement that we have defined the best product possible by the due date - one that provides the minimum necessary to enter the market next year.
      >
      > How confident are you, personally, that this is possible? If you're not totally confident (and it sounds like you are not), then what else should you, and the company, be doing?
      >
      > Or (as is likely in my opinion) will the company really not explode into bits when, as seems quite possible, the team delivers somewhat too little, somewhat too late? And if the company really will not explode into bits, what, looking back from that date, would have produced a better result than "work overtime"?
      > >
      > > Entering the market as late as 2Q next year could be too late. This is where I get lost between what is advocated by the books vs what I see day after day, year after year. I'm not suggesting you're wrong. I expect you have seen and experienced something different than I have. This is where I think a coach would really help us. We seem stuck in our box unable to see how to bridge the gap between these seemingly conflicting goals.
      >
      >
      > These are the main possibilities I can see:
      >
      > Overtime will make you go fast enough to get what you need. There are a number of Very Big Assumptions in this one. First, that overtime will make you go faster, not slower, between now and June. Science, and experience, are against you on this one. Second, that if overtime does make you go faster, it will make you go enough faster that stopping steering now, in April, and just running like hell until June will do the job. What are the odds of that?
      > These features, as currently defined, are the absolute minimum viable product. Think how good you'd have to be, as a company, to have gotten it exactly right, with nothing capable of being thinned down, and nothing needing a bit of ramping up. And, if you are that good, so that you're all that confident, why not add in one or two very very good contract developers to help you. Not crappy beginners, but gods of programming. I could recommend some.
      > Overtime will not get us where we're aiming. This is incredibly likely to be true. So likely that you, your team, and your company need to do some serious risk management.
      > This isn't the minimum viable product. This is also incredibly likely to be true. So likely that your organization needs to find a way to create some slack, and some information, between now and then.
      >
      > I have been in your situation many times in my half century in this business. Never once was overtime the best thing to do, in retrospect, though we did it many times. The result, every time, was that we produced less code, of lower quality, than we would have otherwise. The result, every time, was that people suffered and, almost always, the company lost good people who quit when they became aware of the disrespect that lies beneath "someone made this promise, your job is to make it happen".
      >
      > My guess is that you're caught in this trap now and there is no way out but to bull it through. It's quite possible that you'll get enough done to survive. It's quite possible that you'll stay in business one way or another. Almost always, that's what happens.
      >
      > It's unfortunate that when we do something heroic and survive it, we tend to conclude that only by doing heroic things can we survive, and that if we were only more heroic we might even thrive.
      >
      > In my experience, nothing could be less true. We survive the heroism, and we survive the inferior work that heroics make us produce, and when we reflect later, we realize that we could, therefore, have done more work, better work, with less pain, by working smarter, rather than harder.
      >
      > We both know you're going to go ahead and do this. I hope at the other end, whatever happens, you'll think about it and come back and tell us about it.
      >
      > Good luck ...
      >
      > Ron Jeffries
      > www.XProgramming.com
      > If not now, when? -- Rabbi Hillel
      >
    • Show all 25 messages in this topic