Agile Methods

The product owner is an ideal. I have experienced this myself as product owner and business analyst in a scrum team. How many organizations have a job title that can cover the role completely? If not, is your organization ready to change in order to fit the scrum method? The organization I work in is not but it is still possible for the scrum team to have an efficient product owner. In our team, it was decided to adapt the role to fit our organization by establishing a product owner team in which I as business analyst am a member.

A great approach under the right circumstances, agile is not a universal solution for successfully completing a software project. Some projects are simply not compatible with most agile practices. For such projects, NANW has been driving results in terms of project and rework costs, integration time, and improved quality as reported by customers.

One of the most significant characteristics of an Agile engagement is that technical and business professionals work collaboratively to grow the system. The team agrees upon the goals for the project, as well as the order in which the requirements will be addressed on each of the sprints... At least one team member should have the role of “data advocate”; a person who wears the data hat...

I’ve written in the past about why hybrid approaches that incorporate traditional and agile methods of software development are been applied by organizations seeking to improve the results of their software projects. Here I’ll describe the 3 types of hybrid projects I have identified while working with different organizations in consulting assignments, and what impact each type has in the work of a business analyst.

The Agile Extension to the BABOK® describes “business analysis areas of knowledge, their associated activities and tasks, and the skills necessary to be effective in their execution within the framework of agile software development”.  Below are 3 misconceptions that, in my opinion, the current draft of the Agile Extension is helping perpetuate.
 

Instead of taking for granted that either you find a flavor of agile that will fit the needs of your organization, or you must completely dismiss the use of agile methods, a much more valuable approach is to determine, for each individual project, which agile concepts should be embraced or not.

By taking a closer look at how your company is developing software, and what is working for projects with different profiles, it’s possible to leverage winning strategies and hybrid approaches to make your software initiatives equally or more successful in the future.

This article proposes a V-Model for agile development testing and invites feedback from the reader. The agile method used in this article is Scrum; the author assumes the reader is familiar with this solution development life cycle.

My understanding is that, in practice, successful agilists tend to bring together a number of activities, tasks, and deliverables that are from beyond the boundaries of what may be called “pure agile.” This mixing and matching of software process elements from agile and non-agile (more formal) approaches is a much more practical way of using these methods.

Software development process is undergoing seismic shift from traditional waterfall software methodologies towards agile methodologies. Agile software development methodologies deliver high quality software products in rapid iterations with high flexibility and adaptability to changing conditions. This article discusses the dynamics of agile projects by comparing it with the SDLC project framework to help the IT leaders and organizations plan effectively for transitioning to Agile software development methodologies.

As agile methods become widespread in organizations, it’s not surprising to see the idea of the business analyst as a dispensable role taking root among IT project teams. After all, in agile approaches, tasks typically performed by a business analyst, such as requirements elicitation, analysis and documentation, are replaced by a conversation between customer and developers.

How come product owners and teams struggle to use the product backlog effectively? One of the reasons lies in the linear nature of a traditional product backlog: It is a list of "features, functions, technologies, enhancements, and bug fixes," as "Agile Software Development with Scrum" states. Such a list works well for creating a simple product. But it can be inappropriate for a more ambitious one.

Whether it is in software development, business analysis, portfolio management or business strategy, everyone wants to be Agile - and nobody wants to admit they aren't Agile. But what does it really take to be Agile? What is the state of Agility like?

 Adult children. Jumbo shrimp. Seriously funny. I’m sure you recognize these expressions as oxymorons—self-contradictory phrases, often with an ironic meaning.  Should we add “agile requirements” to the list? Does agile development fit in with traditional requirements practices? And if so, how?
 

The benefits of Agile methods are becoming more obvious and compelling. While the most popular practices were developed and proven in small team environments, the interest and need for using Agile in the enterprise is growing rapidly. That's largely because Agile provides quantifiable, "step-change" improvements in the "big three" software development measures - quality, productivity and morale. Confirming Agile's benefits, hundreds of large enterprises, many with more than 1,000 software developers, are adopting the methodology.

Regarding software architecture, it's interesting to note that it is the "lighter-weight" Agile methods, specifically Scrum and XP, that are seeing the broadest adoption in the enterprise.