Agile And The New Business Analyst Manifesto

In the cool logical realm of technology, we find no shortage of passionate “movements” that take on the fervor of religious wars or fanatical political ideologies.

Mac vs PC was the big brawl back in the 80’s.  Then it was Java vs Microsoft.  And then we had the web browser wars.  And then the Human / Cylon wars.  Oh wait, that’s the SciFi channel.  Now we have Android vs iOS.   (a quick search yields over 24 million entries). But of course, it’s never really about the technology per se, it’s about the values behind it.  In the above examples, it really comes down to a battle between different business models.

In the even more insular world of the Software Development Life Cycle (SDLC), a debate of near equal fervor has been brewing for a decade or more now, and the business analyst has been caught in the crossfire.  I’m talking about the world of waterfall vs agile, of traditional top-down “Big Spec” driven development vs the wily iterative circular one that builds, destroys, rebuilds and destroys, and rebuilds again.   A quick search yields over half a million entries. And if you don’t think these Agile folks are serious about their revolution, read their Manifesto!

So, what’s at the root of this debate between waterfall and agile?  What are the values or business models underlying each that are so in conflict, and more importantly for us business analysts, what do we stand to gain, or to lose, should we find ourselves working in one environment or the other?  These are the questions I posed to my guest, Ellen Gottesdiener of EBG Consulting Group, Inc., for this episode of my running series on Building BA Maturity.

First, let me brag on Ellen a little.  I heard her speak at Building Business Capability 2010, last year in Washington, DC.  She was stumping on the topic of “Nonfunctional Requirements: Forgotten, Misunderstood, Neglected”.   Ellen has produced two great resource books for BAs – her first title, Requirements By Collaboration about facilitating great requirements workshops, and her 2nd called the Software Requirements Memory Jogger, which is used by analysts worldwide as a study tool for CCBA and CBAP exams. Reading her thoughts is great, but to experience Ellen speak in person, is a treat.  In short, Ellen is not only a thought leader in the areas of collaborative requirements gathering, she’s a very talented trainer, presenter and educator.  And any chance you have to hear her, go for it.

Who’s right, the Waterfallians or the Agilistas?

Although I suspect Ellen harbors an inner revolutionary Agilista, she says she’s ultimately a pragmatist.  “There are elements of traditional analysis that are useful in agile contexts, and agile approaches that are very beneficial in the traditional environments,” she says.  Interestingly, she points out that Waterfall as it’s defined today is actually a misinterpretation of Winston Royce’s original idea (from whom we get the notion of waterfall development).  “Royce himself came to a modified, much more like agile approach, in his final version of Waterfall” says Ellen. And indeed, the Wikipedia entry on waterfall, confirms that point.

So, then, what is it?  What really defines Agile? Ellen describes it as an umbrella term that encompasses these main concepts:

  1. Partnership between Business, Customer and Technology
    In a certain sense, this has always been the case, but Agile levels out the field so that this becomes a more equilateral triad.
  2. Collaboration as the primary means of discovery, design and build
    What should be built?  And why, and when?  These are problems best solved through team collaboration.  Read Ellen’s book Requirements By Collaboration for a masterwork on group problem solving methods.
  3. Recursive in nature
    Meaning, no step of the process (plan, design, build, test, deploy) gets away unscathed just once. Artifacts get repeated attention and further refinement as they cycle back each time, and the deliverables of each iteration/timebox/sprint (synonyms for ‘chunk of development time’) are essentially slices or portions of the final product.
  4. Tolerance or even embrace of Ambiguity and Uncertainty
    Not knowing exactly where a product is headed at first is a given.  Allowing the solution or product features to “emerge” over time is the hallmark of this approach.
  5. Primary role of Feedback and Retrospection
    Ellen loves the notion of “retrospective” ably popularized by Norm Kerth. Agile builds retrospection into every iteration or release, so that feedback goes to the whole group for further improvement.  Feedback also comes from prototypes, inspections, quality examinations as well.

If that’s Agile culture, what it’s like to BE an Agile business analyst?

Ellen describes the role of analysis in the agile context as a ‘team sport’.  For some of us, (this author included) that can be a little jolting.  Down in the trenches with project team members (developers, stakeholders, managers) crafting requirements together?  Hey, who’s in charge here?  On the flip side, the requirements burden is no longer solely vested on one BA’s shoulders. Rather it’s shared within a wider group.  For a beautiful elaboration of this shift for analysts, check out this article by Ellen and her business partner Mary Gorman, on the role of business analysis in Scrum (‘Scrum’ is one of the formal approaches to doing agile, as opposed to Kanban, Lean, XP, etc.).

If you’re okay with not being the only BA on the project, the rest of the culture, according to Ellen, will rock your world.  When I asked her, bottom line, day-to-day, what’s really that different about doing BA work in an agile context?   Ellen didn’t flinch.

“You are jazzed every day.  In classic waterfall work, you do your requirements and you’re done.  In this world, you’re constantly learning, always connected to the business and the value, not working in isolation.”

Okay that sounds good Ellen, what else?

“Waste goes away.  There’s no hiding.  Every single individual’s work is more apparent, more transparent, and so everyone, including you as the BA, is pushed to the top of your game.”

Alright, that’s sounding very New York, very metro, kinda sexy.  Does it get even better than that?

“As a BA, you craft new requirements every day. I like to think of them like a chef putting only the freshest ingredients into the day’s menu. You slice fresh carrots and celery every day.”

Now I’m getting hungry.  Tell me more!

“You’re completely and utterly engaged.”

Sold!  You had me from ‘Jazzed’ Ellen.  I’ll take me two of those Agile sashimi slices to-go please, and thank you very much.

Bottom line, a great BA, in any context, but especially in Agile, holds three intersecting points of view simultaneously.  Ellen calls them the Now View (data, dirty details), the Preview (features, story dependencies, impact on next release, etc.), and the Big View (overarching business strategy, goals, value, impact).

The tools of the trade for an analyst working in Agile aren’t any different.  The IIBA is working on an addendum to the BABOK to bring in Agile terminology and help orient the BA, but what analysts have done, and will continue to do, is analyze and strategize for the benefit of the business.  One of Ellen’s articles that explains this back-to-the-future shift really well is Agile Analysis: Not An Oxymoron. Traditional analysis, and all the tools in our tool belt don’t go away.  What we’re going to be doing more of, if Ellen’s right and I suspect she is, we’re going to be doing a lot more of that work in groups and teams, and we’ll be immersing ourselves in areas we may not have tread in before.  “Great BAs will be learning about acceptance testing” she says.

She also says we can up the Agilistas at their own game.  Agile analysis can mature as well.  Case in point, “User Stories can be abused the way Use Cases have been,” she says. “They were originally an anchor or token for doing release or iteration planning and for having requirements discussions with stakeholders, but they’ve been elevated to the status of be-all end-all of requirements gathering in Agile projects.”   But as she points out, good BAs know that the devil is in the details of any feature.  Details like data, rules, interface, constraints, acceptance criteria, etc.  There’s room for analysts to do a world of good in these areas.  Another excellent resource in this regard is the article (available as PDF download) by Ellen and Mary entitled Agile Planning and Analysis: Synchronizing to Deliver Value

Ellen describes it succintly;

“Just remember, business analysis in Agile is not about the ‘role’, or the title.  It’s about achieving the ‘goal’ of having team members with critical thinking skills, big picture mindsets, and the ability to analyze, so that the highest value requirements are always the ones being fed first to development and testing teams for earliest delivery.”

So my friends, take heart.  To borrow from Karl Marx, BA’s of the World Unite – we have nothing to lose but our boredom and BRDs!  Or, read one of my favorite BA Manifesto’s , posted right here, by our own Laura Brandenburg.  There’s wisdom in those words.  It’s not the title,  or the role.  It’s ultimately, always, about alignment, clarity, value.

Fellow BAs, what do you think, does agile analysis sound like fun?  Does Ellen’s portrayal of doing analysis in the agile world ring true for you?  Would love to hear about some of your own experiences.  What have others experienced? Real stories from the trenches are welcome.

Free Training - Quick Start to Success

(Stop the frustration and earn the respect
you deserve as a business analyst.)

Click here to learn more

By signing up, you agree to our Privacy Policy.


  1. @Paul, I only have my own experience and analysis of that experience. (One thing I miss about academic life is peer-reviewed publication).

    My experience was working for a project contract house from 1997-2006. In 1999-2001, we set up a half-dozen projects using a plan-up-front, fixed-fee strategy. Most of them ended up under water, often badly.

    Having barely survived that ordeal, our group director told me we needed a “failure-proof methodology.” I said there wasn’t such a thing, did a lot of thinking about the failures we had, and ended up with Agile, fronted with a Facilitated Requirements Workshop, and supported with metrics-based estimation using IFPUG Function Points (I owe Eva-Marie Postion of Siemens in 2003 for the idea of FRW+FP). We “flew it off the drawing board” with no gradual testing, and proceeded to have 12 “three-green” successes–happy customer, healthy team, profitable–out of 13, and the failure was really a breakdown in account/customer relationship management.

    My analysis of that experience is summarized in the links I posted above, to which I would add

    I think what you’ve seen, Paul, is a common early-majority adoption of Agile, which without ruthless, daily attention to quality, isn’t Agile at all. All methodologies devolve. Agile devolves to what we used to call Cowboy Coding:


    • Robert, extremely interesting to hear about your experiences.

      We also always start a project with a facilitated workshop wherever possible, and of course do some estimation from that. But I don’t see how you can call a project “agile” if it’s done on the basis of requirements and estimates based on a single up-front workshop. I’ve always considered the FP approach pretty much antithetical to agile. In an agile project, requirements change, hence the FP count changes. Are you saying you used the up-front FP count as a benchmark, or that the changes were small enough not to impact it?

      On Paul’s point, there’s no denying that a reluctance to do documentation is built in to agile (it’s in the manifesto after all), and this is a problem. A lot of less experienced practitioners seem to think there’s no need to worry about maintainability, but it’s no use “valuing individuals and interactions over processes” if the individuals who had the interactions have left the company.

  2. @Robert wrote – “…an Agile project holds up a lot better in the face of an estimation error…”

    Can you give an example because I’m struggling to be convinced.

  3. @Paul, @Nick, here’s some things I’ve written and said on costing Agile projects. In a nutshell, a) you use functional (as opposed to task) decomposition, and b) it isn’t as critical because an Agile project holds up a lot better in the face of an estimation error.

    Function Points and Agile Methods:

    Diminishing Returns:

    6’40” Pecha Kucha talk:

  4. Curtis Michelson says

    @Paul, you are 100% correct that Agile can’t be an excuse for shoddy practices in software development. But I wouldn’t make a knock against Agile itself for that. In your case, if all that was left behind was a bunch of User Stories, that’s an indication the team was not using best practices for requirements management during the iterations. Those stories are a planning tool, a ‘handle’ as it were, but they rarely if ever contain sufficient documentation. Where were there acceptance tests and criteria? Where were the more detailed documents and changes logged? I saw a presentation last week from IBM showing their Rational line for ALM (application lifecycle management), and if your prior team used something like that, there would have been a permanent repository of all that stuff to refer to. NOTE: IBM targets and sells to many professional development shops that are 100% agile, and who don’t cut corners on documentation or management of requirements. So, it’s quite possible to do both.

  5. Paul Miller says

    Here’s a real life downside to the Agile approach – before I do, I think Agile has a legitimate place in the rich tapestry of the methodology philosophies available, but there is a culture out there that associates Agile with not having to do the professional stuff and to make a beeline towards the more cool and fun bits of the project as soon as you can. I’m working on a project where a legacy system developed using the “Agile” approach needs to undergo some serious enhancements (actually, it’s to fix deficiencies that should have been there in the first place if more time was spent understanding the big picture up front). In order to know how these enhancements can be integrated we need a reasonably accurate representation of what has been deployed, so we are particularly dependent on specifications and design descriptions. All we can find is a whole lot of User Stories and bits-n-pieces spread over disparate files where the version status of this info is unkown, traceability to what was actually tested and deployed is unknown, original team members have moved on. So with no reliable baseline, our ability to integrate changes into this legacy system for the asking price is pretty much close to zero – in fact it would be technically safer and probably cheaper in the long run to replace the legacy system which is less than 2 years old. So whilst this legacy system might have been delivered on time and on budget and with happy users ( I doubt all three) – it has not been developed to be maintainable so that enhancements can be integrated without major cost and high technical risk – “Maintainability” now there’s a question that should have been asked up front – it’s a bit like a building architect being asked to add a renovation to a house but the current architectural drawings of the house either don’t exist, are the wrong version or do not adequately represent what is currently there – flying blind. It’s now going to cost a whole lot more than it should.

  6. Curtis Michelson says

    @Esme, it’s hard to prescribe any approach here, because the details of your situation could be varied, but I noted your one sentence; “Clients want to see developed ‘modules’ ASAP”. I don’t know what you mean by ‘module’ but on the surface, that itself, does not sound very agile. Again, I may be misunderstanding your situation, but imagine a system ultimately has 10 modules. And a clients wants to see one of them completed right away. The Agile approach would be to focus on the minimum most important feature set, which may not be all of the features in Module 7 let’s say. It might be feature A from Module 1 (because that feature is a key learning to the rest of the system) as well as features B,C, & D from Module 7. In other words, the critical thing in Agile iterations is deciding on the priority slices for each go-round. In terms of getting your developers or your company on board, that’s a whole article to itself, but a possibility is to cut the project into a couple pieces, and beg, petition, plead for the ability to try an agile approach for one part of the project, and the traditional approach for the other half. Let the teams try it out, on just a small aspect, to get a feel. Dip their toes in the water. That might be easier said than done though. Good luck!

    @Kai, your situation sounds like one where the limited documentation you suggest (screen shot, small process diagram, or data flow) would be ideal and quite adequate. I’m presuming here that a body of project knowledge and business domain context already exists and is equally shared among team members. If that’s not the case, it’s always good to fill in those gaps for everyone’s benefit. And let’s face it, the changes to the business (even if small ones to an existing system as you mention) are usually driven by larger forces that remain invisible to everyone unless someone like yourself, makes them more transparent. in other words, the form change on the website might be a simple change, but what’s behind, and more importantly, what it might suggest about what’s coming down the product pipeline over the next 6 months or year, could be extremely important for everyone to wrap their heads around.

  7. How would u write a requirement for an edit or update of additional features to an existing system. Is it necessary to fill in the business requirement, current process etc or would it suffice just to not added functionality, screen shots of the revised form and possible activity diagram of the current process and new activity process showing how the new features should be implemented??

    I am pretty much being assigned these type of projects and nothing really where I am having to flush out requirements from the inception of a project

  8. Esme Pretorius says

    Thank you for the great article!
    I remember about 4 years ago a developer came to me with the Agile methodology (of which i never heard before!). I was still a junior BA and sceptical already about what the developers wanted. The company culture at the time was that BA’s weren’t needed. Sad but true.
    Currently i’m in a company with a different challenge. We are a growing company still getting out BA processes in place and currently its a struggle between Waterfall and Agile. Or should i say our company opts for Waterfall where as the client is adamant on Agile! And here the BA is smack dab in the middle of the struggle. How to keep everyone happy though? Currently it seems as though Agile is definitely the way to go because of time constraints and personally i think it makes sense. Clients want to see developed ‘modules’ asap! It makes them happy! It makes them feel like the project is getting somewhere! Isn’t this what we should ultimately strive for? Show output asap? Even if its just for a little bit of the bigger picture?
    One of my biggest challenges of the project is probably were to start. Because how do you eat an elephant? Bit by bit. But perhaps starting at the tail end is not the brightest idea. Explaining to the developers that it is an elephant is also important. Keep the big picture in mind even though its not a 100% clear and it can evolve into so much more. We have to have a goal.
    Any thoughts?

  9. Ellen is correct, there are plenty of elements in both traditional and agile methods that bring benefits to the project, the team, and the client & users. It’s all about collaboration, understanding, and working to enable the clients needs (and not just their wants).

    While many BAs are just coming into Scrum and Agile, there are some who have started to move towards a post-Agile workplace. At the same time we are fighting to bring understanding of the value we offer in both traditional and agile environments. Is it time for a BA Manifesto?

  10. Paul Miller says

    @Curtis – I like your responses, they reflect my experience. I have not come across any customers that will sign on the dotted line without there being some evidence of an outcome that will be within budget and time give or take some risk reserve on their side for surprises – but most certainly not open ended.

    @Nick – you wrote “….In my own experience clients are usually much more comfortable with talking about requirements and deadlines than budget….” are these internal customers within your organisation or external customers? If they are external customers, is there a contract in place? I would find it hard to understand an external customer entering into a deal that involves time, money and reputation without contract terms & conditions in place that will protect them from financial ruin – e.g. Warranty, Liquidated damages, Liability, Right of Recovery and so on.

  11. Curtis Michelson says

    @Nick, perhaps you’re saying it’s a chicken-egg paradox here. Can’t get budget till relationship established, can’t get relationship established until you do work with a budget? In my experience, budget, as well as time, and scope (the classic tri-lateral constraints of any project) ARE the starting point. So, I force all three variables right out of the box immediately, and if I can’t get those, I don’t see how i can realistically go forward. But indeed you’re correct, that ‘feasibility’ is exactly what I was referring to. There again, of course, a client needs to have enough trust in you as a consultant to do a feasibility study; i.e., trust that you are unbiased, objective, etc., which again, presumes the “trust” element of which you speak is already there.

  12. I’ve been looking for the best answers to Paul’s question on costing for some years. Curtis, I’m interested that you say “Client says we have X dollars to spend”. In my own experience clients are usually much more comfortable with talking about requirements and deadlines than budgets. A frank, realistic discussion about budgets can only happen once a good working relationship has been established – which of course leaves the original question about bids and proposals unanswered. One reasonable answer, as you suggest, is to pitch a separate up-front discovery phase – what would once have been called a feasibility study.

  13. Curtis Michelson says

    @Paul, to your other question about applicability of Agile to various industries, projects, etc… I came across this piece which dives right into that question and seems to frankly assert a few of the dicier areas Agile has tried to play, and why the results have been, as the author asserts “dismal”.

    I was intrigued in particular by his last point that the quality of the Agile group is more to do with people (the maturity level of the players) than the process itself. That resonates with my own experience and has a LOT to do with how effective the approach is. It requires, sorry to put it like this, “grown ups”. 😉

  14. Curtis Michelson says

    @Paul, great question. I’d love to hear others’ thoughts, but in my experience, it goes something like this. Client says we have X dollars to spend. Let’s use round numbers here and say $50,000. The development team is of a fixed size, let’s say 5 members. And they know that working together as a team, they burn through $10,000 of that budget every two weeks. So, assuming the agile delivery timebox is bi-weekly, that means, the project can afford 5 iterations. Five burns and then you need to be at orbit velocity, or you’re sunk.

    So, there is a high premium placed on smart project planning at the get-go. Because, if you don’t have a good ‘sense’ at least of scope, architecture, technology, then, you could easily go off in a variety of directions, burn through five iterations, and client may not have an orbiting satellite. I think this is where the notion of “purity” breaks down, and the Agile folks would admit, there’s a role for some traditional specification at the early stages. But I think that takes the form of broad outlines, and dare I say “traditional business analysis”?.

    If the project is something totally new, a green field situation, then a responsible firm would have to tell the client, “we need to plan two iterations for discovery” and then we’ll be in a better position to tell you exactly when and how we’ll get to the goal. Of course, other situations are not like that. The team is doing something it has done before, perhaps many times, and this particular project just pulls a small twist on the prior projects, so it’s quite reasonable to make some assumptions about number of iterations required, and just get on with it.

    In the projects I’ve worked on that are explicitly labeled “agile” (which I can count on one hand), this has been what I’ve observed. I’d really love to hear other’s thoughts on this, and their more learned experience.

  15. Paul Miller says

    So how does one cost an Agile project? In bids and proposal work, just how is this achieved? I don’t know of many prospective customers that are comfortable with an open ended Time & Materials type response. Also – what is the scope of Agile? What is the set of projects where Agile is appropriate before it becomes inappropriate. For example, would anyone entertain an Agile approach to developing a medical device, a train signaling system or a commercial aircraft?

  16. @Tony: “My take on the Agile Manifesto is that it’s trying to say that we have been focussing on the wrong things – we have been focussing too much on process, and too little on delivering business benefit – and that we need to take a step back and re-adjust our mindset.”

    That was not my experience before agile existed, but still, I’ll grant that the Agile Manifesto may have brought this benefit to many organizations. However, if one looks at the principles associated with the manifesto:, not all of them apply to all successful projects. I am working and have worked in many projects (some of them systems that have been in production for years, and users love) in which it was simply impossible to “deliver working software frequently”, or have “business people and developers work together daily throughout the project”. Thus, I don’t feel comfortable with classifying these project as “agile”, even though they had nothing to do with the waterfall model.

  17. Curtis Michelson says

    @Tony, I think you’re exactly right, that the philosophical orientation of Agile is putting products (working software) ahead of process (requirements, analysis, documentation). It values products over process. What was eye opening to me, in talking to Ellen, was that process is still important, and analysis is still important, and the way that planning and analyzing gets synchronized with the development flow, was the key.

    And your memory indeed serves you correctly about Marx. The ‘commune’ was supposed to be a ‘Collaborative’ venture, with the operative Business Rule of “from each according to their abilities, and to each according to their needs.” And dictators and czars and 5 year plans and project managers, we’re not part of that vision!

    To bring the History of the issue a little more forward, there’s no question that Agile (the folks behind the creation of the Manifesto) were reacting to what they saw as an “elitism” rampant in the software development world. Where analysts, architects, designers were the kings, and everyone else the grunts and the minions. The proletariat if you will. So there has been something of a “class struggle” going on here. For an interesting take on this history, and how it might repeat itself again, check out this piece from Uncle Bob (Robert Martin’s) blog, entitled, “What killed Waterfall, could Kill Agile”.

  18. Also, in reference to your picture of Karl Marx… Communism, as it was implemented in Russia and other states – with a central command & control structure – sounds like a great idea in theory – everyone has their place in the machine, everyone is part of the process. But in practice it doesn’t work, in part because it forgets that humans need incentivisation and responsibility for motivation. There are at least some parallels to the problems with process-bound IT projects in there somewhere. And I’ve met more than my fair share or ruthless dictator project managers 🙂

    Ironically, if I remember correctly, Marx’s ultimate goal was to be able to strip away the command & control structure, leaving a self-organising community in which everyone had an equal stake. Hmm…sounds a bit like the agile philosophy, doesn’t it?

  19. So for me, agile is not so much a process as it is a state of mind; an approach; a philosophy.

    My take on the Agile Manifesto is that it’s trying to say that we have been focussing on the wrong things – we have been focussing too much on process, and too little on delivering business benefit – and that we need to take a step back and re-adjust our mindset.

    It’s easy to see why IT projects have become process-centric – a desire to achieve quality, consistency, repeatability – CMMI and all that. So we’ve built up processes around these things, and hired project managers and CMMI gurus to entrench and enforce these processes.

    And that all seems like a good idea in theory, but in practice what we see is individuals focussed on their own small part in the process – a requirements document, an architecture document perhaps, with the belief that their artefact is actually the end product, rather than just a means to an end.

    For me, Agile means focussing relentlessly on business benefit (the “working software”) – forever re-prioritising, adapting, embracing change. Constantly questioning whether the task you’re working on really matters, not just an item on a process checklist.

    And also recognising that workers are human beings who are imperfect processors of information, and need motivating. It’s pointing out that workers who are process-bound do not deliver the best results, and the way that we interact is crucial for success. I’ve only recently recognised the importance of face-to-face communication, co-location, osmotic communication etc.

    So in my view you can take an agile approach to your work regardless of the process you are using, so log as you have the right mindset.

  20. Curtis Michelson says

    @Michelle, indeed agile approaches offer daily bread and nourishment don’t they!

    @Adrianna, I agree it’s a false choice really, for several reasons. As i point out, Waterfall itself took a wrong turn somewhere and lost the more refined iterative components that Royce himself wanted in it. Two, as Ellen points out, Agile is an umbrella concept taking in many of the approaches that Kupe was referring to, formal and informal, that are lean or lean’ish, iterative and visualized. So, indeed, it’s not a simple choice between A and B. Thanks for pointing that out.

  21. “Although I suspect Ellen harbors an inner revolutionary Agilista, she says she’s ultimately a pragmatist. ” If I weren’t already a fan of Ellen’s work, that phrase alone would make me so :-).

    Curtis, I like everything about your article except how it reinforces the idea that one must choose between agile and waterfall, as if there weren’t other models. As well put by Kupe in af recent article:

    “Before the Agile Manifesto was developed, I worked on teams that collaborated, were lean, iterated, and visualized.”

    Many of us have. And many of us work in projects that could not be successful either with “traditional top-down “Big Spec” driven development” or “the wily iterative circular one that builds, destroys, rebuilds and destroys, and rebuilds again” model. For that reason, I don’t feel comfortable calling my projects “agile”, even though they are incremental/iterative/collaborative too.

  22. Michelle Swoboda says

    Enjoyed your article! I have worked both traditional methods and agile and I find agile sexy as you described. I enjoy being in partnership with the developer and seeing the changes each day. I feel more engaged with the project whereas in traditional methods there are days when I do not even talk with the developer and I wonder where their mind is taking them. 🙂

  23. Great article here. There are a lot of ways traditional BA’s can move into Agile environments:

Before you go, would you like to receive our absolutely FREE workshop?

(No formal experience required.)


Quick Start to Success
as a Business Analyst

By signing up, you agree to our Privacy Policy.