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

Architecture backlog

Expand Messages
  • JackM
    I was fortunate to catch one of Mike Cottemeyer s webinars on Acieving Business Agility at the Porfolio level. He spoke about the architectural roadmap and how
    Message 1 of 11 , Apr 12, 2013
    • 0 Attachment
      I was fortunate to catch one of Mike Cottemeyer's webinars on Acieving Business Agility at the Porfolio level.

      He spoke about the architectural roadmap and how that overlays onto the epic roadmap all in an effort to help to risk reduce the backlog.

      I am wondering if anyone in this forum is doing this and if so what the architectural roadmap might look like, is it just a backlog of architecture epics.

      I have a feeling that this forum is going to say that architecture shouldn't be ahead but rather handled together with the epic development in a thin slice approach.

      The problem we have is that we are building software that's deployed into huge financial institutions and some of the architecture "bits" are extremely complex that need to be figured out to a level that when the teams are ready to sprint they have this reasonably figured out.

      Any information would be helpful.

      Thanks
      jack
      www.agilebuddy.com
    • Curtis Cooley
      ... advance you have to make a lot of assumptions and guesses. You are not waiting until the last responsible moment. I also feel you are assuming all large
      Message 2 of 11 , Apr 12, 2013
      • 0 Attachment
        On Fri, Apr 12, 2013 at 7:44 AM, JackM <jack@...> wrote:

        > **
        >
        >
        > I have a feeling that this forum is going to say that architecture
        > shouldn't be ahead but rather handled together with the epic development in
        > a thin slice approach.
        >
        > I'm in this camp because when you try to figure out your architecture in
        advance you have to make a lot of assumptions and guesses. You are not
        waiting until the last responsible moment.

        I also feel you are assuming all large scale architectures are the same,
        and you can just grab a book on enterprise architecture and copy into
        yours. When you do this, you are missing the opportunity not only to mold
        the architecture to your needs, but to find revolutionary approaches to
        your enterprise problems.

        If you allow your architecture to evolve, it more closely matches your
        needs, you make architectural decisions when you know enough about your
        software to make them, and you give yourself the opportunity to break out
        of the mold and perhaps create something interesting and awesome.
        --
        --------------------------------------
        Curtis Cooley
        Agile Coach
        Industrial Logic
        curtis@...


        [Non-text portions of this message have been removed]
      • Ram Srinivasan
        ... link, if possible? Thanks, Ram ... [Non-text portions of this message have been removed]
        Message 3 of 11 , Apr 12, 2013
        • 0 Attachment
          On Fri, Apr 12, 2013 at 10:44 AM, JackM <jack@...> wrote:

          > **
          >
          >
          > I was fortunate to catch one of Mike Cottemeyer's webinars on Acieving
          > Business Agility at the Porfolio level.
          >

          >> I would be actually interested to know what he says. Can you send me the
          link, if possible?

          Thanks,
          Ram

          > Thanks
          > jack
          > www.agilebuddy.com
          >
          >
          >


          [Non-text portions of this message have been removed]
        • JackM
          I buy that, and in actual fact our architecture does evolve. However the way we work is upfront of a release we identify investment areas and Epics upfront. we
          Message 4 of 11 , Apr 12, 2013
          • 0 Attachment
            I buy that, and in actual fact our architecture does evolve. However the way we work is upfront of a release we identify investment areas and Epics upfront. we work in 6 week increments 3 sprints of 2 weeks each. so generally we know which epics are coming up in the next 6 week increment and we identify any potential risks upfront and try to start thinking about what architecture elements we need in place, what security pieces will be impacted etc. So ahead of the next cycle we're working on risk reducing our backlog so we can drive more certainty in our process.

            At the sprint level we do something similar - we have at least 2 sprints worth of stories ranked, and any uncertainty in the forthcoming sprint we try to run spikes in the current sprint. this makes our planning better, it makes us more reliable and we're able to commit better through upfront understanding.

            So these architecture pieces we identify upfront is kind of where my question lies. what should an architecture roadmap look like, are they simply epics in and of themselves. Is it a separate backlog etc.

            In regards the link to the presentation, i'll try to post later as i don't have it handy.

            Cheers
            Jack
            www.agilebuddy.com

            --- In extremeprogramming@yahoogroups.com, Curtis Cooley <curtis@...> wrote:
            >
            > On Fri, Apr 12, 2013 at 7:44 AM, JackM <jack@...> wrote:
            >
            > > **
            > >
            > >
            > > I have a feeling that this forum is going to say that architecture
            > > shouldn't be ahead but rather handled together with the epic development in
            > > a thin slice approach.
            > >
            > > I'm in this camp because when you try to figure out your architecture in
            > advance you have to make a lot of assumptions and guesses. You are not
            > waiting until the last responsible moment.
            >
            > I also feel you are assuming all large scale architectures are the same,
            > and you can just grab a book on enterprise architecture and copy into
            > yours. When you do this, you are missing the opportunity not only to mold
            > the architecture to your needs, but to find revolutionary approaches to
            > your enterprise problems.
            >
            > If you allow your architecture to evolve, it more closely matches your
            > needs, you make architectural decisions when you know enough about your
            > software to make them, and you give yourself the opportunity to break out
            > of the mold and perhaps create something interesting and awesome.
            > --
            > --------------------------------------
            > Curtis Cooley
            > Agile Coach
            > Industrial Logic
            > curtis@...
            >
            >
            > [Non-text portions of this message have been removed]
            >
          • JeffGrigg
            ... Epics ... You know, the fact that we have a convenient word for it doesn t make it a good thing to have.
            Message 5 of 11 , Apr 13, 2013
            • 0 Attachment
              --- "JackM" <jack@...> wrote:
              > ... we identify ... Epics upfront. ...

              "Epics"...

              You know, the fact that we have a convenient word for it doesn't make it a good thing to have.
            • JeffGrigg
              ... ...kinda like war .
              Message 6 of 11 , Apr 13, 2013
              • 0 Attachment
                > --- "JackM" <jack@> wrote:
                >> ... we identify ... Epics upfront. ...

                --- "JeffGrigg" <jeffreytoddgrigg@...> wrote:
                > "Epics"...
                >
                > You know, the fact that we have a convenient word for it
                > doesn't make it a good thing to have.

                ...kinda like "war".
              • steveropa
                Considering the calendar, I was going to say like “taxes”... I’m struggling with how many people are finding ways to use what they feel are Agile terms
                Message 7 of 11 , Apr 14, 2013
                • 0 Attachment
                  Considering the calendar, I was going to say like “taxes”...


                  I’m struggling with how many people are finding ways to use what they feel are Agile terms in order to bring us back to BDUF and waterfall. And there are a lot of people I really like and respect who are following that will-o-the-wisp. Whenever I start to say “don’t do that” I start to feel like I’m coming across as the grumpy old man. Any suggestions as to a gentle way to say “this hasn’t worked yet, why do you think this time will be different?” when it comes to following that path?



                  Steve



                  From: JeffGrigg
                  Sent: ‎Saturday‎, ‎April‎ ‎13‎, ‎2013 ‎1‎:‎48‎ ‎AM
                  To: extremeprogramming@yahoogroups.com





                  > --- "JackM" <jack@> wrote:
                  >> ... we identify ... Epics upfront. ...

                  --- "JeffGrigg" <jeffreytoddgrigg@...> wrote:
                  > "Epics"...
                  >
                  > You know, the fact that we have a convenient word for it
                  > doesn't make it a good thing to have.

                  ...kinda like "war".





                  [Non-text portions of this message have been removed]
                • JackM
                  Perhaps, I am misunderstanding you but i am having difficulty understanding why identifying high level what you are trying to accomplish in a release is BDUF.
                  Message 8 of 11 , Apr 15, 2013
                  • 0 Attachment
                    Perhaps, I am misunderstanding you but i am having difficulty understanding why identifying high level what you are trying to accomplish in a release is BDUF.

                    We have extremely large customers with long sales cycles and our pipeline is generally aligned with what our customers long term needs are.

                    It's important for us to understand what's coming so that we are prepared. Identifying risks upfront has been extremely helpful. We're talking one to two quarters out at the epic level.

                    My understanding is that planning to the horizons is common practice ... i.e. sprint horizon, requires 2 sprints worth of well understood well ranked stories. At the quarterly horizon prob a good idea that the teams have a good handle on what epics are on the horizon etc.

                    Thanks
                    jack
                    agilebuddy.com


                    --- In extremeprogramming@yahoogroups.com, <steveropa@...> wrote:
                    >
                    > Considering the calendar, I was going to say like “taxes”...
                    >
                    >
                    > I’m struggling with how many people are finding ways to use what they feel are Agile terms in order to bring us back to BDUF and waterfall. And there are a lot of people I really like and respect who are following that will-o-the-wisp. Whenever I start to say “don’t do that” I start to feel like I’m coming across as the grumpy old man. Any suggestions as to a gentle way to say “this hasn’t worked yet, why do you think this time will be different?” when it comes to following that path?
                    >
                    >
                    >
                    > Steve
                    >
                    >
                    >
                    > From: JeffGrigg
                    > Sent: ‎Saturday‎, ‎April‎ ‎13‎, ‎2013 ‎1‎:‎48‎ ‎AM
                    > To: extremeprogramming@yahoogroups.com
                    >
                    >
                    >
                    >
                    >
                    > > --- "JackM" <jack@> wrote:
                    > >> ... we identify ... Epics upfront. ...
                    >
                    > --- "JeffGrigg" <jeffreytoddgrigg@> wrote:
                    > > "Epics"...
                    > >
                    > > You know, the fact that we have a convenient word for it
                    > > doesn't make it a good thing to have.
                    >
                    > ...kinda like "war".
                    >
                    >
                    >
                    >
                    >
                    > [Non-text portions of this message have been removed]
                    >
                  • Adam Dymitruk
                    You can t agile away architectural decisions. Domain Driven Design gives us some headlights to follow, as do concepts such as CQRS. What we know up front is
                    Message 9 of 11 , Apr 15, 2013
                    • 0 Attachment
                      You can't agile away architectural decisions. Domain Driven Design gives us
                      some headlights to follow, as do concepts such as CQRS. What we know up
                      front is SLAs for certain actions the user is going to take - at least what
                      they tell us they are.

                      Ignoring these concepts can lead into a nice design that falls out of TDD,
                      but fails under load. These are requirements, but they are non-functional
                      requirements where stories feel like fitting a square peg into a round hole.

                      So far, DDD has managed to keep iterating over non-functional requirements
                      not too expensive. And concepts like CQRS and event sourcing can help
                      refactor mid way through and replay events into an alternate set of domain
                      objects.

                      The backlog is easy to determine once you set up a strategy. One that works
                      for me is DDD/CQRS/ES in whole or part.

                      My $0.02

                      Adam

                      --
                      Dymitruk.com
                      On 2013-04-15 9:25 AM, "JackM" <jack@...> wrote:

                      > **
                      >
                      >
                      > Perhaps, I am misunderstanding you but i am having difficulty
                      > understanding why identifying high level what you are trying to accomplish
                      > in a release is BDUF.
                      >
                      > We have extremely large customers with long sales cycles and our pipeline
                      > is generally aligned with what our customers long term needs are.
                      >
                      > It's important for us to understand what's coming so that we are prepared.
                      > Identifying risks upfront has been extremely helpful. We're talking one to
                      > two quarters out at the epic level.
                      >
                      > My understanding is that planning to the horizons is common practice ...
                      > i.e. sprint horizon, requires 2 sprints worth of well understood well
                      > ranked stories. At the quarterly horizon prob a good idea that the teams
                      > have a good handle on what epics are on the horizon etc.
                      >
                      > Thanks
                      > jack
                      > agilebuddy.com
                      >
                      > --- In extremeprogramming@yahoogroups.com, <steveropa@...> wrote:
                      > >
                      > > Considering the calendar, I was going to say like “taxes†...
                      > >
                      > >
                      > > I’m struggling with how many people are finding ways to use what they
                      > feel are Agile terms in order to bring us back to BDUF and waterfall. And
                      > there are a lot of people I really like and respect who are following that
                      > will-o-the-wisp. Whenever I start to say “don’t do that†I start to
                      > feel like I’m coming across as the grumpy old man. Any suggestions as to
                      > a gentle way to say “this hasn’t worked yet, why do you think this time
                      > will be different?†when it comes to following that path?
                      > >
                      > >
                      > >
                      > > Steve
                      > >
                      > >
                      > >
                      > > From: JeffGrigg
                      > > Sent: ‎Saturday‎, ‎April‎ ‎13‎, ‎2013 ‎1‎:‎48‎
                      > ‎AM
                      > > To: extremeprogramming@yahoogroups.com
                      > >
                      > >
                      > >
                      > >
                      > >
                      > > > --- "JackM" <jack@> wrote:
                      > > >> ... we identify ... Epics upfront. ...
                      > >
                      > > --- "JeffGrigg" <jeffreytoddgrigg@> wrote:
                      > > > "Epics"...
                      > > >
                      > > > You know, the fact that we have a convenient word for it
                      > > > doesn't make it a good thing to have.
                      > >
                      > > ...kinda like "war".
                      > >
                      > >
                      > >
                      > >
                      > >
                      > > [Non-text portions of this message have been removed]
                      > >
                      >
                      >
                      >


                      [Non-text portions of this message have been removed]
                    • Michal Svoboda
                      ... Interesting thread. Why do you think epics are bringing us back to BDUF? Michal Svoboda
                      Message 10 of 11 , Apr 15, 2013
                      • 0 Attachment
                        steveropa@... wrote:
                        > I’m struggling with how many people are finding ways to use what they
                        > feel are Agile terms in order to bring us back to BDUF and waterfall.

                        Interesting thread. Why do you think epics are bringing us back to BDUF?

                        Michal Svoboda
                      • Leonardo Postacchini
                        By increasing real sprint size(time in between deliverables regardless what you tagged as the sprint) for example. Look back at this thread: planning ahead,
                        Message 11 of 11 , Apr 17, 2013
                        • 0 Attachment
                          By increasing real sprint size(time in between deliverables regardless what
                          you tagged as the sprint) for example. Look back at this thread: planning
                          ahead, looking to the horizon, making architetural decisions up front, big
                          client having big needs being served by long deliveries.

                          All of it sounds and smells like waterfall.

                          On Tuesday, April 16, 2013, Michal Svoboda wrote:

                          > **
                          >
                          >
                          > steveropa@... <javascript:_e({}, 'cvml', 'steveropa%40gmail.com');>wrote:
                          > > I’m struggling with how many people are finding ways to use what they
                          > > feel are Agile terms in order to bring us back to BDUF and waterfall.
                          >
                          > Interesting thread. Why do you think epics are bringing us back to BDUF?
                          >
                          > Michal Svoboda
                          >
                          >
                          >


                          [Non-text portions of this message have been removed]
                        Your message has been successfully submitted and would be delivered to recipients shortly.