Agile Methods

6242 Views
0 Likes
0 Comments

Business isn’t going to walk hand in hand with IT until we’re ready to truly partner with them. Here’s how.

I’ve had some interesting conversations about the role of business analysts and the best practices most of them use for requirements-gathering. And I’ve noticed a major contradiction between our desire to be effective partners with the business and the way we go about gathering system requirements.

The contradiction is this: current best practices lead us to gather requirements for a new system by using procedures that, right from the start, cause tension and adversarial interactions between IT and business people.

Author: Mike Hugos

17727 Views
14 Likes
8 Comments

If Agile is to become the next zeitgeist for development, what will become of the traditional Business Analyst?

We all know the traditional waterfall mantra: analyze, design, build then test... underpinned by the common belief that the more you analyze up front the more you save in maintenance later on. This has had a huge impact on the way we organize our teams: separating functions and putting a heavy emphasis on theoretical modeling.

When a project kicks off, the classic Gantt chart dictates that analysts are on-boarded early for a lengthy requirements analysis stage. Once the requirements specification is 'signed off' the analysts are often relieved of their posts for the design crew to take over. The 'sign off' fest continues until eventually the user community is (invariably) force fed a UAT phase and the fledgling product is launched; all the while resources are inhaled and exhaled as the project plan demands. The project then becomes more of a way to co-ordinate a set of individual skill sets and activities.

8013 Views
3 Likes
0 Comments

Why has it been necessary to write so many different, book-length treatises about requirements management on software projects? Is it not possible to develop an approach to handling software requirements that is simple enough to express concisely -- and yet can work with large, complex projects as well as smaller efforts?

At the risk of using a word that disturbs many in the field of software engineering, requirements management is just a process. The more simply this process can be described, the more likely it will be to work in real software organizations. So rather than consider every possible nuance relating to managing software requirements, this article will attempt to express the essence of an approach that can work well on virtually any Agile software development project. In the appendix, I include a detailed example illustrating the key ideas.

Author: Theodore F. Rivera, Software Group Strategist, IBM

24007 Views
17 Likes
1 Comments

Across North America, businesses in all sectors are adopting standard development methodologies to turn out a higher quality of goods and services. The tried and true approaches that have yielded such great results for competitors are heralded as best practices. But here is the sad news: no one methodology fits all. In fact, different methodologies are appropriate in fitting diverse projects. Some projects are so unique, future-thinking Business Analysts (BAs) are finding that the adoption of new hybrid concepts is the only smart way to go in problem solving tomorrow’s projects.

The word ‘fresh’ describes that feeling of turning over a new leaf when January 1 rolls around each year – and the sentiment we as individuals strive to maintain all year long when we set New Year’s resolutions. Much in the same vein as these annual goals, BAs seeking an innovative means by which they can see their requirements come to fruition are increasingly interested in the study of the existing methods that are in place within the industry, as well as fresh methods established through modeling and fusion.

5940 Views
2 Likes
0 Comments

The real world is a complex place, resulting in complex requirements for any system that has to work there. This is true regardless of development paradigm. Although "agile in the small" methodologies such as Scrum and Extreme Programming (XP) have done much to show us how to improve our approach, too many people have thrown out the requirements management baby with the bureaucracy bathwater after putting too much faith in the overly simplistic strategies of those processes. Luckily, with a bit of discipline, it is straightforward to address the inherent challenges of complex requirements in an agile manner without resorting to the documentation-heavy practices favored by the traditional community.

The Scrum method has popularized the idea of managing requirements as a stack of small, functional chunks, captured in a prioritized stack called a "product backlog". The idea is that at the beginning of each iteration/sprint, you pull an iteration's worth of work off the top of the stack. If only it were that easy. Although Scrum has helped us to get away from the onerous change prevention strategies (oops, I mean change management strategies) of traditional methods, it has blinded a generation of developers to the inherent complexities and nuances of understanding and implementing requirements.

Author: Scott Ambler

3551 Views
0 Likes
0 Comments

Study after study has shown poor requirements management is the leading cause of failure for traditional software development teams. When it comes to requirements, agile software developers typically focus on functional ones that describe something of value to end users—a screen, report, feature, or business rule. Most often these functional requirements are captured in the form of user stories, although use cases or usage scenarios are also common, and more advanced teams will iteratively capture the details as customer acceptance tests. Over the years, agilists have developed many strategies for dealing with functional requirements effectively, likely one of the factors leading to the higher success rates enjoyed by agile teams. Disciplined agile teams go even further, realizing that there is far more to requirements than just this, that we also need to consider nonfunctional requirements and constraints.

Nonfunctional requirements (NFRs), also known as "technical requirements" or "quality of service" (QoS) requirements, focus on aspects that typically cross-cut functional requirements. Common NFRs include accuracy, availability, concurrency, consumability (a superset of usability), environmental/green concerns, internationalization, operations issues, performance, regulatory concerns, reliability, security, serviceability, support, and timeliness.

A constraint defines a restriction on your solution, such as being required to store all corporate data in DB2 per your enterprise architecture, or only being allowed to use open source software (OSS), which conforms to a certain level of OSS license. Constraints can often impact your technical choices by restricting specific aspects of your architecture, defining suggested opportunities for reuse, and even architectural customization points. Although many developers will bridle at this, the reality is that constraints often make things much easier for your team because some technical decisions have already been made for you. I like to think of it like this—agilists will have the courage to make tomorrow's decisions tomorrow, disciplined agilists have the humility to respect yesterday's decisions as well.

Although agile teams have pretty much figured out how to effectively address functional requirements, most are still struggling with NFRs and constraints.

Author: Scott Ambler

51735 Views
23 Likes
18 Comments

Whether you’ve never heard of Agile or you just finished your nth Agile project, you need to understand that Agile is here to stay! Are you, the Business Analyst, an extinct species in this new world? Is your career changing? Do you need new skills?

Agile guru and visionary Scott Ambler talked with Adrian Marchis, ModernAnalyst.com's Publishing Editor, and shared his vision on what’s next for Agile and his thoughts on the role of the business analyst in the Agile world.

15376 Views
3 Likes
1 Comments

Change seems to be a popular word in this pivotal election year. When I think about change, I recognize that it impacts each of us in many forms. One of the biggest changes I’ve experienced as a Business Analyst was the transition from working requirements in a traditional project lifecycle to an Agile methodology. The change was introduced to my project team as a management directive with management support.

Our project was an enterprise initiative funded as a multi-year program. The program was comprised of three parallel workstreams with shared releases. Our workstream’s objective was to build out data and data services for the other workstreams and the enterprise to use. The team was made up of experienced Information Technology (IT) professionals and a brand new business unit. We were halfway through the program’s duration when our workstream was called upon to employ Agile methods. The other two workstreams we serviced stayed with traditional waterfall software development, which presented challenges interfacing with each other. The entire program had already completed a Business Architecture phase that outlined the program’s objectives, future state vision, and capability implementation plan.

12666 Views
3 Likes
1 Comments

A question was asked in the Modern Analyst forums. I paraphrase:

"How does a BA do their work in an Agile project? Can you give some practical examples?"

I've thought quite a bit about this topic and have experience with BAs on agile developments as a project manager and business analyst.

As a project manager I get frustrated by (but understand) the analyst’s need to move through the sensible steps of understanding the problem domain, documenting it, socialising it and then briefing the solutions team.  Many BAs struggle with breaking away from that paradigm, but to work in an agile style you have to get comfortable with the concept of 'just good enough.'

As an analyst practitioner I took it upon myself to act as a proxy for the product owner – which in a corporate environment came with the challenges of multiple stakeholders, the fact that you are not the product owner and thus don't really have the final say, and a number of other challenges that typically stump people trying to move to agile.

My circumstances were unique in some ways. I had worked in the organisation for some time and had established good relationships with all the key stakeholders. They really did trust me with their requirements because, over time, I had learnt (and shown I had earned) their business.

I also maintained high bandwidth communications with the stakeholders throughout the project and kept them informed of what was happening and how the system was shaping up in the context of their business needs. And expectations were managed.

And, lastly, at the end of the development phase of the project we kicked back into formal gated style UAT and release management.

I think the things I articulated there are useful guidelines for any BA or Project Manager on any project, but these dimensions enabled an agile approach in a waterfall type environment. I put myself forward as the product owner and acted as a proxy for the business stakeholders.

Will it work for you?

It depends on where you are working and your relationship with your client groups. A while ago I put this question of the readers of my blog: "Can the BA act as a proxy for the client?"  I got a resounding no from people that I respect and so I'll re-state that my circumstances above are probably the exception to the rule.

What I have learnt is that the BA can be a very useful person, and even play a crucial role, on an agile project.

Before I go on to speak about that I need to qualify what an agile project is: Originally when people talked about agile software development they were talking about precisely that: software development. The project community has always had a problem separating out the project lifecycle from the software development cycle. If you don't know the difference between these two concepts you need to go find out.
Here is one explanation.

So anyway, projects run many software development activities and naturally the processes and methods bleed into one another. And agile development was soon mixed into the concept of agile projects. And that's fine, but it presents a set of challenges for organisations wanting to transition from one way of doing things to another.

Have you ever learnt to juggle? I did. Hours of practicing in front of my bed so I didn't have to bend down to pick up the balls all the time. But I practiced with three balls and if I try to juggle four or five it's just too hard. I could set aside the time and practice until I get it right, but really, I am satisfied with three. It works for me, so why sweat the effort?

Same goes for shifting project methods. Sure your project office is sick of spending months and millions of dollars on wasted projects, but the various other participants in the project aren't feeling the same pain.

And smart, talented business analysts are one of those groups that aren't feeling the pain. Really, in my experience, excellent business analysts are often enough of a catalyst to break the cycle of project failures. Good requirements management, stakeholder engagement and change management really will get you there, even in the most formal waterfall environments. So why do they have to shift their whole way of doing things? They have achieved mastery of their profession, and now you want them to throw all that away and start again?

Well, yes. An agile approach in an agile environment is so much easier for everyone on the project.

Unfortunately an agile approach in a non agile environment struggles. And that environment is basically the stakeholders, the project team and the organisation's bureaucracy. So you end up using hybrid methods like agile in the developer space but more structured at the top end of the project.

The antipathy business analysts often feel towards agile methods isn't helped by the caustic tone of the agile gurus who advocate direct interface between the customer and the development team. Several of them publicly disparage business analysts and actively promote their removal from the process.

I think the key to getting master business analysts to work on agile projects effectively is helping them find a pain point they want to address, and finding a valuable place in the project for them.

The first point probably comes with either maturity – it's not all about them – or with a series of failed projects (naturally not their fault.). The second point – the BA's role – that was your original question, and it doesn't have anything to do with choices of models.
I think the role of the BA on an agile project is two-fold. Your number one role and priority is to facilitate clear requirements. It isn't to document them and it isn't to elicit them. It's to facilitate their clear transmission to the development team.

In some cases this simply means scheduling and booking meeting rooms, while in other cases it requires the BA's professional questioning and modelling skills to draw out an idea and ensure it is elaborated sufficiently for the developers to understand the full dimensions and context of the requirement.

Developers should, ideally, be in the workshops where requirements are teased out, so documentation is a secondary aspect to this work. It is about facilitating communication.

It's also about making sure the client is fully considering other stakeholders. Enterprise scale projects often have many stakeholders, and in less mature organisations the product owner or project sponsor isn't always considering the needs of his or her peers. The BA can help with that.

So, you see my idea of the role of a BA on an agile project is quite different from the traditional and industry view of what a BA does. It becomes much more people focused and much more about understanding the drivers, values and context of the business requirements than the details of the requirements themselves.

I believe these are key success factors that all excellent BAs apply in their job no matter what the project methodology.

I hope this is useful for you. And I am glad to be corrected by people who know better:" Agile Experts, what say you?"

Author: Craig Brown

8463 Views
1 Likes
0 Comments

The ultimate management sin is to waste people’s time, Tom DeMarco and Timothy Lister told us in their famous book Peopleware [1]. This includes having pointless meetings that prevent people from actually doing anything useful. Nevertheless, some meetings are considered a necessary evil and therefore the so-called “agile movement” in software development has come up with an efficient way of dealing with this: the Stand-up Meeting in 15 Minutes. For those who have just woken up from ten years of hibernation, or having emerged from a cave that had no Internet access, I will explain this briefly.

A stand-up meeting is a daily meeting where people remain standing up to keep the duration of the meeting under 15 minutes. Teams use these meetings to answer three simple questions..

6666 Views
0 Likes
0 Comments

Requirements and the way they are dealt with are decisive to the success of a project. This statement is never really questioned in modern software engineering circles.

Why is it, then, that a systematic requirements engineering (RE) system is so rarely established?

Where do the problems lie when it comes to implementing such a system?

This paper outlines the challenges and how these may be met using the example of the automotive industry.

Authors: Michael Gerdom and Dr. Uwe Rastofer, method park Software AG

18705 Views
2 Likes
0 Comments

"As I discussed my May article for Modern Analyst, there's a lot of hype about the role of requirements in agile projects. Many people think you don’t “do” requirements on an agile project. Hogwash. Indeed, agile projects use requirements—but just enough requirements at just the right time."

In this article Ellen covers a number of agile requirements topics including:

  • Agile requirements need to be understood in context of the product, release, and iteration
  • Balancing Business and Technical Value
  • The Product Workshop
  • Release Workshops
  • Iteration Workshops

Author: Ellen Gottesdiener, Principal Consultant, EBG Consulting, helps business and technical teams get product requirements right so their projects start smart and deliver the right product at the right time.

12147 Views
1 Likes
0 Comments

The latest progression in software development methods is the agile approach. Its growing popularity proves how effective it is. But two extreme—and even dangerous—views have arisen about agile development. One is that you don’t do requirements at all when you’re working on an agile project. The other is that you don’t need good requirements practices.

In truth, agile development processes are based on good practices. Most of them are not new but are being reconfigured, along with good product development, engineering, and project management practices. In my work with agile teams, I’ve noticed a number of key practices.

Author: Ellen Gottesdiener, Principal Consultant, EBG Consulting, helps business and technical teams get product requirements right so their projects start smart and deliver the right product at the right time.

218337 Views
4 Likes
2 Comments

Ideally, an agile document is just barely good enough, or just barely sufficient, for the situation at hand. Documentation is an important part of agile software development projects, but unlike traditionalists who often see documentation as a risk reduction strategy, agilists typically see documentation as a strategy which increases overall project risk and therefore strive to be as efficient as possible when it comes to documentation. Agilists write documentation when that's the best way to achieve the relevant goals, but there often proves to be better ways to achieve those goals than writing static documentation. This article summarizes common "best practices" which agilists have adopted with respect to documentation.

6762 Views
1 Likes
0 Comments
Agile software development teams embrace change, accepting the idea that requirements will evolve throughout a project. Agilists understand that because requirements evolve over time that any early investment in detailed documentation will only be wasted. Instead agilists will do just enough initial requirements envisioning to identify their projec...
Page 7 of 9First   Previous   2  3  4  5  6  [7]  8  9  Next   Last   











Copyright 2006-2020 by Modern Analyst Media LLC