What methodology are you working in?

I was intrigued by an answer given on another thread that Agile doesn't work in a large program/project.

I'm interested to find out what methodology you work in and whether you believe it is working. I've seen both traditional (waterfall) and agile working on project both large and small with localised and distant teams. I've also seen it failing. But then I've also seen traditional projects fail with localised and small projects.

So what methodology do you work in?
Do you think it is working for your project?
If you have tried switching to agile, did it work/not work and if so, why?

Rob..

Views: 3

▶ Reply to This

Replies to This Discussion

Permalink Reply by Ainars Galvans on October 25, 2009 at 19:14
I work in a project that does not follow the methodology (no SCRUM, XP, TDD, or anything). A lot of procedures are documented but we are not bound by them. We try to deliver weekly but 1) customer decided if they want to look at a each delivery (and may as well ignore it as they have done seldom). But we are free to delay delivery a day or two or even skip a delivery. Development as well as testing practices depend on each individual doing it but we have team leaders who stick everything together. I can't say everything goes perfectly well, but I don't think we are Failing...

Basically I don't have any black or white answer to any of your questions.
Permalink Reply by Rob Lambert on October 25, 2009 at 19:20
Ainars,

I think this may be the same for a lot of testers and teams. Everyone works in a unique way.

It sounds like you are hedging towards agile though as you are delivering weekly and are engaging with your customers regularly. Well. It sounds like you are adopting some agile principles as I don't believe there is just one methodology that can be defined by the term agile.

Thanks
Rob..
Permalink Reply by Stephen Hill on October 26, 2009 at 9:35
I'll be interested in the answers you get to this one, Rob. In my case we seem to follow a hybrid of waterfall (as opposed to the V-model version) and eXtreme Programming (XP). I am pleased to say that slowly but surely the waterfall part is becoming a V but it is taking time on the older, long-running, projects to get testing integrated throughout the project stages.

I think our approach works reasonably well for us - although there are problems they are not disastrous - the types of project we have on the go require everything to come together at once but the constituent parts are not well understood or documented.

Stephen
Permalink Reply by Mohinder Khosla on October 27, 2009 at 12:04
Methodology what methodology? We are so used to waterfall model (V-model) that we hate to lose its influence. I have always been very critical of this method of software development that put you in a straight jacket. You in general have to go through all the stages and produce all the deliverables before you see light at the end of tunnel. I have seen projects where the product delivered at the end of development cycle is no more required due to change in business directions or regulatory imposition. I quite like Agile that has no expected set of deliverables except the end product to the required specifications. No matter which development framework you pick, the ultimate aim is to reliably turn requirements and design into application code that meets customer needs and is delivered as per customer defined timescale. Consistency is the key word in all that as they say ‘consistency is a quality unto itself’.
Permalink Reply by Brian Buckmaster on November 2, 2009 at 13:13
Well, I'm not particularly married to the waterfall methodology, but I have yet to see anything come along yet that is superior. I've heard many criticisms of the waterfall model - horror stories of failed projects, and each time I have to wonder if the problem was due to deficiencies of the model itself or the way the project was executed.

Software development is a discipline which requires systematic, disciplined approach by all participants, and that's why I'm not a proponent of the so-called agile approach, which encourages an ad-hoc style. This is not to say that agile has not place. But I won't step on an airplane whose Flight Management System (FMS) was developed under an agile model (hear that Honeywell?).
Permalink Reply by Rob Lambert on November 2, 2009 at 13:22
Brian,

I think the problem that agile faces is this belief that it is ad-hoc.

In my experience (and I'm an agile fanboy) agile projects are more disciplined. In fact they have to be in order to deliver consistently and in short time scales.

It takes a few sprints before a team hit their stide but if they are doing things properly then it is awesome to see. Software just works and rolls out at such regular intervals that the customer starts to get value from the start.

Speed requires discipline. Agile has documentation, lots of it, but documentation aimed at the right people, pitched at the right level and produced at the right time. There are stats and reports available at all times. The swim lanes clearly show the work to be done and Mohinder is right in that the end results is not stats, metrics or reports, but fully working software.

I was incredibly skeptical of agile when I first moved to it. In fact I hated it. It took away my control and my stability. Well, I thought it did. And then I settled in, gave it some time and had my Eireka moment.

But, at the same time it is not right for all projects, it might not suit all teams and if waterfall truly is working then why change it?

And I've seen agile implemented in all sorts of environments from financial critical systems to huge corporates like BT and IBM.

My belief is that the team make the project. And if you have a great team they will make waterfall work, just like they will make agile work. A bad team will fail no matter what methodology. But the beauty of agile is that it structures your project in such a way that you get to find out how good your team is early in the process.

Just my thoughts on it. :)

Rob..
Permalink Reply by Andy Glover on October 27, 2009 at 14:25
In my development department, we follow an iterative life cycle that can sometimes become a v-model when it's a small sized project. Our iterative life cycle does work well to a point: we deliver s/w that is more or less what the customers wanted, if a bit late (sometimes very late!). We plan the projects in monthly cycles, where new functionality is delivered at the end of each cycle. The last two cycles are for bug fixing and formal acceptance testing. We work in the pharmaceutical industry, which demands lots of documentation, our SDLC allows us plenty of time to ensure the paperwork is up to industry standards.

Our Dev manager is investigating if we can move into Agile. We are finding that we already follow some of it's principles, although we still wouldn't call our selves Agile by any means. I doubt we will be able to be fully Agile due to all the documentation that is required in our industry, although most of what I've read about Agile is positive.

Some Agile literature would indicate that testers are encouraged not to raise a defect/bug report (in a defect management tool) when an issue is identified, but rather go straight to the developer and discuss it with them. Is this the case for real-life Agile developments?
Permalink Reply by Rob Lambert on October 27, 2009 at 14:41
It can be the case. It certainly is for me on most of the projects. I work by a few simple rules, but these will differ per team. But ultimately, agile is about getting the highest priority story done. And if entering each defect slows this process down, then there needs to be some 'kaizen' applied to remove the blockages.

the rules I tend to work by are:
1. If the story is broken by the bug (i.e the acceptance criteria is not met) then that defect needs fixing ASAP
2. If, when I shout to the dev it is not working, they can fix it immediately, they will. Check in > CI > Deploy
3. If, when I shout to the dev it is not working, they cannot fix immediately, it gets raised as a task agains the story. (in our world the story is not DONE if it has tasks outstanding)
4. If a defect is found that does not invalidate a story in the sprint then it gets raised as a new "story" on the backlog for the customer to decide the priority.

For me, it's a case of getting the highest priority story done 100%. Then the second highest priority 100%. And so on.

So defects get fixed immediately (where possible).

It works really well. Anything that is a bug not associated with a current story goes to the customer to decide on the priority rather than the team trying to make their own mind up about it's priority. Some things we think are critical some customers may think are trivial. And that for me, is the beauty of agile. It places the quality, decisions and commercial direction back to the customer. It is their decision.

I really love working in an agile environment. It suits my style of testing perfectly. I would also suggest that there is no reason why you cannot work agile and produce lots of documentation for your requirements. Agile doesn't mean NO documentation. It means only the RIGHT documentation. It's about only doing the things that need doing at the level that is appropriate. :)

Rob..
Permalink Reply by Jim Hazen on October 27, 2009 at 15:34
I work in the "Get er' Done!" methodology (loosely a spiral/iterative model). I'm not working in the tightly constrained time periods like the Agile methods, but it is still collaborative and parallel to others on the project. This works best for us and me as it lets me be flexible on what I work on and deliver at different periods of time during a phase and at the Milestone point. I come from a background using MSF and RUP, I prefer MSF because it is a more flexible framework.

So I stay with the Team model from MSF and work within cycles/phases of the project. I've been in a couple of places that use Agile (SCRUM mainly) and found that certain people got to be a little too "Cowboy" in their work. But that in those situations.
Permalink Reply by Linda Wilkinson on October 27, 2009 at 15:38
We use an interative model here, with 4 scheduled releases per year and multiple "mini" releases between them. A "mini" release is anything that doesn't require a customer outage. It works extremely well; flexible enough for us to move quickly when we have to, and "just enough" structure to remain SOX and audit compliant. We produce code that works to our clients with a minimum of thrash.

I've seen agile tank on multiple occasions (not here) primarily due to lack of experience and training. You need project leaders/managers that know what they're doing to make it work!

- Linda
Permalink Reply by Joe Strazzere on October 27, 2009 at 15:59
We use the "None of the Above" Methodology.

We have many projects going on at any one time - some short duration, some long. Some are minor, single-customer-specific project, others are major releases to core functionality. Some involve just a small, local team, others are spread out to include our India team as well.

The "methods" and "ology" for each project are derived as part of the project planning process. So far, none have been what others would usually call Agile.

Yes, it's working so far.
Permalink Reply by Asmaa Magdy on October 27, 2009 at 16:32
I totally agree with "None of the above". I guess this is totally project dependent.

For me, i work on a business intelligence project. It integrates many tools and technologies such as (Sharepoint, performance point, Microsoft pro-clarity, sql server services (SSIS, SSAS and SSRS) and kerberos delegation ).
So, from the outside it looks like agile (because Sharepoint is a content management tool) which is true. But if we look deeper, we'll see that the business part requires waterfall because of the complex business rules that don't change throughout project phases.
Also, i think it depends on the nature of your client. Sometimes, clients are constantly changing their minds about stuff. So, the waterfall would be a total mess.
So, it doesn't have to be either/or. You could use whatever serves your software service best. :)

RSS

© 2012   Created by Rosie Sherry.

Badges  |  Report an Issue  |  Terms of Service