PMP? Bring us your toughest Agile Questions.

You asked. Isaac answered…

Below you’ll find answers to the top questions submitted by traditional project managers and PMPs. Your peers generated more than 6,000 votes and we had a lively discussion on August 23rd. You can listen to the webinar archive for all the details.

Note that we won’t be answering any additional questions, but we’re likely to use this format of “crowd-sourced” webinar questions again in the future. So stay tuned!

I'm considering Agile, but I want to know...

You've used all your votes and won't be able to post a new idea, but you can still search and comment on existing ideas.

There are two ways to get more votes:

  • When an admin closes an idea you've voted on, you'll get your votes back from that idea.
  • You can remove your votes from an open idea you support.
  • To see ideas you have already voted on, select the "My feedback" filter and select "My open ideas".
(thinking…)

Enter your idea and we'll search to see if someone has already suggested it.

If a similar idea already exists, you can vote and comment on it.

If it doesn't exist, you can post your idea so others can vote on it.

Enter your idea and we'll search to see if someone has already suggested it.

  1. How do traditional roles change?

    We have a variety of specialty departments involved with our software development process. They want to know how their traditional roles will change. What's different for Business Analysts, Architects, QA, development staff and Project Managers?

    Merged with:

    What is the role of a traditional BA in an Agile team?

    Is there a need for the BA role in an Agile team or would the other members of the team take over the BA responsibilities? If there is a role what is it? What should a BA focus on in an Agile team? What are the areas where a BA's skills…

    600 votes
    Vote
    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      You have left! (?) (thinking…)
      6 comments  ·  Flag idea as inappropriate…  ·  Admin →
      started  ·  imontgomeryimontgomery responded

      I generally try to avoid mapping traditional titles to agile roles. I’ve seen far too many organizations cripple their agile teams by uniformly assigning those with a given traditional title to an agile role they assume is roughly equivalent. Some people are wildly successful; others are abject failures; while still others are left wondering if they still have a job – since agile doesn’t a role for their title.

      I find it much more valuable and healthy to talk about the skills, capabilities and inclinations of individuals who tend to be successful and add value in each of the Scrum roles (I use the Scrum role names simply because they tend to be the most recognized); and what traditional titles I’ve most often found those people holding.

      You might be a Product Owner if:
      If you are good at working with stakeholders; managing expectations and balancing competing priorities; if you’ve…

    • How do I work with distributed, offshore teams?

      I have developers in India and Russia, architects in Chicago, business stakeholders and BA's in New York, and testers in Mexico.

      Will agile work in such a highly distributed environment?

      538 votes
      Vote
      Sign in
      Check!
      (thinking…)
      Reset
      or sign in with
      • facebook
      • google
        Password icon
        I agree to the terms of service
        Signed in as (Sign out)
        You have left! (?) (thinking…)
        1 comment  ·  Flag idea as inappropriate…  ·  Admin →
        started  ·  imontgomeryimontgomery responded

        There is this rumor out there that Agile requires co-located teams, that if you have people in distributed around the country and/or around the world, that agile won’t work. That’s just patently not true.

        What agile DOES says is: “the most efficient and effective method of conveying information to and within a development is face-to-face communication” and that “Business people and developers must work together daily throughout the project.”

        Effective communication and collaboration is what agile asks for.

        Now, it’s certainly easiest to do so when your teams are co-located – when high quality communication and collaboration can happen naturally, through face-to-face interactions. But if your teams aren’t co-located, it doesn’t eliminate or reduce the need – it just makes it harder.

        And the challenges we face in creating highly collaborative environments is not limited to geography. Strong personal relationships and trust are at least as important to effective collaboration…

      • How do I work with waterfall teams?

        If I have other (internal, partner, third-party, customer) teams that I'm working with...and they are following a waterfall process...how does our Agile team work with them? How are dependencies and milestones coordinated?

        Merged with:

        In a PMO, how do you report on a Program that has teams and vendors using both Agile and Waterfall?

        Posted in PMP? Bring us your toughest Agile Questions.

        When a program has multiple vendors or teams and some of them are Agile and working in Sprints and some of them are traditional waterfall, how do you handle reporting and metrics?

        Jennifer on Aug 5, 2011…

        536 votes
        Vote
        Sign in
        Check!
        (thinking…)
        Reset
        or sign in with
        • facebook
        • google
          Password icon
          I agree to the terms of service
          Signed in as (Sign out)
          You have left! (?) (thinking…)
          3 comments  ·  Flag idea as inappropriate…  ·  Admin →
          started  ·  imontgomeryimontgomery responded

          So probably not surprising, but the key to working effectively with other team – be they waterfall, agile or otherwise – is collaboration. We’ve got to communicate and work together. And I find a barrier to effective communication between agile and waterfall teams is often a lack of trust and understanding.

          So lets start with a little understanding – agile teams and waterfall teams (good waterfall teams) aren’t as really as diametrically opposed as we sometimes make them out to be.

          PMI’s Project Management Body of Knowledge (PMBOK) describes the 4 process groups of a project phase as Initiating, Planning, Executing, and Closing. A project may be done in 1 phase, or split into a series of phases – delivering the project in multiple increments or releases. Agile’s 5 levels of agile planning closely mirrors the PMBOK model.

          5 Levels of Agile Planning:
          - Vision
          - Roadmap
          -…

        • How do I fund and initiate Agile Projects?

          We're used to operating in a fixed scope environment. The business funds projects based on a set of requirements that detail what they will get in return. How do we support this funding model when we move to Agile?

          Merged with Idea created Aug 5, 2011 by S Myrow

          How do you write up an 'Agile' contract so the client knows what they're spending up front?

          If you have a client who has to answer to a board in terms of departmental spending and they NEED to know what the project will cost up front......how can you create a contract…

          523 votes
          Vote
          Sign in
          Check!
          (thinking…)
          Reset
          or sign in with
          • facebook
          • google
            Password icon
            I agree to the terms of service
            Signed in as (Sign out)
            You have left! (?) (thinking…)
            3 comments  ·  Flag idea as inappropriate…  ·  Admin →
            started  ·  imontgomeryimontgomery responded

            I’m struck by how often I hear this sort of question. There seems to be a pervasive belief that agile teams don’t plan beyond the next iteration. That on any project longer than an iteration, we can’t tell our customers and business partners what they’re going to get, when they’ll get it, or how much it’ll cost. Which leads to a very reasonable question – “but how can I get the business to fund the project, if I can’t give them the basic information they need to decide if its a sound investment?”

            Exactly.

            But an agile team not only can give them these answers, but can give them answers they can believe in.

            And it all starts with the agile team and 3 key attributes that every agile team has:
            - A Backlog
            - A Cost
            - A Velocity

            Backlog:
            A team’s backlog consists of the business valued work…

          • How to do Agile when we mostly do maintenance/sustainment/support?

            Agile examples often seem to be new projects or larger development efforts. What if I'm on a maintenance team supporting MANY applications with lots of incoming bugs and small user stories? Iteration Planning seems difficult, we have MANY customers/Product Owners, and frequent bug interuptions.

            414 votes
            Vote
            Sign in
            Check!
            (thinking…)
            Reset
            or sign in with
            • facebook
            • google
              Password icon
              I agree to the terms of service
              Signed in as (Sign out)
              You have left! (?) (thinking…)
              0 comments  ·  Flag idea as inappropriate…  ·  Admin →
              started  ·  imontgomeryimontgomery responded

              Agile very well suited to a maintenance and support environment. The ability to be flexible and adapt to changing priorities is the essence of life in a maintenance and support environment. Agile delivers that flexibility by allowing teams focus on the most important thing – and to get it done as quickly as possible. Iteratively and Incrementally getting the most important item to done – to fully tested and deployable – improves cycle times, increases our productivity, and ensures that we can change directions quickly.

              However, in many support and maintenance environments, Scrum isn’t the best fit. The nature of the environment may not allow the team to lock their scope and maintain focus – even for the duration of a 2-week iteration. And without the ability to focus and deliver on iteration commitments, the integrity of scrum begins to degrade.

              But Scrum is only 1 agile framework. Another framework…

            • How do I get buy in, especially from the business, to move to Agile?

              I recently started at a new company, and our development team is new. There really was no process, and I have been mostly working with quasi Extreme Programming methodologies. I would like to move to a formal Agile process. How do I get the business to buy in?

              Merged with: (Idea created Jul 22, 2011 by Stephanie J Brown)

              How do we convince upper management to adopt Agile practices?
              We started working with Agile when our prior CTO came on board. Now that he's gone, we need another Agile Champion at the higher levels of the company. What information and…

              359 votes
              Vote
              Sign in
              Check!
              (thinking…)
              Reset
              or sign in with
              • facebook
              • google
                Password icon
                I agree to the terms of service
                Signed in as (Sign out)
                You have left! (?) (thinking…)
                0 comments  ·  Flag idea as inappropriate…  ·  Admin →
                started  ·  imontgomeryimontgomery responded

                A few months ago, a number of my colleagues and I were collecting testimonials from some of our clients who were well along their path toward agility, and were seeing the kinds of transformational successes that we want all our clients to achieve. One of questions we ask them was ‘how did you get started? how did you get everyone on-board? how did get get buy-in from the business and from senior management?’

                Without exception they told us that the key was finding opportunities to demonstrate frequent, small successes – and building on those successes over time. Business leaders and senior management were intrigued by the industry statistics – 25% greater productivity; 50% faster to market; 83% improved customer satisfaction – but they didn’t really start to understanding it, to really start getting behind it, until it became real. Until they saw the results ‘here’ – on their projects.

                So…

              • Is the gap between PMI framework (with sw projects) and Agile methods really that large?

                I acknowledge that lengthy (aka burdensome) planning, locked down requirements, and rigid change control will lead to less than satisfactory customer deliverables in IT software projects. It seems, however, that the main difference between these two methodologies is that the the PMI framework appears linear from initiation through the closing, while in agile the planning, execution, monitoring groups are just more flexible/iterative/dynamic. Thoughs??

                302 votes
                Vote
                Sign in
                Check!
                (thinking…)
                Reset
                or sign in with
                • facebook
                • google
                  Password icon
                  I agree to the terms of service
                  Signed in as (Sign out)
                  You have left! (?) (thinking…)
                  3 comments  ·  Flag idea as inappropriate…  ·  Admin →
                  started  ·  imontgomeryimontgomery responded

                  Not really – not as I read the PMBOK. I consider them to be quite congruent actually. Agile just emphasizes and expands on certain ideas in the PMBOK.

                  In fact, I find that Agile teams are MORE aligned with the philosophies I see in the PMBOK than most implementations in traditional environments.

                  Agile is about discipline. Its about visibility. It’s about predictability. Its about mitigating risk. It’s about adapting to change. It’s about delivering value. Those are all very clearly emphasized in the PMBOK – though many tend to gloss over them.

                  In fact, while the details of this question suggest that the PMBOK framework describes a linear process flow (while agile is more iterative) I don’t see a linear process in the PMBOK at all. The PMBOK describes the Planning and Execution phases as a continuous, iterative feedback loop, with project control activities overlaying to provide visibility…

                • Is small / agile development team is capable enough...?

                  Few things, @especially about Agile Development Team; It is a practice that agile/scrum development team should be small specially 4/5 people, not more than 9. They should be all rounder and cross functional, and should know everything including programming, testing etc. They are expected to participate into the planning process, in the meetings, development, testing and even implementation (incremental). As per agile, they do not contain sub-teams dedicated to particular domains like testing or business analysis.

                  My question is, in today's specialization age, is this approach practical? Are these Team members are capable enough to handle all these tasks efficiently…

                  295 votes
                  Vote
                  Sign in
                  Check!
                  (thinking…)
                  Reset
                  or sign in with
                  • facebook
                  • google
                    Password icon
                    I agree to the terms of service
                    Signed in as (Sign out)
                    You have left! (?) (thinking…)
                    4 comments  ·  Flag idea as inappropriate…  ·  Admin →
                    started  ·  imontgomeryimontgomery responded

                    The details of the question state that “agile teams should be small – 4/5 people and not more than 9.”
                    – The general rule of thumb for a scrum team is 5-9 people. I generally say its a guideline. You certainly don’t want your team too get too big – lest the size impede collaboration – but I’ve worked with very effective scrum teams as large as 12-15 people. Other agile frameworks, like kanban for example, don’t specify a team size and have been shown to scale much larger.

                    The details of the question state that “all members of the team are cross functional and know everything including programming, testing, etc…”
                    - We definitely want our teams to be as cross-functional as possible, so as to maximize flexibility of the team. But in practice most teams have a range of skill sets and experiences on the team. Rarely have I…

                  • What is the best way to manage requirements to get them into the Agile process?

                    When considering Agile the most difficult transition is getting all the requirements into a tool that allows for easier shift and resource planning. How is the accomplished? What tools are people using?

                    260 votes
                    Vote
                    Sign in
                    Check!
                    (thinking…)
                    Reset
                    or sign in with
                    • facebook
                    • google
                      Password icon
                      I agree to the terms of service
                      Signed in as (Sign out)
                      You have left! (?) (thinking…)
                      2 comments  ·  Flag idea as inappropriate…  ·  Admin →
                    • How do we calculate Earned Value for Agile projects?

                      How do we calculate Earned Value for Agile projects?

                      244 votes
                      Vote
                      Sign in
                      Check!
                      (thinking…)
                      Reset
                      or sign in with
                      • facebook
                      • google
                        Password icon
                        I agree to the terms of service
                        Signed in as (Sign out)
                        You have left! (?) (thinking…)
                        1 comment  ·  Flag idea as inappropriate…  ·  Admin →
                        started  ·  imontgomeryimontgomery responded

                        Here is an example:

                        DATA
                        - You have a project backlog estimated at 240 points
                        - The team has a velocity of 40 points (2 week iterations)
                        - The team’s cost is $50,400 per iteration (7 people @ $90/hour x 80hrs)
                        - Schedule is 12 weeks (6 iterations)
                        - Budget is $302,400 ($50,400 × 6)

                        EVM CONVERSION
                        PV = $50,400 per iteration (your planned costs)
                        EV = $1260 per Story Point delivered ($302,400 / 240 = $1260)

                        ITERATION #1
                        The team delivered 42 story points
                        EV = $52,920 ($1260 × 42)
                        AC = $50,400 (actual cost)
                        PV = $50,400

                        CPI = 1.05 (EV/AC) – you’re under budget!
                        SPI = 1.05 (EV/PV) – you’re ahead of schedule!

                        ITERATION #2
                        A develop resigned from the team effective day-1 of the iteration. They’re not replaced
                        The team delivers 38 story points
                        EV = $100,800 ($1260 × 38 + $52,920)
                        AC = 93,600 ($43,200…

                      • 182 votes
                        Vote
                        Sign in
                        Check!
                        (thinking…)
                        Reset
                        or sign in with
                        • facebook
                        • google
                          Password icon
                          I agree to the terms of service
                          Signed in as (Sign out)
                          You have left! (?) (thinking…)
                          1 comment  ·  Flag idea as inappropriate…  ·  Admin →
                        • Concerned that quality will suffer in the rush to be Agile

                          As a QA/IV&V team member, I need to be reasonably comfortable with products, such as documentation and resolution of testing defects, going forward. But I'm concerned that quality will, once again, take a back-seat to schedule & need to find a way to convince the team that we do not want to hit a target date with half baked goods.

                          176 votes
                          Vote
                          Sign in
                          Check!
                          (thinking…)
                          Reset
                          or sign in with
                          • facebook
                          • google
                            Password icon
                            I agree to the terms of service
                            Signed in as (Sign out)
                            You have left! (?) (thinking…)
                            0 comments  ·  Flag idea as inappropriate…  ·  Admin →
                            started  ·  imontgomeryimontgomery responded

                            Any agile team worthy of the name knows that quality should be – must be – at the core of everything they do.

                            From the Agile Manifesto
                            - ‘Working software is the primary measure of progress.’
                            - ‘Continuous attention to technical excellence and good design enhances agility.’

                            Every iteration, agile teams deliver backlog items (stories) to “Done” – coded, tested, documented, accepted, ready for deployment – D.O.N.E.

                            They do so for many reasons, including:

                            - Backlog items that don’t meet the Definition of Done are RISK. They Work in Progress (WIP). They’re an unknown and uncertain quantity. The most risk laden phrase in software development – ’we’re almost done with testing’.

                            - Building additional backlog items on top of code that isn’t known to be of high quality (because it hasn’t been tested) is akin to building a house on top of an unstable foundation. It only…

                          • How to revive a "failed" agile transformation

                            A team failed the first attempt to do an agile transformation and fell back to a mix of predominantly waterfall and partly agile process. What ideas would you suggest to revive the agile transformation

                            149 votes
                            Vote
                            Sign in
                            Check!
                            (thinking…)
                            Reset
                            or sign in with
                            • facebook
                            • google
                              Password icon
                              I agree to the terms of service
                              Signed in as (Sign out)
                              You have left! (?) (thinking…)
                              0 comments  ·  Flag idea as inappropriate…  ·  Admin →
                              started  ·  imontgomeryimontgomery responded

                              If you were trying to convince me to reinvest and recommit myself to an agile transformation, my question to you would be ‘why is it going to be different this time?’ Unless you can answer that question, I can’t imagine why an organization would get behind trying something that they’ve seen fail in the past.

                              So I would encourage you to do a retrospective on the failed attempt.
                              - In what ways did you “fail”?
                              - What contributed to that failure?
                              - Was there anything positive about the attempt?
                              - Why was that successful, while other aspects weren’t?
                              - How can you mitigate the areas of failure?
                              - How can you amplify the areas of success?

                              The answers to those questions might be:
                              - we’re going to enlist greater management support and involvement
                              - we’re going to engage more closely with our business partners
                              - we’re going to actively manage…

                            • How does the business know that governance and regulatory mandates will be met?

                              Our stakeholders are concerned with security and privacy breaches. We place a lot of emphasis on architectural risk. And we have regulartory mandates (e.g., HIPPA, FSCXXX, ...) we must adhere to. How does Agile work in this environment?

                              128 votes
                              Vote
                              Sign in
                              Check!
                              (thinking…)
                              Reset
                              or sign in with
                              • facebook
                              • google
                                Password icon
                                I agree to the terms of service
                                Signed in as (Sign out)
                                You have left! (?) (thinking…)
                                2 comments  ·  Flag idea as inappropriate…  ·  Admin →
                                started  ·  imontgomeryimontgomery responded

                                In general I agree with the comment from Chad. Making regulatory and compliance documentation and other requirements part of your definition of done is how I’ve most often seen this addressed. Where Chad’s description has the actual verification process in the definition of done, I haven’t done that. In general, my experience has been that the regulatory bodies will only review your product when you are ready to take it to production. In those cases, we’ve simply made our verification materials being updated, and in a state of READY to enter the verification process, as our definition of done.

                                But this is a big topic. Rather than try to do it justice here, I would recommend people attend our next webinar, which just so happens to be on this precise topic! -

                                ‘Agile in High Assurance and Regulated Environments’ – http://www.rallydev.com/events/agile_webinar_series/

                              • How do you handle the technical requirements - as stories as well?

                                Are technical requirements related to user stories written as stories as well? Or are they documented more formally and included in estimates related to stories they are associated with for example?

                                125 votes
                                Vote
                                Sign in
                                Check!
                                (thinking…)
                                Reset
                                or sign in with
                                • facebook
                                • google
                                  Password icon
                                  I agree to the terms of service
                                  Signed in as (Sign out)
                                  You have left! (?) (thinking…)
                                  0 comments  ·  Flag idea as inappropriate…  ·  Admin →
                                  started  ·  imontgomeryimontgomery responded

                                  There are 2 types of technical requirements that I see:

                                  1) requirements that are related to a functionally oriented business need – for example, a requirement that the new transaction history search feature support 1000 concurrent users.

                                  2) requirements that stand on their own, delivering value without any feature functionality – for example, a requirement to encrypt the database in order to meet security and privacy needs.

                                  Example #1 is generally captured as an Acceptance Criteria for the user story / backlog item that describes the new history search feature.

                                  Example #2 is a stand-alone user story / backlog item

                                  The primary distinction is that a backlog item must be able to deliver demonstrable business value – on its own.

                                  A good rule of thumb is to always try make sure that your stories / backlog items meet the INVEST criteria. The should be:

                                  I – Independent
                                  N – Negotiable…

                                • Estimates

                                  What's the most efficient technique of producing estimtates of time and complexity from a team and then refactoring those estimates during the project?

                                  109 votes
                                  Vote
                                  Sign in
                                  Check!
                                  (thinking…)
                                  Reset
                                  or sign in with
                                  • facebook
                                  • google
                                    Password icon
                                    I agree to the terms of service
                                    Signed in as (Sign out)
                                    You have left! (?) (thinking…)
                                    0 comments  ·  Flag idea as inappropriate…  ·  Admin →
                                    started  ·  imontgomeryimontgomery responded

                                    Agile teams estimate backlog items in terms of their ‘relative size’, rather than in the absolute number of hours of effort or duration they will take to complete.

                                    The relative unit of measure most commonly used is the ‘Story Point’.

                                    Story points compare the size of backlog items based on 3 attributes:

                                    1) Effort
                                    2) Complexity
                                    3) Doubt

                                    A Story Point is an arbitrary unit that has meaning only in relation to itself. So sizing a backlog item as 2 points simply means that it is twice as big as another item sized as 1 point.

                                    We then derive Duration based on how many Story Points the team demonstrates they’re able to deliver over the course of an iteration – we can this their velocity – Velocity = distance/time.

                                    The best way of producing high quality Story Point estimates is to engage the team in a structured conversation using one…

                                  • Is there any good tool, software to manage an agile project (other than MP)?

                                    Is there any good tool, software to manage an agile project (other than MP)?

                                    96 votes
                                    Vote
                                    Sign in
                                    Check!
                                    (thinking…)
                                    Reset
                                    or sign in with
                                    • facebook
                                    • google
                                      Password icon
                                      I agree to the terms of service
                                      Signed in as (Sign out)
                                      You have left! (?) (thinking…)
                                      3 comments  ·  Flag idea as inappropriate…  ·  Admin →
                                    • 76 votes
                                      Vote
                                      Sign in
                                      Check!
                                      (thinking…)
                                      Reset
                                      or sign in with
                                      • facebook
                                      • google
                                        Password icon
                                        I agree to the terms of service
                                        Signed in as (Sign out)
                                        You have left! (?) (thinking…)
                                        1 comment  ·  Flag idea as inappropriate…  ·  Admin →
                                        started  ·  imontgomeryimontgomery responded

                                        I will assume you’re referring to Change Management in terms of Scope.

                                        The vehicle for managing scope change on an Agile Team is the backlog. The Product Owner – as the “owner” of that backlog – is effectively your Change Manager. They are responsible for ensuring that any changes to the Backlog are desirable (are addressing the business need more effectively than without the change), and that the impact to Schedule and/or Budget are understood and acceptable.

                                        This is made continuously visible to everyone on the team, and all stakeholders (business and technology).

                                        Coming out of Release Planning, the team, the product owner, and all stakeholders will have a clear understanding and of what backlog items are projected to be delivered when – based on the team’s sizing of those backlog items and their historical velocity.

                                        As the team begins iterating and delivering, several things will likely begin happening:

                                        1)…

                                      • Does agile support multi-tasking? If so, how?

                                        Some tasks (for eg: I.T related, setting up a Windows VM etc) take a few hours to complete, but don't require the individual's full attention,thus allowing it possible to multi-task. How can we accurately allocate, track and report metrics for such tasks/stories?

                                        73 votes
                                        Vote
                                        Sign in
                                        Check!
                                        (thinking…)
                                        Reset
                                        or sign in with
                                        • facebook
                                        • google
                                          Password icon
                                          I agree to the terms of service
                                          Signed in as (Sign out)
                                          You have left! (?) (thinking…)
                                          1 comment  ·  Flag idea as inappropriate…  ·  Admin →
                                          started  ·  imontgomeryimontgomery responded

                                          I see 2 questions in here Multi-Tasking and Time-Tracking. I’ll try to address each in turn:

                                          MULTI-TASKING
                                          It’s certainly a reality that many tasks involve substantial wait time, and it would be foolish for a team member to do nothing but watch a status bar while some automated activity is occurring. So, in that scenario, agile would absolutely support them switching to another task in the interim.

                                          Where Agile discourages multi-tasking is where we could be focused and productive on a single task, but instead are switching between coding, emailing, attending administrative meetings, working support tickets, etc… We’re all familiar with the many studies that show how inefficient multi-tasking is. Agile just encourages that we focus on the most important thing – as an individual, as a team, as an enterprise – get it done as quickly and effectively as possible, then move on to the next most…

                                        • How can I apply an Agile framework to dev projects which have significant Discovery phases?s?

                                          How can I apply an Agile framework to dev projects which have significant Discovery (requirements) phases?

                                          48 votes
                                          Vote
                                          Sign in
                                          Check!
                                          (thinking…)
                                          Reset
                                          or sign in with
                                          • facebook
                                          • google
                                            Password icon
                                            I agree to the terms of service
                                            Signed in as (Sign out)
                                            You have left! (?) (thinking…)
                                            0 comments  ·  Flag idea as inappropriate…  ·  Admin →
                                            started  ·  imontgomeryimontgomery responded

                                            How do you eat an elephant?…

                                            Part of the agile mindset is a belief that we get better requirements, that we get better architecture and design, that we are more effective in delivering solutions that solve customer problems, when we allow those details to emerge through a process of Progressive Elaboration and Continuous Feedback.

                                            So while there certainly may be significant Discovery activity on an agile project, there generally isn’t a significant Discovery ‘Phase’ – that in a sequence prior to ‘Construction’. Discover is spread throughout the process.

                                            Now, that doesn’t mean we do no Discovery or Planning up-front. As I’ve discussed in a number of other responses, Agile projects engage in the 5 Levels of Agile Planning to progressively elaborate on requirements and plans.

                                            For more information, check-out the White Paper on the 5 Levels of Agile Planning: http://www.rallydev.com/downloads/document/2-five-levels-of-agile-planning-from-enterprise-product-vision-to-team-stand-up.html

                                          ← Previous 1 3 4 5

                                          PMP? Bring us your toughest Agile Questions.

                                          Feedback and Knowledge Base