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

Re: [Agile_BA_Requirements] Re: Nailing my colours to the mast

Expand Messages
  • Kevin Brennan
    ... This one probably warrants a little explanation... When we (that is IIBA) launched the development of the BABOK there wasn t a lot of consensus out there
    Message 1 of 26 , Oct 1, 2009
    View Source
    • 0 Attachment
      On 2009-09-29, at 2:23 AM, Steve wrote:

      > But what does the BA do in an "agile" environment, write user
      > stories? Well let me use the consultant's mantra "...it depends..."
      > One thing I do know for sure is the BA needs to be much more of a
      > communicator, networker, facilitator, and builder of back channels.
      > The very best BAs already know this, and I strongly believe the best
      > work that will come from this group is to place interpersonal skills
      > at the very heart of the profession and the BA BOK. Right now I'm a
      > little disappointed this topic is dealt with almost as an
      > afterthought in the BA BOK.

      This one probably warrants a little explanation...

      When we (that is IIBA) launched the development of the BABOK there
      wasn't a lot of consensus out there as to what a BA was or what a BA
      should do. A major purpose of version 2.0 of the BABOK was to nail
      that down...we were much more focused on being able to answer the
      question "what is business analysis" than on trying to answer "what
      makes a good BA?". Essentially we felt (and were advised by others,
      such as PMI) that we had to get consensus on the first point before we
      could hope to get anywhere on the second.

      To a large extent I have to say that they were right...it took a lot
      of work to reach consensus within the team regarding the BA role and
      there were a lot of disputes (for those of you who have read the
      BABOK, there are a number of places where people complained the text
      was too pro-Agile, for instance). That said there are things that I
      would do differently if I had to do it all over again, and one of them
      is that we would probably have taken a more competency-based approach
      to developing the BABOK Guide. That said, it's not a huge issue--I
      have a team of volunteers building a competency model for BAs right
      now based on the BABOK Guide, and it turns out our structure supports
      that pretty well. By the time version 3 comes out we'll have actual
      data on the kinds of interpersonal skills and qualities that make for
      a good BA and will revise things accordingly.

      One thing that I can say that's interesting is that we are seeing a
      real gap between what BAs understand to be important and what they're
      actually doing. While the exact figures are confidential, I'm sure it
      won't surprise anyone to know there's a marked difference between what
      BAs say is critical to be effective and where they are actually
      spending their time. In theory, BAs acknowledge that defining the
      problem (the Enterprise Analysis KA) and validating the solution as
      delivered against the business need is at least as important as the
      specification of requirements. But in practice, most of their time is
      being spent on specification.
      ________________
      Kevin Brennan, CBAP, PMP
      Vice-President, Professional Development
      International Institute of Business Analysis (IIBA®)
      "Helping Business Do Business Better"
      www.theiiba.org
      kevin.brennan@...
      Office: (416) 233-8743
    • Kevin Brennan
      One issue I d like to throw out for discussion to this group. It often seems to me that a lot of the debate around the role of the BA in agile is predicated on
      Message 2 of 26 , Oct 6, 2009
      View Source
      • 0 Attachment
        One issue I'd like to throw out for discussion to this group. It often
        seems to me that a lot of the debate around the role of the BA in
        agile is predicated on the assumption that the BA's job is to write
        software specifications. I'm actually not at all sure that's true.
        There's no question that a lot of BAs do that, but even today our
        surveys are showing that the most critical and in-demand skills for
        business analysts are actually business-facing analysis skills, such
        as process modelling, business rule analysis, and so forth.

        So let me ask this: does Agile change the way that the business
        develops software? Or does it change how the business changes itself?
        ________________
        Kevin Brennan, CBAP, PMP
        VP, Professional Development
        International Institute of Business Analysis (IIBA®)
        "Helping Business Do Business Better"
        www.theiiba.org
        kevin.brennan@...
        (416) 233-8743
      • greyskinnedboy
        A fundamental question to ask the group Kent, thank you. It would be great if we could consider this fully. Remembering the Russian doll or onion layers of
        Message 3 of 26 , Oct 6, 2009
        View Source
        • 0 Attachment
          A fundamental question to ask the group Kent, thank you. It would be great if we could consider this fully. Remembering the Russian doll or onion layers of focus and interest, with the delivery team at its core.

          The focus of the delivery team may or may not be to develop software, but in all layers up from there it's good to be focused on the business benefits that any initiative is intended to realise, then what capabilities this needs or affects, etc. The delivery team's technical focus may vary from software development, business process improvement, organisation change -- or a combination of all three.

          It might be too narrow of a focus if we only talk around agile software development.

          Cheers,
          David.
        • greyskinnedboy
          Another crucial question, Steve, thanks - are we look at the role or capabilities of business analysis. My principle would be to look at the capabilities,
          Message 4 of 26 , Oct 6, 2009
          View Source
          • 0 Attachment
            Another crucial question, Steve, thanks - are we look at the role or capabilities of business analysis.

            My principle would be to look at the capabilities, whoever does them. Remember the delivery team is often termed as cross-functional and multi-disciplinary, which often means members will wear different hats at different times. But, heck, we do that today ... business analysts are often standing in for project managers, running tests, etc. ... but that is not business analysis.

            This was one of the principles behind development of the Business Analysis Body of Knowledge.

            Cheers,
            David.
          • Chris Matts
            For some reason I m compelled to focus on the value and the outputs. So Imagine I m someone coming to the Agile BABOK (C) ;-) What questions do I want the
            Message 5 of 26 , Oct 7, 2009
            View Source
            • 0 Attachment
              For some reason I'm compelled to focus on the value and the outputs.
               
              So Imagine I'm someone coming to the Agile BABOK (C) ;-) What questions do I want the answer to.
               
              1. What is Agile? ( I assume people have heard of Agile, but they may not know what it is about )
               
              2. How does Agile affect business analysis? / What are the implications of Agile on Business Analysis. / Why and How is Business Analysis different to traditional approaches.
               
              3. What are the techniques / tools people use on Agile Projects ( Experience Reports )? ( and references... books, web-sites etc. )
               
              4. What skills do I need to do Business Analysis on an Agile Project.?
               
              5. How do people currently doing analysis on agile projects rate the tools / references / skills. etc.?
               
              6. How do people rate the experience reports?
               
              7. Does Agile Business Analysis extend beyond software development?
               
              For 5 and 6, I'm thinking of the Amazon.com Rating system with "Founder" / "Top 100" users who write reviews and rate them.
              Are there other questions business analysts would ask?
               
              Chris

               
              On Tue, Oct 6, 2009 at 9:41 PM, greyskinnedboy <david.morris@...> wrote:
               

              Another crucial question, Steve, thanks - are we look at the role or capabilities of business analysis.

              My principle would be to look at the capabilities, whoever does them. Remember the delivery team is often termed as cross-functional and multi-disciplinary, which often means members will wear different hats at different times. But, heck, we do that today ... business analysts are often standing in for project managers, running tests, etc. ... but that is not business analysis.

              This was one of the principles behind development of the Business Analysis Body of Knowledge.

              Cheers,
              David.




              --
              Regards

              Chris Matts
            • Shane Hastie
              Hi Folks My feeling is that the role of the BA in Agile projects is to ensure that business value is delivered. We need to apply our skills and knowledge to
              Message 6 of 26 , Oct 7, 2009
              View Source
              • 0 Attachment

                Hi Folks

                 

                My feeling is that the role of the BA in Agile projects is to ensure that business value is delivered.  We need to apply our skills and knowledge to facilitating the communication of business needs into the project.  The “soft skills” are often more important than formal modelling and technical techniques. 

                 

                The Agile value “individuals and interactions over processes and tools” is a very important driver for analysts on Agile projects.  We probably will be involved in identifying requirements and building models to help understand the needs, however our primary role is to facilitate the communication on the project, shepherding the stories and ensuring the team has access to the knowledge they need when they need it.

                 

                The BABOK defines the Fundamental skills of business analysis but I feel there is not sufficient emphasis on the importance of these underlying interpersonal skills. 

                 

                I propose the A-BABOK should place a greater emphasis on these skills, and then look at the specific Agile practices and how the analyst applies their skills to assist the project on its mission to deliver business value.

                 

                We should have a chapter/area on the “soft skills”, talking about such things as (in no particular order)

                ·         Effective questioning

                ·         Active listening

                ·         Interviewing techniques

                ·         Facilitating workshops

                ·         Facilitating brainstorming sessions

                ·         Building trust

                ·         Evidencing personal integrity

                ·         Active and passive observation

                ·         Persuasion & influence

                ·         Understanding peoples motivations using techniques such as

                o   Maslow’s hierarchy of needs

                o   Emotional intelligence

                o   Social intelligence

                o   Transactional analysis

                o   NLP

                ·         (others, please…)

                 

                Then I propose we look at each of the common Agile practices and which of the analysis skills/techniques can be used to move the project forward.

                 

                How do others feel?

                 

                Cheers

                 

                Shane

                 

                From: Agile_BA_Requirements@... [mailto:Agile_BA_Requirements@...] On Behalf Of Kevin Brennan
                Sent: Wednesday, 7 October 2009 6:23 a.m.
                To: Agile_BA_Requirements@...
                Subject: Re: [Agile_BA_Requirements] Re: Nailing my colours to the mast

                 

                 

                One issue I'd like to throw out for discussion to this group. It often
                seems to me that a lot of the debate around the role of the BA in
                agile is predicated on the assumption that the BA's job is to write
                software specifications. I'm actually not at all sure that's true.
                There's no question that a lot of BAs do that, but even today our
                surveys are showing that the most critical and in-demand skills for
                business analysts are actually business-facing analysis skills, such
                as process modelling, business rule analysis, and so forth.

                So let me ask this: does Agile change the way that the business
                develops software? Or does it change how the business changes itself?
                ________________
                Kevin Brennan, CBAP, PMP
                VP, Professional Development
                International Institute of Business Analysis (IIBA®)
                "Helping Business Do Business Better"
                www.theiiba.org
                kevin.brennan@...
                (416) 233-8743

              • Chris Matts
                Dennis An important question and one that will resurface many times. I have been canvassing non-BA practitioners on this question. The common response so far
                Message 7 of 26 , Oct 8, 2009
                View Source
                • 0 Attachment
                  Dennis
                   
                  An important question and one that will resurface many times.
                   
                  I have been canvassing non-BA practitioners on this question. The common response so far is that we should focus on the BA capabilities, rather than a BA role. On Tuesday I was discussing this with a couple of Dev's whose view was that articulating the Business Analysis skills / practices etc. was very valuable. However, Agile practitioners are keen to avoid handovers and hence "specialist" roles. This means we can state the capabilities, and that one or others on the team would benefit from having those skills and say that a specialist BA is not required, however on some projects, the team may decide to have someone in a specialist BA role.
                   
                  I know this sounds a bit like politicing but I am keen to avoid us being attacked or disowned by the Agile Community. If we focus on the BA role rather than the BA capabilities that a team requires, there is a danger that the Agile anti-bodies will crawl out of the woodwork.
                   
                  That said, this is what we say when we represent the Agile Community view. We can allways state a personal view that from experience on many teams they are best served by specialist BA/QA teams.
                   
                  Thoughts
                   
                  Chris
                   
                   

                   
                  On Tue, Sep 29, 2009 at 1:08 PM, dennisstevens <dennis.stevens@...> wrote:
                   

                  Steve,

                  Great discussion. I agree with pretty much everything you said. I did want one clarification within the group.

                  Are we writing about the Business Analyst role or about Business Analysis capabilities? In your discussion below you say the XP team probably doesn't need someone to be the Business Analyst, but aren't there still situationally specific Business Analysis practices that would be useful to the XP team? As the project gets more complex some additional Business Analysis practices become appropriate. Even if these move to a Product Owner or some other role - they are business analysis capabilities aren't they?

                  My thought is that in emerging organizations, the Business Analyst may perform some of the Business Analyst capabilities, facilitate others, and some may belong to other roles. I think we need to be able to discuss the Business Analysis capabilities and practices as they might exist in an agile team and then provide some guidance on where they might be performed - regardless of the specific role.

                  Everything you said about the need to be a communicator, networker, facilitator, and builder of back channels is true regardless of what role performs the capabilities.

                  Dennis Stevens



                  --- In Agile_BA_Requirements@..., "Steve" <steve@...> wrote:
                  >
                  > Ok its late and I'm tired, but I'll toss my hat into the ring or raise my colours...
                  >
                  >
                  > First what is agile about? There are two basic assumptions behind agile, change happens and people trump process. In an environment of change, the utility of detailed plans and requirements is limited at best. Rather what we need is an adaptive approach. Ken Schwaber suggested software development is much more like an empirical process which that requires monitoring and adjusting in real-time. Real-time here means if its late, its wrong. Practices that delay our ability to monitor and adjust will lead to less than optimal results. The agile methods offer us light weight practices that enable us to quickly try something, obtain feedback and adjust. This in my opinion is really what agile is about, can I create a process for my project that allows me to make decisions about my project and take action in a timely manner.
                  >
                  > For a small project, a method like XP enables very fast decision cycles, wonderful for a project where things could be changing by the day. It is unlikely projects like these require a BA, and our enterprise here will have little utility to people involved in these kinds of projects.
                  >
                  > The BA role came about because as projects became more complex customers were not usually capable of understanding the technology behind the system and tech people were not usually capable of understanding the requirements. Then of course there is the problem of resolving competing interests. These problems did not go away with agile, so the BA still is an important role regardless of the method.
                  >
                  > But what does the BA do in an "agile" environment, write user stories? Well let me use the consultant's mantra "...it depends..." One thing I do know for sure is the BA needs to be much more of a communicator, networker, facilitator, and builder of back channels. The very best BAs already know this, and I strongly believe the best work that will come from this group is to place interpersonal skills at the very heart of the profession and the BA BOK. Right now I'm a little disappointed this topic is dealt with almost as an afterthought in the BA BOK.
                  >
                  > The practices available to the Agile BA will depend a lot on the organization they are part of. Here I want us to think very carefully about distinguishing practices as either governance or coordination. Governance are the immutable practices a project must comply with for either regulatory or internal policy requirements. Coordination is the set of practices we have in place that enable people to work effectively together. A mistake we commonly make is that we use our governance practices for coordination. For example, why do we produce an SRS? Is it because it is required by law or as internal corporate policy? Ok fine, but do our developers and testers need it to do their jobs? In fact could the SRS be getting in the way of the developers and testers doing their job effectively? In this situation, produce the SRS, but do not use it as the only mechanism for communicating requirements to the developers and testers.
                  >
                  >
                  > Now I'm going to step out into much more controversial territory, why the distance between Business Analysis and Quality Assurance? In many methods they are at opposite ends of the life-cycle and yet in many ways should be working closely together. The most accurate, and up to date specification for a system are the tests. In XP there are no quote requirements, just stories which are requirements place holders. The tests are the real requirements. Part of our work therefore must be to develop recommendations for practices that bring these two disciplines closer together.
                  >
                  >
                  > My bottom line, in my opinion I believe the BA will take the brunt of managing impedance mismatches between the different corporate process in place for the creation of software. The software development team itself may be "agile" drawing stories from their backlog and creating "potentially shippable product" every few weeks, but the surrounding organization may be much more traditional. The Agile BA are some of the people who will have to be flexible enough to satisfy the needs of all the processes involved in the creation of software.
                  >
                  > ok its bedtime for me, good night everyone
                  > Steve Adolph
                  >
                  > --- In Agile_BA_Requirements@..., "Shane Hastie" <shaneh@> wrote:
                  > >
                  > > Hi Folks
                  > >
                  > >
                  > >
                  > > I proposed we do this, so I'll start.
                  > >
                  > >
                  > >
                  > > I do like Chris's goal of "A comprehensive knowledge base for anyone
                  > > interested in Business Analysis and Requirements in Agile" - I would
                  > > expand Agile to "Agile software development", although these principles
                  > > apply to other types of projects we are focused on software development
                  > > (or are we??).
                  > >
                  > >
                  > >
                  > > My feeling is that the fundamental skills of business analysis remain
                  > > vitally important in Agile projects. These skills include
                  > >
                  > > * Communication
                  > >
                  > > * Facilitation
                  > >
                  > > * Investigation
                  > >
                  > > * Persuasion & influence
                  > >
                  > > * Presentation
                  > >
                  > > * Analysis (the ability to examine a problem and break it apart
                  > > into manageable bite-sized chunks)
                  > >
                  > > * Synthesis (the ability to visualise solutions and identify
                  > > components of those solutions)
                  > >
                  > > * Modelling - the ability to represent complex problems in
                  > > simple terms using effective representation techniques
                  > >
                  > > * Business process identification and business process
                  > > improvement understanding (IT projects are ALWAYS about
                  > > changing/improving business processes - computer systems are enablers of
                  > > business processes, not the reason for business processes)
                  > >
                  > > * Requirements identification
                  > >
                  > >
                  > >
                  > > There are a number of ways that the Analyst role changes (compared to
                  > > "traditional" approaches), including:
                  > >
                  > > * When we undertake analysis - there needs to be some (minimal)
                  > > analysis up front to understand the "shape" of the project, identifying
                  > > the user stories/use case briefs (or whatever your team calls them -
                  > > high level requirements which can be prioritised and estimated), and
                  > > then expanding the analysis to the detailed requirements (acceptance
                  > > criteria/detailed use case scenarios/feature details ...) on a Just in
                  > > Time basis. This conscious deferment of detail until it is really
                  > > needed (one iteration ahead at the most) prevents psychological lock-in
                  > > or fixation so we are prepared to accept change. One of the issues with
                  > > BDUF (even if it is done well) is the emotional investment in the work
                  > > done results in a natural resistance to change ("they don't like my baby
                  > > - waaaah")
                  > >
                  > > * We are not solely responsible for "gathering" requirements - I
                  > > see the Agile Analyst role as the "shepherd of stories" - like the
                  > > shepherd in the field (I come from New Zealand after all, we're an
                  > > agricultural economy) we have a responsibility to ensure that the herd
                  > > moves in the right direction, is protected and nurtured to grow and
                  > > mature but we don't own the sheep - we are an agent for the owner (the
                  > > business stakeholders who have the real need)
                  > >
                  > > * The analyst contributes to design as well and we need to have
                  > > an understanding of user interaction and interface design principles
                  > >
                  > > * We need to have basic testing skills ("thinking like a tester"
                  > > see
                  > > http://softwareeducation.wordpress.com/2009/09/17/36-testing-heuristics/
                  > > and http://testobsessed.com/2007/02/19/test-heuristics-cheat-sheet/ )
                  > > to help identify test cases and expose opportunities for improving the
                  > > product
                  > >
                  > >
                  > >
                  > > I wrote an article for InfoQ which explains my thinking - it can be
                  > > found at
                  > > http://www.softed.com/Resources/Docs/The-Role-of-the-Analyst-in-Agile-Pr
                  > > ojects.pdf
                  > >
                  > >
                  > >
                  > > That's my thinking in a few (???) words J
                  > >
                  > >
                  > >
                  > > I look forward to reading others' views
                  > >
                  > >
                  > >
                  > > Cheers
                  > >
                  > >
                  > >
                  > > Shane
                  > >
                  > >
                  > >
                  > > Shane Hastie, MIM, CBAP
                  > >
                  > > Chief Knowledge Engineer
                  > >
                  > > Software Education Associates Ltd
                  > >
                  > > DDI +64 4 924 1270 From Australia 1800 145 952
                  > >
                  > > Switchboard +64 4 568 7806
                  > >
                  > > NZ Mobile +64 21 590 255 Australia Mobile +61 450 604 413
                  > >
                  > > Web www.softed.com <http://www.softed.com/>
                  > >
                  > >
                  > >
                  > > Learn with the experts
                  > >
                  > >
                  > >
                  > >
                  > >
                  > > Join us for the world's best requirements training - "Mastering the
                  > > Requirements Process" with James and Suzanne Robertson. Courses are
                  > > running in Melbourne & Canberra (4 Nov), Wellington (9 Nov), Auckland
                  > > (16 Nov), Sydney (30 Nov) and Christchurch (9 Dec). Call now for more
                  > > details or visit www.softed.com <http://www.softed.com>
                  > >
                  >




                  --
                  Regards

                  Chris Matts
                • dennisstevens
                  Chris, With regard to 1. Agile methods: o Focus on Iterative and Incremental delivery (which) o Drive transparency – in status of the project, viability of
                  Message 8 of 26 , Oct 8, 2009
                  View Source
                  • 0 Attachment
                    Chris,

                    With regard to 1.

                    Agile methods:
                    o Focus on Iterative and Incremental delivery (which)
                    o Drive transparency – in status of the project, viability of the product, and performance of the team (which)
                    o Compels learning – both about the product and the delivery capabilities (which)
                    o Facilitates risk reduction through responding to change associated with learning throughout the project

                    With regard to 2.

                    I am writing a paper I will post here for review tomorrow.

                    With regard to 7.

                    Agile delivery methods may be moving outside of software development – but this is not the case most of the time. Our ability to define capabilities and create Business Analysis techniques that support Agile software development is sufficient for dramatic improvements in Agile software delivery (and therefore the strategy execution of most companies). Solving this problem will establish a strategic "seat at the table" for Business Analysts. A broader holistic vision of Agile will be difficult to get right the first time. I suggest we focus on Business Analysis Capabilities as they support Agile software development in this first edition. With success of this edition and broader uptake of Agile methods we can come back and fine tune the capabilities to address the broader holistic impact of Agile beyond software development.

                    Dennis
                    --- In Agile_BA_Requirements@..., Chris Matts <chris.matts@...> wrote:
                    >
                    > For some reason I'm compelled to focus on the value and the outputs.
                    >
                    > So Imagine I'm someone coming to the Agile BABOK (C) ;-) What questions do I
                    > want the answer to.
                    >
                    > 1. What is Agile? ( I assume people have heard of Agile, but they may not
                    > know what it is about )
                    >
                    > 2. How does Agile affect business analysis? / What are the implications of
                    > Agile on Business Analysis. / Why and How is Business Analysis different to
                    > traditional approaches.
                    >
                    > 3. What are the techniques / tools people use on Agile Projects ( Experience
                    > Reports )? ( and references... books, web-sites etc. )
                    >
                    > 4. What skills do I need to do Business Analysis on an Agile Project.?
                    >
                    > 5. How do people currently doing analysis on agile projects rate the tools /
                    > references / skills. etc.?
                    >
                    > 6. How do people rate the experience reports?
                    >
                    > 7. Does Agile Business Analysis extend beyond software development?
                    >
                    > For 5 and 6, I'm thinking of the Amazon.com Rating system with "Founder" /
                    > "Top 100" users who write reviews and rate them.
                    > Are there other questions business analysts would ask?
                    >
                    > Chris
                    >
                    >
                    > On Tue, Oct 6, 2009 at 9:41 PM, greyskinnedboy
                    > <david.morris@...>wrote:
                    >
                    > >
                    > >
                    > > Another crucial question, Steve, thanks - are we look at the role or
                    > > capabilities of business analysis.
                    > >
                    > > My principle would be to look at the capabilities, whoever does them.
                    > > Remember the delivery team is often termed as cross-functional and
                    > > multi-disciplinary, which often means members will wear different hats at
                    > > different times. But, heck, we do that today ... business analysts are often
                    > > standing in for project managers, running tests, etc. ... but that is not
                    > > business analysis.
                    > >
                    > > This was one of the principles behind development of the Business Analysis
                    > > Body of Knowledge.
                    > >
                    > > Cheers,
                    > > David.
                    > >
                    > >
                    > >
                    >
                    >
                    >
                    > --
                    > Regards
                    >
                    > Chris Matts
                    >
                  • dennisstevens
                    I clearly agree. Focusing on capabilities enables the BA role without alienating our target audience by going against the Agile concept of specializing
                    Message 9 of 26 , Oct 8, 2009
                    View Source
                    • 0 Attachment
                      I clearly agree. Focusing on capabilities enables the BA role without alienating our target audience by going against the Agile concept of specializing generalists. I understand the fear is that the role of BA (the IIBA constituent community) is somehow diminished through this.

                      Contrarily, I believe that the BA role becomes more strategic and valuable on mature Agile teams. The subset of BA activities that end up being assimilated into the team is minimal. These involve tasks like detailed elicitation and communication of requirements where an intermediary does not add value in the transaction. Many of the remaining (higher value) BA tasks - Business Analysis Planning and Monitoring, Enterprise Analysis, Solution Assessment, Requirements Analysis (prioritization, organization, verification, validation), Requirements Management (up to communicate requirements) - are still in the Product Owner domain, and will be supported on mature Agile teams by business analyst specialists.

                      We should provide guidance (maybe through emerging best practices or experience reports) about different models of allocating capabilities to team members.

                      Dennis

                      --- In Agile_BA_Requirements@..., Chris Matts <chris.matts@...> wrote:
                      >
                      > Dennis
                      >
                      > An important question and one that will resurface many times.
                      >
                      > I have been canvassing non-BA practitioners on this question. The common
                      > response so far is that we should focus on the BA capabilities, rather than
                      > a BA role. On Tuesday I was discussing this with a couple of Dev's whose
                      > view was that articulating the Business Analysis skills / practices etc. was
                      > very valuable. However, Agile practitioners are keen to avoid handovers and
                      > hence "specialist" roles. This means we can state the capabilities, and that
                      > one or others on the team would benefit from having those skills and say
                      > that a specialist BA is not required, however on some projects, the team may
                      > decide to have someone in a specialist BA role.
                      >
                      > I know this sounds a bit like politicing but I am keen to avoid us being
                      > attacked or disowned by the Agile Community. If we focus on the BA role
                      > rather than the BA capabilities that a team requires, there is a danger that
                      > the Agile anti-bodies will crawl out of the woodwork.
                      >
                      > That said, this is what we say when we represent the Agile Community view.
                      > We can allways state a personal view that from experience on many teams they
                      > are best served by specialist BA/QA teams.
                      >
                      > Thoughts
                      >
                      > Chris
                      >
                      >
                      >
                      >
                      > On Tue, Sep 29, 2009 at 1:08 PM, dennisstevens <dennis.stevens@...>wrote:
                      >
                      > >
                      > >
                      > > Steve,
                      > >
                      > > Great discussion. I agree with pretty much everything you said. I did want
                      > > one clarification within the group.
                      > >
                      > > Are we writing about the Business Analyst role or about Business Analysis
                      > > capabilities? In your discussion below you say the XP team probably doesn't
                      > > need someone to be the Business Analyst, but aren't there still
                      > > situationally specific Business Analysis practices that would be useful to
                      > > the XP team? As the project gets more complex some additional Business
                      > > Analysis practices become appropriate. Even if these move to a Product Owner
                      > > or some other role - they are business analysis capabilities aren't they?
                      > >
                      > > My thought is that in emerging organizations, the Business Analyst may
                      > > perform some of the Business Analyst capabilities, facilitate others, and
                      > > some may belong to other roles. I think we need to be able to discuss the
                      > > Business Analysis capabilities and practices as they might exist in an agile
                      > > team and then provide some guidance on where they might be performed -
                      > > regardless of the specific role.
                      > >
                      > > Everything you said about the need to be a communicator, networker,
                      > > facilitator, and builder of back channels is true regardless of what role
                      > > performs the capabilities.
                      > >
                      > > Dennis Stevens
                      > >
                      > >
                      > > --- In Agile_BA_Requirements@...<Agile_BA_Requirements%40yahoogroups.co.uk>,
                      > > "Steve" <steve@> wrote:
                      > > >
                      > > > Ok its late and I'm tired, but I'll toss my hat into the ring or raise my
                      > > colours...
                      > > >
                      > > >
                      > > > First what is agile about? There are two basic assumptions behind agile,
                      > > change happens and people trump process. In an environment of change, the
                      > > utility of detailed plans and requirements is limited at best. Rather what
                      > > we need is an adaptive approach. Ken Schwaber suggested software development
                      > > is much more like an empirical process which that requires monitoring and
                      > > adjusting in real-time. Real-time here means if its late, its wrong.
                      > > Practices that delay our ability to monitor and adjust will lead to less
                      > > than optimal results. The agile methods offer us light weight practices that
                      > > enable us to quickly try something, obtain feedback and adjust. This in my
                      > > opinion is really what agile is about, can I create a process for my project
                      > > that allows me to make decisions about my project and take action in a
                      > > timely manner.
                      > > >
                      > > > For a small project, a method like XP enables very fast decision cycles,
                      > > wonderful for a project where things could be changing by the day. It is
                      > > unlikely projects like these require a BA, and our enterprise here will have
                      > > little utility to people involved in these kinds of projects.
                      > > >
                      > > > The BA role came about because as projects became more complex customers
                      > > were not usually capable of understanding the technology behind the system
                      > > and tech people were not usually capable of understanding the requirements.
                      > > Then of course there is the problem of resolving competing interests. These
                      > > problems did not go away with agile, so the BA still is an important role
                      > > regardless of the method.
                      > > >
                      > > > But what does the BA do in an "agile" environment, write user stories?
                      > > Well let me use the consultant's mantra "...it depends..." One thing I do
                      > > know for sure is the BA needs to be much more of a communicator, networker,
                      > > facilitator, and builder of back channels. The very best BAs already know
                      > > this, and I strongly believe the best work that will come from this group is
                      > > to place interpersonal skills at the very heart of the profession and the BA
                      > > BOK. Right now I'm a little disappointed this topic is dealt with almost as
                      > > an afterthought in the BA BOK.
                      > > >
                      > > > The practices available to the Agile BA will depend a lot on the
                      > > organization they are part of. Here I want us to think very carefully about
                      > > distinguishing practices as either governance or coordination. Governance
                      > > are the immutable practices a project must comply with for either regulatory
                      > > or internal policy requirements. Coordination is the set of practices we
                      > > have in place that enable people to work effectively together. A mistake we
                      > > commonly make is that we use our governance practices for coordination. For
                      > > example, why do we produce an SRS? Is it because it is required by law or as
                      > > internal corporate policy? Ok fine, but do our developers and testers need
                      > > it to do their jobs? In fact could the SRS be getting in the way of the
                      > > developers and testers doing their job effectively? In this situation,
                      > > produce the SRS, but do not use it as the only mechanism for communicating
                      > > requirements to the developers and testers.
                      > > >
                      > > >
                      > > > Now I'm going to step out into much more controversial territory, why the
                      > > distance between Business Analysis and Quality Assurance? In many methods
                      > > they are at opposite ends of the life-cycle and yet in many ways should be
                      > > working closely together. The most accurate, and up to date specification
                      > > for a system are the tests. In XP there are no quote requirements, just
                      > > stories which are requirements place holders. The tests are the real
                      > > requirements. Part of our work therefore must be to develop recommendations
                      > > for practices that bring these two disciplines closer together.
                      > > >
                      > > >
                      > > > My bottom line, in my opinion I believe the BA will take the brunt of
                      > > managing impedance mismatches between the different corporate process in
                      > > place for the creation of software. The software development team itself may
                      > > be "agile" drawing stories from their backlog and creating "potentially
                      > > shippable product" every few weeks, but the surrounding organization may be
                      > > much more traditional. The Agile BA are some of the people who will have to
                      > > be flexible enough to satisfy the needs of all the processes involved in the
                      > > creation of software.
                      > > >
                      > > > ok its bedtime for me, good night everyone
                      > > > Steve Adolph
                      > > >
                      > > > --- In Agile_BA_Requirements@...<Agile_BA_Requirements%40yahoogroups.co.uk>,
                      > > "Shane Hastie" <shaneh@> wrote:
                      > > > >
                      > > > > Hi Folks
                      > > > >
                      > > > >
                      > > > >
                      > > > > I proposed we do this, so I'll start.
                      > > > >
                      > > > >
                      > > > >
                      > > > > I do like Chris's goal of "A comprehensive knowledge base for anyone
                      > > > > interested in Business Analysis and Requirements in Agile" - I would
                      > > > > expand Agile to "Agile software development", although these principles
                      > > > > apply to other types of projects we are focused on software development
                      > > > > (or are we??).
                      > > > >
                      > > > >
                      > > > >
                      > > > > My feeling is that the fundamental skills of business analysis remain
                      > > > > vitally important in Agile projects. These skills include
                      > > > >
                      > > > > * Communication
                      > > > >
                      > > > > * Facilitation
                      > > > >
                      > > > > * Investigation
                      > > > >
                      > > > > * Persuasion & influence
                      > > > >
                      > > > > * Presentation
                      > > > >
                      > > > > * Analysis (the ability to examine a problem and break it apart
                      > > > > into manageable bite-sized chunks)
                      > > > >
                      > > > > * Synthesis (the ability to visualise solutions and identify
                      > > > > components of those solutions)
                      > > > >
                      > > > > * Modelling - the ability to represent complex problems in
                      > > > > simple terms using effective representation techniques
                      > > > >
                      > > > > * Business process identification and business process
                      > > > > improvement understanding (IT projects are ALWAYS about
                      > > > > changing/improving business processes - computer systems are enablers
                      > > of
                      > > > > business processes, not the reason for business processes)
                      > > > >
                      > > > > * Requirements identification
                      > > > >
                      > > > >
                      > > > >
                      > > > > There are a number of ways that the Analyst role changes (compared to
                      > > > > "traditional" approaches), including:
                      > > > >
                      > > > > * When we undertake analysis - there needs to be some (minimal)
                      > > > > analysis up front to understand the "shape" of the project, identifying
                      > > > > the user stories/use case briefs (or whatever your team calls them -
                      > > > > high level requirements which can be prioritised and estimated), and
                      > > > > then expanding the analysis to the detailed requirements (acceptance
                      > > > > criteria/detailed use case scenarios/feature details ...) on a Just in
                      > > > > Time basis. This conscious deferment of detail until it is really
                      > > > > needed (one iteration ahead at the most) prevents psychological lock-in
                      > > > > or fixation so we are prepared to accept change. One of the issues with
                      > > > > BDUF (even if it is done well) is the emotional investment in the work
                      > > > > done results in a natural resistance to change ("they don't like my
                      > > baby
                      > > > > - waaaah")
                      > > > >
                      > > > > * We are not solely responsible for "gathering" requirements - I
                      > > > > see the Agile Analyst role as the "shepherd of stories" - like the
                      > > > > shepherd in the field (I come from New Zealand after all, we're an
                      > > > > agricultural economy) we have a responsibility to ensure that the herd
                      > > > > moves in the right direction, is protected and nurtured to grow and
                      > > > > mature but we don't own the sheep - we are an agent for the owner (the
                      > > > > business stakeholders who have the real need)
                      > > > >
                      > > > > * The analyst contributes to design as well and we need to have
                      > > > > an understanding of user interaction and interface design principles
                      > > > >
                      > > > > * We need to have basic testing skills ("thinking like a tester"
                      > > > > see
                      > > > >
                      > > http://softwareeducation.wordpress.com/2009/09/17/36-testing-heuristics/
                      > > > > and http://testobsessed.com/2007/02/19/test-heuristics-cheat-sheet/ )
                      > > > > to help identify test cases and expose opportunities for improving the
                      > > > > product
                      > > > >
                      > > > >
                      > > > >
                      > > > > I wrote an article for InfoQ which explains my thinking - it can be
                      > > > > found at
                      > > > >
                      > > http://www.softed.com/Resources/Docs/The-Role-of-the-Analyst-in-Agile-Pr
                      > > > > ojects.pdf
                      > > > >
                      > > > >
                      > > > >
                      > > > > That's my thinking in a few (???) words J
                      > > > >
                      > > > >
                      > > > >
                      > > > > I look forward to reading others' views
                      > > > >
                      > > > >
                      > > > >
                      > > > > Cheers
                      > > > >
                      > > > >
                      > > > >
                      > > > > Shane
                      > > > >
                      > > > >
                      > > > >
                      > > > > Shane Hastie, MIM, CBAP
                      > > > >
                      > > > > Chief Knowledge Engineer
                      > > > >
                      > > > > Software Education Associates Ltd
                      > > > >
                      > > > > DDI +64 4 924 1270 From Australia 1800 145 952
                      > > > >
                      > > > > Switchboard +64 4 568 7806
                      > > > >
                      > > > > NZ Mobile +64 21 590 255 Australia Mobile +61 450 604 413
                      > > > >
                      > > > > Web www.softed.com <http://www.softed.com/>
                      > > > >
                      > > > >
                      > > > >
                      > > > > Learn with the experts
                      > > > >
                      > > > >
                      > > > >
                      > > > >
                      > > > >
                      > > > > Join us for the world's best requirements training - "Mastering the
                      > > > > Requirements Process" with James and Suzanne Robertson. Courses are
                      > > > > running in Melbourne & Canberra (4 Nov), Wellington (9 Nov), Auckland
                      > > > > (16 Nov), Sydney (30 Nov) and Christchurch (9 Dec). Call now for more
                      > > > > details or visit www.softed.com <http://www.softed.com>
                      > > > >
                      > > >
                      > >
                      > >
                      > >
                      >
                      >
                      >
                      > --
                      > Regards
                      >
                      > Chris Matts
                      >
                    • Kevin Brennan
                      ... Obviously I m a strong believer in the BA role, but I think it s worth pointing out in this context that the BABOK Guide actually is intended to define
                      Message 10 of 26 , Oct 8, 2009
                      View Source
                      • 0 Attachment
                        On 2009-10-08, at 4:43 AM, Chris Matts wrote:

                        > I have been canvassing non-BA practitioners on this question. The
                        > common response so far is that we should focus on the BA
                        > capabilities, rather than a BA role. On Tuesday I was discussing
                        > this with a couple of Dev's whose view was that articulating the
                        > Business Analysis skills / practices etc. was very valuable.
                        > However, Agile practitioners are keen to avoid handovers and hence
                        > "specialist" roles. This means we can state the capabilities, and
                        > that one or others on the team would benefit from having those
                        > skills and say that a specialist BA is not required, however on some
                        > projects, the team may decide to have someone in a specialist BA role.
                        >
                        > I know this sounds a bit like politicing but I am keen to avoid us
                        > being attacked or disowned by the Agile Community. If we focus on
                        > the BA role rather than the BA capabilities that a team requires,
                        > there is a danger that the Agile anti-bodies will crawl out of the
                        > woodwork.
                        >
                        > That said, this is what we say when we represent the Agile Community
                        > view. We can allways state a personal view that from experience on
                        > many teams they are best served by specialist BA/QA teams.

                        Obviously I"m a strong believer in the BA role, but I think it's worth
                        pointing out in this context that the BABOK Guide actually is intended
                        to define "what business analysis is" instead of defining a job. I
                        think it's perfectly reasonable to take the same approach here and say
                        "this is what business analysis is in an Agile environment" without
                        getting caught up in whether that work is done by a specific person on
                        the team.

                        There were a couple of reasons we did that. One was the issue Chris
                        identified above. The other was the exact opposite: we had a lot of
                        cases where people would argue that "I'm a BA and I do X therefore X
                        is part of business analysis". Because BAs in real life are often the
                        team utility player (for instance, in my career I've pretty much done
                        everything except coding and I know BAs who do that too) that would
                        have meant that everything in a project was business analysis! That
                        didn't seem like a good starting point, so we went back to basics,
                        worked out a definition of business analysis, and then asked what were
                        the essential elements of the role.
                        ________________
                        Kevin Brennan, CBAP, PMP
                        VP, Professional Development
                        International Institute of Business Analysis (IIBA®)
                        "Helping Business Do Business Better"
                        www.theiiba.org
                        kevin.brennan@...
                        (416) 233-8743
                      • Chris
                        Hi All No doubt I will be wibbling on about Feature Injection. The best way to read it is in comic book form. Send me your address if you would like copies.
                        Message 11 of 26 , Oct 9, 2009
                        View Source
                        • 0 Attachment
                          Hi All

                          No doubt I will be wibbling on about Feature Injection. The best way to read it is in comic book form. 

                          Send me your address if you would like copies. The postage costs more than the comic so 10 copies cost about the same as 1. I'll pick up the tab in the interests of international love and harmony.

                          Chris 

                          Sent from my iPhone

                          On 8 Oct 2009, at 19:06, Kevin Brennan <kevin.brennan@...> wrote:

                           

                          On 2009-10-08, at 4:43 AM, Chris Matts wrote:

                          > I have been canvassing non-BA practitioners on this question. The
                          > common response so far is that we should focus on the BA
                          > capabilities, rather than a BA role. On Tuesday I was discussing
                          > this with a couple of Dev's whose view was that articulating the
                          > Business Analysis skills / practices etc. was very valuable.
                          > However, Agile practitioners are keen to avoid handovers and hence
                          > "specialist" roles. This means we can state the capabilities, and
                          > that one or others on the team would benefit from having those
                          > skills and say that a specialist BA is not required, however on some
                          > projects, the team may decide to have someone in a specialist BA role.
                          >
                          > I know this sounds a bit like politicing but I am keen to avoid us
                          > being attacked or disowned by the Agile Community. If we focus on
                          > the BA role rather than the BA capabilities that a team requires,
                          > there is a danger that the Agile anti-bodies will crawl out of the
                          > woodwork.
                          >
                          > That said, this is what we say when we represent the Agile Community
                          > view. We can allways state a personal view that from experience on
                          > many teams they are best served by specialist BA/QA teams.

                          Obviously I"m a strong believer in the BA role, but I think it's worth
                          pointing out in this context that the BABOK Guide actually is intended
                          to define "what business analysis is" instead of defining a job. I
                          think it's perfectly reasonable to take the same approach here and say
                          "this is what business analysis is in an Agile environment" without
                          getting caught up in whether that work is done by a specific person on
                          the team.

                          There were a couple of reasons we did that. One was the issue Chris
                          identified above. The other was the exact opposite: we had a lot of
                          cases where people would argue that "I'm a BA and I do X therefore X
                          is part of business analysis". Because BAs in real life are often the
                          team utility player (for instance, in my career I've pretty much done
                          everything except coding and I know BAs who do that too) that would
                          have meant that everything in a project was business analysis! That
                          didn't seem like a good starting point, so we went back to basics,
                          worked out a definition of business analysis, and then asked what were
                          the essential elements of the role.
                          ____________ ____
                          Kevin Brennan, CBAP, PMP
                          VP, Professional Development
                          International Institute of Business Analysis (IIBA®)
                          "Helping Business Do Business Better"
                          www.theiiba. org
                          kevin.brennan@theiiba.org
                          (416) 233-8743

                        • Steve
                          Hmm, this is a topic I know little about, so I ll comment on it :-) Agile, that is agile as far as the software community is concerned is a set of light weight
                          Message 12 of 26 , Oct 10, 2009
                          View Source
                          • 0 Attachment
                            Hmm, this is a topic I know little about, so I'll comment on it :-)

                            Agile, that is agile as far as the software community is concerned is a set of light weight practices for creating software. if you listen to some of the most ardent agilitas you may get the impression they software development team or IT group is about to lead the organization into a brave new future. However, success through agility is a very old idea and as software developers (a group which I include myself in) are late to the party. Many companies serve as poster children for the agile organization, one of my favourites is Southwest Airlines - for a good treatment of this read Gittell's book "The Southwest Way"

                            Today, most in the agile software development community are very focused on the software development process, so most of the practices and ideas circulating in the agile community are focused on changing the way the business creates software. Many are beginning to realize an "impedance mismatch" between business processes and the software development processes as the software group adopts agile practices. So IMHO the body of knowledge in the agile software development community is about how we create software. There are arguments the business should follow the software development group's lead, but in many organizations this like the tail wagging the dog. The business is not at the service of the software development group, the software development group is at the service of the business.

                            That said, the concepts and practices emerging from the agile software development community can have an influence on how business analyst participate in business process engineering. Agile practices were developed as strategies for coping with change and uncertainty, I am quite sure these are environmental factors that affect BPR just as they affect software development.

                            Steve Adolph

                            --- In Agile_BA_Requirements@..., Kevin Brennan <kevin.brennan@...> wrote:
                            >
                            > One issue I'd like to throw out for discussion to this group. It often
                            > seems to me that a lot of the debate around the role of the BA in
                            > agile is predicated on the assumption that the BA's job is to write
                            > software specifications. I'm actually not at all sure that's true.
                            > There's no question that a lot of BAs do that, but even today our
                            > surveys are showing that the most critical and in-demand skills for
                            > business analysts are actually business-facing analysis skills, such
                            > as process modelling, business rule analysis, and so forth.
                            >
                            > So let me ask this: does Agile change the way that the business
                            > develops software? Or does it change how the business changes itself?
                            > ________________
                            > Kevin Brennan, CBAP, PMP
                            > VP, Professional Development
                            > International Institute of Business Analysis (IIBA®)
                            > "Helping Business Do Business Better"
                            > www.theiiba.org
                            > kevin.brennan@...
                            > (416) 233-8743
                            >
                          • chrisjmatts1968
                            Steve I like your description of Agile. One minor nit pick is that I think the IT department is a partner of the business rather than a service. ( I do not
                            Message 13 of 26 , Oct 12, 2009
                            View Source
                            • 0 Attachment
                              Steve

                              I like your description of Agile. One minor nit pick is that I think the IT department is a partner of the business rather than a service. ( I do not like the idea of servile relationships as I think it leads to wrong stuff happening ).

                              We all have our own ways of understanding Agile but I think the description that we give in the wiki needs to be straight forward and unambiguous rather than abstract. This could well be the first port of call for a number of people interested in Agile.

                              As we write our description, we should perhaps have one ( or many personas ) that we write for. Personally I imagine a farm boy with his barn full of horses in smallville in the mid-west who has to go to work in a medical insurance company to pay for fodder and straw. If he can understand.......

                              Thoughts?

                              Chris

                              --- In Agile_BA_Requirements@..., "Steve" <steve@...> wrote:
                              >
                              > Hmm, this is a topic I know little about, so I'll comment on it :-)
                              >
                              > Agile, that is agile as far as the software community is concerned is a set of light weight practices for creating software. if you listen to some of the most ardent agilitas you may get the impression they software development team or IT group is about to lead the organization into a brave new future. However, success through agility is a very old idea and as software developers (a group which I include myself in) are late to the party. Many companies serve as poster children for the agile organization, one of my favourites is Southwest Airlines - for a good treatment of this read Gittell's book "The Southwest Way"
                              >
                              > Today, most in the agile software development community are very focused on the software development process, so most of the practices and ideas circulating in the agile community are focused on changing the way the business creates software. Many are beginning to realize an "impedance mismatch" between business processes and the software development processes as the software group adopts agile practices. So IMHO the body of knowledge in the agile software development community is about how we create software. There are arguments the business should follow the software development group's lead, but in many organizations this like the tail wagging the dog. The business is not at the service of the software development group, the software development group is at the service of the business.
                              >
                              > That said, the concepts and practices emerging from the agile software development community can have an influence on how business analyst participate in business process engineering. Agile practices were developed as strategies for coping with change and uncertainty, I am quite sure these are environmental factors that affect BPR just as they affect software development.
                              >
                              > Steve Adolph
                              >
                              > --- In Agile_BA_Requirements@..., Kevin Brennan <kevin.brennan@> wrote:
                              > >
                              > > One issue I'd like to throw out for discussion to this group. It often
                              > > seems to me that a lot of the debate around the role of the BA in
                              > > agile is predicated on the assumption that the BA's job is to write
                              > > software specifications. I'm actually not at all sure that's true.
                              > > There's no question that a lot of BAs do that, but even today our
                              > > surveys are showing that the most critical and in-demand skills for
                              > > business analysts are actually business-facing analysis skills, such
                              > > as process modelling, business rule analysis, and so forth.
                              > >
                              > > So let me ask this: does Agile change the way that the business
                              > > develops software? Or does it change how the business changes itself?
                              > > ________________
                              > > Kevin Brennan, CBAP, PMP
                              > > VP, Professional Development
                              > > International Institute of Business Analysis (IIBA®)
                              > > "Helping Business Do Business Better"
                              > > www.theiiba.org
                              > > kevin.brennan@
                              > > (416) 233-8743
                              > >
                              >
                            • Chris Matts
                              Hi All Whilst we wait for the feedback from the work that others have done previously with the IIBA and PMI, I would like to kick off our discussions again.
                              Message 14 of 26 , Nov 27, 2009
                              View Source
                              • 0 Attachment
                                Hi All

                                Whilst we wait for the feedback from the work that others have done previously with the IIBA and PMI, I would like to kick off our discussions again. This is especially the case now that we have more members on the group.

                                I would like to propose the following structure for each page of the wiki.

                                1. A short description of the subject. Assume the reader is new to the subject so keep fairly straight forward and short. We should direct readers toward quality references rather than rewrite them.

                                2. References.

                                3. Experience Reports / Opinion of practitioners. I feel that a number of the excellent posts in this thread on Agile would find their way into the opinion section.

                                As an Aunt Sally for "What is Agile"

                                The Agile Movement started when a number of proponents of lightweight methodologies came together in Snowbird in 2001 to sign the Agile Manifesto < link to manifesto >.

                                When people refer to Agile, they often mean the two most popular Agile Methodologies which are eXtreme Programming <link> and Scrum <link>. However there are many others such as DSDM <link>, EVO <Link>, Kanban <link>, Lean <link> etc.

                                The Agile Manifesto acted as a call to arms for software professionals to "continue to improve the way we do software development by doing it.". Local groups of practitioners met to discuss how they really did software rather than than the theoretical approach they had been taught. Over twenety Yahoo groups exist which discuss many aspects of methodologies or tools and practices. In addition, a thriving conference scene sprang up globally where software professionals could come together from further afield to discuss "Agile". The Agile Alliance coordinates coordinates and supports this activity. In particular the Agile Alliance organises the main USA based conference known as Agile 20xx <link>

                                Most Agile Practitioners regard the Agile Manifesto as a historical document which does not reflect current Agile thinking. They all have a different view of what Agile means, although most agree that we value approaches that work in practice rather than those that should theoretically be optimal.

                                The main principles of Agile are....

                                Frequent delivery of business value....
                                Supported by automating repeated tasks....
                                And a humistic approach that leverages the strengths of team members.

                                References...
                                Agile Software Dev by A Cockburn <link>
                                Agile Eco Systems by J. Highsmith <link>
                                History of Iterative Dev by Craig Larman <link>

                                Experience Reports / Opinion <link>
                                links to our own view on the subject.

                                Thoughts?

                                Once we agree a format, I'd like to start a couple of threads. One to finish "What is Agile" and "What is the effect of Agile on Business Analysis"

                                Thoughts?


                                Chris
                                On Sat, Oct 10, 2009 at 7:56 PM, Steve <steve@...> wrote:
                                 

                                Hmm, this is a topic I know little about, so I'll comment on it :-)

                                Agile, that is agile as far as the software community is concerned is a set of light weight practices for creating software. if you listen to some of the most ardent agilitas you may get the impression they software development team or IT group is about to lead the organization into a brave new future. However, success through agility is a very old idea and as software developers (a group which I include myself in) are late to the party. Many companies serve as poster children for the agile organization, one of my favourites is Southwest Airlines - for a good treatment of this read Gittell's book "The Southwest Way"

                                Today, most in the agile software development community are very focused on the software development process, so most of the practices and ideas circulating in the agile community are focused on changing the way the business creates software. Many are beginning to realize an "impedance mismatch" between business processes and the software development processes as the software group adopts agile practices. So IMHO the body of knowledge in the agile software development community is about how we create software. There are arguments the business should follow the software development group's lead, but in many organizations this like the tail wagging the dog. The business is not at the service of the software development group, the software development group is at the service of the business.

                                That said, the concepts and practices emerging from the agile software development community can have an influence on how business analyst participate in business process engineering. Agile practices were developed as strategies for coping with change and uncertainty, I am quite sure these are environmental factors that affect BPR just as they affect software development.

                                Steve Adolph

                                --- In Agile_BA_Requirements@..., Kevin Brennan <kevin.brennan@...> wrote:
                                >
                                > One issue I'd like to throw out for discussion to this group. It often
                                > seems to me that a lot of the debate around the role of the BA in
                                > agile is predicated on the assumption that the BA's job is to write
                                > software specifications. I'm actually not at all sure that's true.
                                > There's no question that a lot of BAs do that, but even today our
                                > surveys are showing that the most critical and in-demand skills for
                                > business analysts are actually business-facing analysis skills, such
                                > as process modelling, business rule analysis, and so forth.
                                >
                                > So let me ask this: does Agile change the way that the business
                                > develops software? Or does it change how the business changes itself?
                                > ________________
                                > Kevin Brennan, CBAP, PMP
                                > VP, Professional Development
                                > International Institute of Business Analysis (IIBA®)
                                > "Helping Business Do Business Better"
                                > www.theiiba.org
                                > kevin.brennan@...
                                > (416) 233-8743
                                >




                                --
                                Regards

                                Chris Matts
                              • Kent McDonald
                                Format makes sense. With regards to: Once we agree a format, I d like to start a couple of threads. One to finish What is Agile and What is the effect of
                                Message 15 of 26 , Nov 27, 2009
                                View Source
                                • 0 Attachment
                                  Format makes sense.

                                  With regards to:
                                  Once we agree a format, I'd like to start a couple of threads. One to finish "What is Agile" and "What is the effect of Agile on Business Analysis"

                                  Another thread that may be interesting is "What is Business Analysis".  Like Agile, and beauty, it may be in the eye of the beholder.

                                  Kent J. McDonald
                                  kent@...

                                  Collaborate | Iterate | Serve the Team | Consider Context
                                  Practice Excellence| Decide Wisely | Reflect and Adapt | Deliver Value



                                  On Fri, Nov 27, 2009 at 4:05 PM, Chris Matts <chris.matts@...> wrote:
                                   

                                  Hi All

                                  Whilst we wait for the feedback from the work that others have done previously with the IIBA and PMI, I would like to kick off our discussions again. This is especially the case now that we have more members on the group.

                                  I would like to propose the following structure for each page of the wiki.

                                  1. A short description of the subject. Assume the reader is new to the subject so keep fairly straight forward and short. We should direct readers toward quality references rather than rewrite them.

                                  2. References.

                                  3. Experience Reports / Opinion of practitioners. I feel that a number of the excellent posts in this thread on Agile would find their way into the opinion section.

                                  As an Aunt Sally for "What is Agile"

                                  The Agile Movement started when a number of proponents of lightweight methodologies came together in Snowbird in 2001 to sign the Agile Manifesto < link to manifesto >.

                                  When people refer to Agile, they often mean the two most popular Agile Methodologies which are eXtreme Programming <link> and Scrum <link>. However there are many others such as DSDM <link>, EVO <Link>, Kanban <link>, Lean <link> etc.

                                  The Agile Manifesto acted as a call to arms for software professionals to "continue to improve the way we do software development by doing it.". Local groups of practitioners met to discuss how they really did software rather than than the theoretical approach they had been taught. Over twenety Yahoo groups exist which discuss many aspects of methodologies or tools and practices. In addition, a thriving conference scene sprang up globally where software professionals could come together from further afield to discuss "Agile". The Agile Alliance coordinates coordinates and supports this activity. In particular the Agile Alliance organises the main USA based conference known as Agile 20xx <link>

                                  Most Agile Practitioners regard the Agile Manifesto as a historical document which does not reflect current Agile thinking. They all have a different view of what Agile means, although most agree that we value approaches that work in practice rather than those that should theoretically be optimal.

                                  The main principles of Agile are....

                                  Frequent delivery of business value....
                                  Supported by automating repeated tasks....
                                  And a humistic approach that leverages the strengths of team members.

                                  References...
                                  Agile Software Dev by A Cockburn <link>
                                  Agile Eco Systems by J. Highsmith <link>
                                  History of Iterative Dev by Craig Larman <link>

                                  Experience Reports / Opinion <link>
                                  links to our own view on the subject.

                                  Thoughts?

                                  Once we agree a format, I'd like to start a couple of threads. One to finish "What is Agile" and "What is the effect of Agile on Business Analysis"

                                  Thoughts?


                                  Chris

                                  On Sat, Oct 10, 2009 at 7:56 PM, Steve <steve@...> wrote:
                                   

                                  Hmm, this is a topic I know little about, so I'll comment on it :-)

                                  Agile, that is agile as far as the software community is concerned is a set of light weight practices for creating software. if you listen to some of the most ardent agilitas you may get the impression they software development team or IT group is about to lead the organization into a brave new future. However, success through agility is a very old idea and as software developers (a group which I include myself in) are late to the party. Many companies serve as poster children for the agile organization, one of my favourites is Southwest Airlines - for a good treatment of this read Gittell's book "The Southwest Way"

                                  Today, most in the agile software development community are very focused on the software development process, so most of the practices and ideas circulating in the agile community are focused on changing the way the business creates software. Many are beginning to realize an "impedance mismatch" between business processes and the software development processes as the software group adopts agile practices. So IMHO the body of knowledge in the agile software development community is about how we create software. There are arguments the business should follow the software development group's lead, but in many organizations this like the tail wagging the dog. The business is not at the service of the software development group, the software development group is at the service of the business.

                                  That said, the concepts and practices emerging from the agile software development community can have an influence on how business analyst participate in business process engineering. Agile practices were developed as strategies for coping with change and uncertainty, I am quite sure these are environmental factors that affect BPR just as they affect software development.

                                  Steve Adolph

                                  --- In Agile_BA_Requirements@..., Kevin Brennan <kevin.brennan@...> wrote:
                                  >
                                  > One issue I'd like to throw out for discussion to this group. It often
                                  > seems to me that a lot of the debate around the role of the BA in
                                  > agile is predicated on the assumption that the BA's job is to write
                                  > software specifications. I'm actually not at all sure that's true.
                                  > There's no question that a lot of BAs do that, but even today our
                                  > surveys are showing that the most critical and in-demand skills for
                                  > business analysts are actually business-facing analysis skills, such
                                  > as process modelling, business rule analysis, and so forth.
                                  >
                                  > So let me ask this: does Agile change the way that the business
                                  > develops software? Or does it change how the business changes itself?
                                  > ________________
                                  > Kevin Brennan, CBAP, PMP
                                  > VP, Professional Development
                                  > International Institute of Business Analysis (IIBA®)
                                  > "Helping Business Do Business Better"
                                  > www.theiiba.org
                                  > kevin.brennan@...
                                  > (416) 233-8743
                                  >




                                  --
                                  Regards

                                  Chris Matts

                                • Chris Matts
                                  Kent Good catch Chris ... -- Regards Chris Matts Kent Good catch Chris On Sat, Nov 28, 2009 at 2:40 AM, Kent McDonald wrote:  
                                  Message 16 of 26 , Nov 27, 2009
                                  View Source
                                  • 0 Attachment
                                    Kent

                                    Good catch

                                    Chris

                                    On Sat, Nov 28, 2009 at 2:40 AM, Kent McDonald <kentjmcdonald@...> wrote:
                                     

                                    Format makes sense.

                                    With regards to:


                                    Once we agree a format, I'd like to start a couple of threads. One to finish "What is Agile" and "What is the effect of Agile on Business Analysis"

                                    Another thread that may be interesting is "What is Business Analysis".  Like Agile, and beauty, it may be in the eye of the beholder.


                                    Kent J. McDonald
                                    kent@...

                                    Collaborate | Iterate | Serve the Team | Consider Context
                                    Practice Excellence| Decide Wisely | Reflect and Adapt | Deliver Value



                                    On Fri, Nov 27, 2009 at 4:05 PM, Chris Matts <chris.matts@...> wrote:
                                     

                                    Hi All

                                    Whilst we wait for the feedback from the work that others have done previously with the IIBA and PMI, I would like to kick off our discussions again. This is especially the case now that we have more members on the group.

                                    I would like to propose the following structure for each page of the wiki.

                                    1. A short description of the subject. Assume the reader is new to the subject so keep fairly straight forward and short. We should direct readers toward quality references rather than rewrite them.

                                    2. References.

                                    3. Experience Reports / Opinion of practitioners. I feel that a number of the excellent posts in this thread on Agile would find their way into the opinion section.

                                    As an Aunt Sally for "What is Agile"

                                    The Agile Movement started when a number of proponents of lightweight methodologies came together in Snowbird in 2001 to sign the Agile Manifesto < link to manifesto >.

                                    When people refer to Agile, they often mean the two most popular Agile Methodologies which are eXtreme Programming <link> and Scrum <link>. However there are many others such as DSDM <link>, EVO <Link>, Kanban <link>, Lean <link> etc.

                                    The Agile Manifesto acted as a call to arms for software professionals to "continue to improve the way we do software development by doing it.". Local groups of practitioners met to discuss how they really did software rather than than the theoretical approach they had been taught. Over twenety Yahoo groups exist which discuss many aspects of methodologies or tools and practices. In addition, a thriving conference scene sprang up globally where software professionals could come together from further afield to discuss "Agile". The Agile Alliance coordinates coordinates and supports this activity. In particular the Agile Alliance organises the main USA based conference known as Agile 20xx <link>

                                    Most Agile Practitioners regard the Agile Manifesto as a historical document which does not reflect current Agile thinking. They all have a different view of what Agile means, although most agree that we value approaches that work in practice rather than those that should theoretically be optimal.

                                    The main principles of Agile are....

                                    Frequent delivery of business value....
                                    Supported by automating repeated tasks....
                                    And a humistic approach that leverages the strengths of team members.

                                    References...
                                    Agile Software Dev by A Cockburn <link>
                                    Agile Eco Systems by J. Highsmith <link>
                                    History of Iterative Dev by Craig Larman <link>

                                    Experience Reports / Opinion <link>
                                    links to our own view on the subject.

                                    Thoughts?

                                    Once we agree a format, I'd like to start a couple of threads. One to finish "What is Agile" and "What is the effect of Agile on Business Analysis"

                                    Thoughts?


                                    Chris

                                    On Sat, Oct 10, 2009 at 7:56 PM, Steve <steve@...> wrote:
                                     

                                    Hmm, this is a topic I know little about, so I'll comment on it :-)

                                    Agile, that is agile as far as the software community is concerned is a set of light weight practices for creating software. if you listen to some of the most ardent agilitas you may get the impression they software development team or IT group is about to lead the organization into a brave new future. However, success through agility is a very old idea and as software developers (a group which I include myself in) are late to the party. Many companies serve as poster children for the agile organization, one of my favourites is Southwest Airlines - for a good treatment of this read Gittell's book "The Southwest Way"

                                    Today, most in the agile software development community are very focused on the software development process, so most of the practices and ideas circulating in the agile community are focused on changing the way the business creates software. Many are beginning to realize an "impedance mismatch" between business processes and the software development processes as the software group adopts agile practices. So IMHO the body of knowledge in the agile software development community is about how we create software. There are arguments the business should follow the software development group's lead, but in many organizations this like the tail wagging the dog. The business is not at the service of the software development group, the software development group is at the service of the business.

                                    That said, the concepts and practices emerging from the agile software development community can have an influence on how business analyst participate in business process engineering. Agile practices were developed as strategies for coping with change and uncertainty, I am quite sure these are environmental factors that affect BPR just as they affect software development.

                                    Steve Adolph

                                    --- In Agile_BA_Requirements@..., Kevin Brennan <kevin.brennan@...> wrote:
                                    >
                                    > One issue I'd like to throw out for discussion to this group. It often
                                    > seems to me that a lot of the debate around the role of the BA in
                                    > agile is predicated on the assumption that the BA's job is to write
                                    > software specifications. I'm actually not at all sure that's true.
                                    > There's no question that a lot of BAs do that, but even today our
                                    > surveys are showing that the most critical and in-demand skills for
                                    > business analysts are actually business-facing analysis skills, such
                                    > as process modelling, business rule analysis, and so forth.
                                    >
                                    > So let me ask this: does Agile change the way that the business
                                    > develops software? Or does it change how the business changes itself?
                                    > ________________
                                    > Kevin Brennan, CBAP, PMP
                                    > VP, Professional Development
                                    > International Institute of Business Analysis (IIBA®)
                                    > "Helping Business Do Business Better"
                                    > www.theiiba.org
                                    > kevin.brennan@...
                                    > (416) 233-8743
                                    >




                                    --
                                    Regards

                                    Chris Matts




                                    --
                                    Regards

                                    Chris Matts
                                  • Ellen Gottesdiener
                                    Wiki structure sounds good. Is someone going to act as producer/coordinator/delivery facilitator for this work? I think David is going to act as that for the
                                    Message 17 of 26 , Nov 30, 2009
                                    View Source
                                    • 0 Attachment

                                      Wiki structure sounds good.

                                      Is someone going to act as producer/coordinator/delivery facilitator for this work?

                                      I think David is going to act as that for the agile-IIBA addendum stuff, but I’m unclear about the wiki side …

                                      ~ ellen


                                      From: Agile_BA_Requirements@... [mailto:Agile_BA_Requirements@...] On Behalf Of Chris Matts
                                      Sent: Saturday, November 28, 2009 2:05 AM
                                      To: Agile_BA_Requirements@...
                                      Subject: Re: [Agile_BA_Requirements] Re: Nailing my colours to the mast

                                       

                                       

                                      Kent

                                      Good catch

                                      Chris

                                      On Sat, Nov 28, 2009 at 2:40 AM, Kent McDonald <kentjmcdonald@ gmail.com> wrote:

                                       

                                      Format makes sense.

                                      With regards to:


                                      Once we agree a format, I'd like to start a couple of threads. One to finish "What is Agile" and "What is the effect of Agile on Business Analysis"

                                      Another thread that may be interesting is "What is Business Analysis".  Like Agile, and beauty, it may be in the eye of the beholder.



                                      Kent J. McDonald
                                      kent@kentmcdonald. com

                                      Collaborate | Iterate | Serve the Team | Consider Context
                                      Practice Excellence| Decide Wisely | Reflect and Adapt | Deliver Value


                                      On Fri, Nov 27, 2009 at 4:05 PM, Chris Matts <chris.matts@ gmail.com> wrote:

                                       

                                      Hi All

                                      Whilst we wait for the feedback from the work that others have done previously with the IIBA and PMI, I would like to kick off our discussions again. This is especially the case now that we have more members on the group.

                                      I would like to propose the following structure for each page of the wiki.

                                      1. A short description of the subject. Assume the reader is new to the subject so keep fairly straight forward and short. We should direct readers toward quality references rather than rewrite them.

                                      2. References.

                                      3. Experience Reports / Opinion of practitioners. I feel that a number of the excellent posts in this thread on Agile would find their way into the opinion section.

                                      As an Aunt Sally for "What is Agile"

                                      The Agile Movement started when a number of proponents of lightweight methodologies came together in Snowbird in 2001 to sign the Agile Manifesto < link to manifesto >.

                                      When people refer to Agile, they often mean the two most popular Agile Methodologies which are eXtreme Programming <link> and Scrum <link>. However there are many others such as DSDM <link>, EVO <Link>, Kanban <link>, Lean <link> etc.

                                      The Agile Manifesto acted as a call to arms for software professionals to "continue to improve the way we do software development by doing it.". Local groups of practitioners met to discuss how they really did software rather than than the theoretical approach they had been taught. Over twenety Yahoo groups exist which discuss many aspects of methodologies or tools and practices. In addition, a thriving conference scene sprang up globally where software professionals could come together from further afield to discuss "Agile". The Agile Alliance coordinates coordinates and supports this activity. In particular the Agile Alliance organises the main USA based conference known as Agile 20xx <link>

                                      Most Agile Practitioners regard the Agile Manifesto as a historical document which does not reflect current Agile thinking. They all have a different view of what Agile means, although most agree that we value approaches that work in practice rather than those that should theoretically be optimal.

                                      The main principles of Agile are....

                                      Frequent delivery of business value....
                                      Supported by automating repeated tasks....
                                      And a humistic approach that leverages the strengths of team members.

                                      References.. .
                                      Agile Software Dev by A Cockburn <link>
                                      Agile Eco Systems by J. Highsmith <link>
                                      History of Iterative Dev by Craig Larman <link>

                                      Experience Reports / Opinion <link>
                                      links to our own view on the subject.

                                      Thoughts?

                                      Once we agree a format, I'd like to start a couple of threads. One to finish "What is Agile" and "What is the effect of Agile on Business Analysis"

                                      Thoughts?


                                      Chris

                                      On Sat, Oct 10, 2009 at 7:56 PM, Steve <steve@wsaconsulting .com> wrote:

                                       

                                      Hmm, this is a topic I know little about, so I'll comment on it :-)

                                      Agile, that is agile as far as the software community is concerned is a set of light weight practices for creating software. if you listen to some of the most ardent agilitas you may get the impression they software development team or IT group is about to lead the organization into a brave new future. However, success through agility is a very old idea and as software developers (a group which I include myself in) are late to the party. Many companies serve as poster children for the agile organization, one of my favourites is Southwest Airlines - for a good treatment of this read Gittell's book "The Southwest Way"

                                      Today, most in the agile software development community are very focused on the software development process, so most of the practices and ideas circulating in the agile community are focused on changing the way the business creates software. Many are beginning to realize an "impedance mismatch" between business processes and the software development processes as the software group adopts agile practices. So IMHO the body of knowledge in the agile software development community is about how we create software. There are arguments the business should follow the software development group's lead, but in many organizations this like the tail wagging the dog. The business is not at the service of the software development group, the software development group is at the service of the business.

                                      That said, the concepts and practices emerging from the agile software development community can have an influence on how business analyst participate in business process engineering. Agile practices were developed as strategies for coping with change and uncertainty, I am quite sure these are environmental factors that affect BPR just as they affect software development.

                                      Steve Adolph


                                      --- In Agile_BA_Requiremen ts@yahoogroups. co.uk, Kevin Brennan <kevin.brennan@ ...> wrote:
                                      >

                                      > One issue I'd like to throw out for discussion to this group. It often
                                      > seems to me that a lot of the debate around the role of the BA in
                                      > agile is predicated on the assumption that the BA's job is to write
                                      > software specifications. I'm actually not at all sure that's true.
                                      > There's no question that a lot of BAs do that, but even today our
                                      > surveys are showing that the most critical and in-demand skills for
                                      > business analysts are actually business-facing analysis skills, such
                                      > as process modelling, business rule analysis, and so forth.
                                      >
                                      > So let me ask this: does Agile change the way that the business
                                      > develops software? Or does it change how the business changes itself?
                                      > ____________ ____
                                      > Kevin Brennan, CBAP, PMP
                                      > VP, Professional Development
                                      > International Institute of Business Analysis (IIBA®)
                                      > "Helping Business Do Business Better"
                                      > www.theiiba. org

                                      > kevin.brennan@ ...
                                      > (416) 233-8743
                                      >



                                      --
                                      Regards

                                      Chris Matts

                                       




                                      --
                                      Regards

                                      Chris Matts

                                      No virus found in this incoming message.
                                      Checked by AVG - www.avg.com
                                      Version: 9.0.709 / Virus Database: 270.14.85/2532 - Release Date: 11/28/09 02:45:00

                                    • greyskinnedboy
                                      Good to have that reinforced. We ve got to keep in mind that the audiences for what we come up with could equally well be agilists that want or need to know
                                      Message 18 of 26 , Dec 1, 2009
                                      View Source
                                      • 0 Attachment
                                        Good to have that reinforced.

                                        We've got to keep in mind that the audiences for what we come up with could equally well be agilists that want or need to know what value can be delivered through business analysis -- as well as informing business analysts as to the value from following agile practices, and then guiding them as to what that means for their own role.

                                        Would be useful to work up some personas to reinforce the various roles that make up our audience -- whilst we're developing these additional resources.

                                        David.


                                        --- In Agile_BA_Requirements@..., Chris Matts <chris.matts@...> wrote:
                                        >
                                        > Kent
                                        >
                                        > Good catch
                                        >
                                        > Chris
                                        >
                                        > On Sat, Nov 28, 2009 at 2:40 AM, Kent McDonald <kentjmcdonald@...>wrote:
                                        >
                                        > >
                                        > >
                                        > > Format makes sense.
                                        > >
                                        > > With regards to:
                                        > >
                                        > > Once we agree a format, I'd like to start a couple of threads. One to
                                        > > finish "What is Agile" and "What is the effect of Agile on Business
                                        > > Analysis"
                                        > >
                                        > > Another thread that may be interesting is "What is Business Analysis".
                                        > > Like Agile, and beauty, it may be in the eye of the beholder.
                                        > >
                                        > >
                                        > > Kent J. McDonald
                                        > > kent@...
                                        > >
                                        > > Collaborate | Iterate | Serve the Team | Consider Context
                                        > > Practice Excellence| Decide Wisely | Reflect and Adapt | Deliver Value
                                        > >
                                        > >
                                        > >
                                        > > On Fri, Nov 27, 2009 at 4:05 PM, Chris Matts <chris.matts@...>wrote:
                                        > >
                                        > >>
                                        > >>
                                        > >> Hi All
                                        > >>
                                        > >> Whilst we wait for the feedback from the work that others have done
                                        > >> previously with the IIBA and PMI, I would like to kick off our discussions
                                        > >> again. This is especially the case now that we have more members on the
                                        > >> group.
                                        > >>
                                        > >> I would like to propose the following structure for each page of the wiki.
                                        > >>
                                        > >> 1. A short description of the subject. Assume the reader is new to the
                                        > >> subject so keep fairly straight forward and short. We should direct readers
                                        > >> toward quality references rather than rewrite them.
                                        > >>
                                        > >> 2. References.
                                        > >>
                                        > >> 3. Experience Reports / Opinion of practitioners. I feel that a number of
                                        > >> the excellent posts in this thread on Agile would find their way into the
                                        > >> opinion section.
                                        > >>
                                        > >> As an Aunt Sally for "What is Agile"
                                        > >>
                                        > >> The Agile Movement started when a number of proponents of lightweight
                                        > >> methodologies came together in Snowbird in 2001 to sign the Agile Manifesto
                                        > >> < link to manifesto >.
                                        > >>
                                        > >> When people refer to Agile, they often mean the two most popular Agile
                                        > >> Methodologies which are eXtreme Programming <link> and Scrum <link>. However
                                        > >> there are many others such as DSDM <link>, EVO <Link>, Kanban <link>, Lean
                                        > >> <link> etc.
                                        > >>
                                        > >> The Agile Manifesto acted as a call to arms for software professionals to
                                        > >> "continue to improve the way we do software development by doing it.". Local
                                        > >> groups of practitioners met to discuss how they really did software rather
                                        > >> than than the theoretical approach they had been taught. Over twenety Yahoo
                                        > >> groups exist which discuss many aspects of methodologies or tools and
                                        > >> practices. In addition, a thriving conference scene sprang up globally where
                                        > >> software professionals could come together from further afield to discuss
                                        > >> "Agile". The Agile Alliance coordinates coordinates and supports this
                                        > >> activity. In particular the Agile Alliance organises the main USA based
                                        > >> conference known as Agile 20xx <link>
                                        > >>
                                        > >> Most Agile Practitioners regard the Agile Manifesto as a historical
                                        > >> document which does not reflect current Agile thinking. They all have a
                                        > >> different view of what Agile means, although most agree that we value
                                        > >> approaches that work in practice rather than those that should theoretically
                                        > >> be optimal.
                                        > >>
                                        > >> The main principles of Agile are....
                                        > >>
                                        > >> Frequent delivery of business value....
                                        > >> Supported by automating repeated tasks....
                                        > >> And a humistic approach that leverages the strengths of team members.
                                        > >>
                                        > >> References...
                                        > >> Agile Software Dev by A Cockburn <link>
                                        > >> Agile Eco Systems by J. Highsmith <link>
                                        > >> History of Iterative Dev by Craig Larman <link>
                                        > >>
                                        > >> Experience Reports / Opinion <link>
                                        > >> links to our own view on the subject.
                                        > >>
                                        > >> Thoughts?
                                        > >>
                                        > >> Once we agree a format, I'd like to start a couple of threads. One to
                                        > >> finish "What is Agile" and "What is the effect of Agile on Business
                                        > >> Analysis"
                                        > >>
                                        > >> Thoughts?
                                        > >>
                                        > >>
                                        > >> Chris
                                        > >> On Sat, Oct 10, 2009 at 7:56 PM, Steve <steve@...> wrote:
                                        > >>
                                        > >>>
                                        > >>>
                                        > >>> Hmm, this is a topic I know little about, so I'll comment on it :-)
                                        > >>>
                                        > >>> Agile, that is agile as far as the software community is concerned is a
                                        > >>> set of light weight practices for creating software. if you listen to some
                                        > >>> of the most ardent agilitas you may get the impression they software
                                        > >>> development team or IT group is about to lead the organization into a brave
                                        > >>> new future. However, success through agility is a very old idea and as
                                        > >>> software developers (a group which I include myself in) are late to the
                                        > >>> party. Many companies serve as poster children for the agile organization,
                                        > >>> one of my favourites is Southwest Airlines - for a good treatment of this
                                        > >>> read Gittell's book "The Southwest Way"
                                        > >>>
                                        > >>> Today, most in the agile software development community are very focused
                                        > >>> on the software development process, so most of the practices and ideas
                                        > >>> circulating in the agile community are focused on changing the way the
                                        > >>> business creates software. Many are beginning to realize an "impedance
                                        > >>> mismatch" between business processes and the software development processes
                                        > >>> as the software group adopts agile practices. So IMHO the body of knowledge
                                        > >>> in the agile software development community is about how we create software.
                                        > >>> There are arguments the business should follow the software development
                                        > >>> group's lead, but in many organizations this like the tail wagging the dog.
                                        > >>> The business is not at the service of the software development group, the
                                        > >>> software development group is at the service of the business.
                                        > >>>
                                        > >>> That said, the concepts and practices emerging from the agile software
                                        > >>> development community can have an influence on how business analyst
                                        > >>> participate in business process engineering. Agile practices were developed
                                        > >>> as strategies for coping with change and uncertainty, I am quite sure these
                                        > >>> are environmental factors that affect BPR just as they affect software
                                        > >>> development.
                                        > >>>
                                        > >>> Steve Adolph
                                        > >>>
                                        > >>> --- In Agile_BA_Requirements@...<Agile_BA_Requirements%40yahoogroups.co.uk>,
                                        > >>> Kevin Brennan <kevin.brennan@> wrote:
                                        > >>> >
                                        > >>> > One issue I'd like to throw out for discussion to this group. It often
                                        > >>> > seems to me that a lot of the debate around the role of the BA in
                                        > >>> > agile is predicated on the assumption that the BA's job is to write
                                        > >>> > software specifications. I'm actually not at all sure that's true.
                                        > >>> > There's no question that a lot of BAs do that, but even today our
                                        > >>> > surveys are showing that the most critical and in-demand skills for
                                        > >>> > business analysts are actually business-facing analysis skills, such
                                        > >>> > as process modelling, business rule analysis, and so forth.
                                        > >>> >
                                        > >>> > So let me ask this: does Agile change the way that the business
                                        > >>> > develops software? Or does it change how the business changes itself?
                                        > >>> > ________________
                                        > >>> > Kevin Brennan, CBAP, PMP
                                        > >>> > VP, Professional Development
                                        > >>> > International Institute of Business Analysis (IIBA®)
                                        > >>> > "Helping Business Do Business Better"
                                        > >>> > www.theiiba.org
                                        > >>> > kevin.brennan@
                                        > >>> > (416) 233-8743
                                        > >>> >
                                        > >>>
                                        > >>>
                                        > >>
                                        > >>
                                        > >> --
                                        > >> Regards
                                        > >>
                                        > >> Chris Matts
                                        > >>
                                        > >
                                        > >
                                        > >
                                        >
                                        >
                                        >
                                        > --
                                        > Regards
                                        >
                                        > Chris Matts
                                        >
                                      • Chris Matts
                                        Dear All I have started to move this to the wiki. A number of links are missing. Could people check it and amend as they see fit. In addition, please move some
                                        Message 19 of 26 , Dec 6, 2009
                                        View Source
                                        • 0 Attachment
                                          Dear All

                                          I have started to move this to the wiki. A number of links are missing. Could people check it and amend as they see fit.

                                          In addition, please move some of the excellent posts in this thread to the "Our Own Opinions" section of the "What is Agile" page.

                                          Regards

                                          Chris

                                          On Fri, Nov 27, 2009 at 10:05 PM, Chris Matts <chris.matts@...> wrote:
                                          Hi All

                                          Whilst we wait for the feedback from the work that others have done previously with the IIBA and PMI, I would like to kick off our discussions again. This is especially the case now that we have more members on the group.

                                          I would like to propose the following structure for each page of the wiki.

                                          1. A short description of the subject. Assume the reader is new to the subject so keep fairly straight forward and short. We should direct readers toward quality references rather than rewrite them.

                                          2. References.

                                          3. Experience Reports / Opinion of practitioners. I feel that a number of the excellent posts in this thread on Agile would find their way into the opinion section.

                                          As an Aunt Sally for "What is Agile"

                                          The Agile Movement started when a number of proponents of lightweight methodologies came together in Snowbird in 2001 to sign the Agile Manifesto < link to manifesto >.

                                          When people refer to Agile, they often mean the two most popular Agile Methodologies which are eXtreme Programming <link> and Scrum <link>. However there are many others such as DSDM <link>, EVO <Link>, Kanban <link>, Lean <link> etc.

                                          The Agile Manifesto acted as a call to arms for software professionals to "continue to improve the way we do software development by doing it.". Local groups of practitioners met to discuss how they really did software rather than than the theoretical approach they had been taught. Over twenety Yahoo groups exist which discuss many aspects of methodologies or tools and practices. In addition, a thriving conference scene sprang up globally where software professionals could come together from further afield to discuss "Agile". The Agile Alliance coordinates coordinates and supports this activity. In particular the Agile Alliance organises the main USA based conference known as Agile 20xx <link>

                                          Most Agile Practitioners regard the Agile Manifesto as a historical document which does not reflect current Agile thinking. They all have a different view of what Agile means, although most agree that we value approaches that work in practice rather than those that should theoretically be optimal.

                                          The main principles of Agile are....

                                          Frequent delivery of business value....
                                          Supported by automating repeated tasks....
                                          And a humistic approach that leverages the strengths of team members.

                                          References...
                                          Agile Software Dev by A Cockburn <link>
                                          Agile Eco Systems by J. Highsmith <link>
                                          History of Iterative Dev by Craig Larman <link>

                                          Experience Reports / Opinion <link>
                                          links to our own view on the subject.

                                          Thoughts?

                                          Once we agree a format, I'd like to start a couple of threads. One to finish "What is Agile" and "What is the effect of Agile on Business Analysis"

                                          Thoughts?


                                          Chris

                                          On Sat, Oct 10, 2009 at 7:56 PM, Steve <steve@...> wrote:
                                           

                                          Hmm, this is a topic I know little about, so I'll comment on it :-)

                                          Agile, that is agile as far as the software community is concerned is a set of light weight practices for creating software. if you listen to some of the most ardent agilitas you may get the impression they software development team or IT group is about to lead the organization into a brave new future. However, success through agility is a very old idea and as software developers (a group which I include myself in) are late to the party. Many companies serve as poster children for the agile organization, one of my favourites is Southwest Airlines - for a good treatment of this read Gittell's book "The Southwest Way"

                                          Today, most in the agile software development community are very focused on the software development process, so most of the practices and ideas circulating in the agile community are focused on changing the way the business creates software. Many are beginning to realize an "impedance mismatch" between business processes and the software development processes as the software group adopts agile practices. So IMHO the body of knowledge in the agile software development community is about how we create software. There are arguments the business should follow the software development group's lead, but in many organizations this like the tail wagging the dog. The business is not at the service of the software development group, the software development group is at the service of the business.

                                          That said, the concepts and practices emerging from the agile software development community can have an influence on how business analyst participate in business process engineering. Agile practices were developed as strategies for coping with change and uncertainty, I am quite sure these are environmental factors that affect BPR just as they affect software development.

                                          Steve Adolph

                                          --- In Agile_BA_Requirements@..., Kevin Brennan <kevin.brennan@...> wrote:
                                          >
                                          > One issue I'd like to throw out for discussion to this group. It often
                                          > seems to me that a lot of the debate around the role of the BA in
                                          > agile is predicated on the assumption that the BA's job is to write
                                          > software specifications. I'm actually not at all sure that's true.
                                          > There's no question that a lot of BAs do that, but even today our
                                          > surveys are showing that the most critical and in-demand skills for
                                          > business analysts are actually business-facing analysis skills, such
                                          > as process modelling, business rule analysis, and so forth.
                                          >
                                          > So let me ask this: does Agile change the way that the business
                                          > develops software? Or does it change how the business changes itself?
                                          > ________________
                                          > Kevin Brennan, CBAP, PMP
                                          > VP, Professional Development
                                          > International Institute of Business Analysis (IIBA®)
                                          > "Helping Business Do Business Better"
                                          > www.theiiba.org
                                          > kevin.brennan@...
                                          > (416) 233-8743
                                          >




                                          --
                                          Regards

                                          Chris Matts



                                          --
                                          Regards

                                          Chris Matts
                                        Your message has been successfully submitted and would be delivered to recipients shortly.