SDLC, Process, and Methodologies

15932 Views
14 Likes
2 Comments

Ron Ross and Gladys Lam have written an important book for the business analyst community. It aims to get business analysts out of the technology ghetto that many of us get stuck in. Regardless of the type of analyst you are, I think it would be worth your time to get your hands on and read this book. I’ll explain why below.

22785 Views
463 Likes
31 Comments

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.
 

8768 Views
1 Likes
0 Comments

In a nutshell, a methodology represents a series of steps in a project specifying Who is to perform What, When, Where, Why, and How (aka, "5W+H"), from start to finish. Perhaps the best way to think of a methodology is as a roadmap or an assembly line where a product is developed over a series of work stations.

22610 Views
8 Likes
0 Comments

Lean techniques use a process-oriented approach. In non-industrial organizations however, the process is invisible. In order to apply Lean techniques successfully in this environment, the visibility of processes has to be significantly increased. Employees have to learn to look at their organization from a process viewpoint. Furthermore, it is important that the method is applied to all layers of the organization.

18144 Views
8 Likes
8 Comments

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.

10567 Views
48 Likes
1 Comments

Many IT managers have chosen to execute long-term projects in an iterative approach rather than a single linear fashion. This approach is not necessarily agile as the methodology is still “waterfall”-based but rather a series of waterfall executions (or terraced). This approach introduces new challenges for business analysts.

18286 Views
5 Likes
2 Comments

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.

23453 Views
16 Likes
1 Comments

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.

14014 Views
9 Likes
0 Comments

In I.T., are we really spending too much time on "maintenance"?  Within any systems development organization, there are but three types of work effort: new systems development, maintenance, and modification/improvements. A mature development organization will spend approximately 5% of its time on new development, 10% on maintenance, and 85% of its time on modification/improvements.

17818 Views
8 Likes
1 Comments

I'm hearing the word "value" a lot lately. This is partly because the economic downturn has us looking to get the most for our money. But that's not all. More and more managers, business analysts, programmers and testers are talking to me about value. They are concerned that their products provide value for their end users. Many of them express a kind of process or tool fatigue. They are tired of being told that using a particular process or toolset is the key to their success. To them, value is a more important concept.

21437 Views
15 Likes
1 Comments

Systems work is not as hard as you might think. However, we have a tendency in this business to complicate things by changing the vocabulary of systems work and introducing convoluted concepts and techniques, all of which makes it difficult to produce systems in a consistent manner. Consequently, there is a tendency to reinvent the wheel with each systems development project. I believe I owe it to my predecessors and the industry overall to describe basic systems theory, so that people can find the common ground needed to communicate and work. Fortunately, there are only four easy, yet important, concepts to grasp which I will try to define as succinctly as possible.

29518 Views
9 Likes
3 Comments

Lean processes—whether you’re building bicycles, assembling TV dinners, or developing software—are all about value. Activities like rework, reprocessing, reformatting, storage, handling, and sign-offs are not valuable. In lean terminology, they’re waste.

24329 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.

53245 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.

13012 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

Page 3 of 5First   Previous   1  2  [3]  4  5  Next   Last   


Upcoming Live Webinars

 

Copyright 2006-2021 by Modern Analyst Media LLC