Discussion on:
View:
Show:
What if you have a dispersed, diverse set of end users and you do not have a well defined system scope? Does Agile help then or do you need to spend some time scoping and understanding what the needs are before launching an Agile effort?
In a way, agile helps when you do not have a well defined system scope as you can build first then improve once those generic features is there and user help build it by testing it. Rather than you never build it because you can never really determine what's the final scope or how the system should be built.
But this then also have a downside that sometimes the user project scope can lost its focus.
Good direction, project management and clear goal of the system will help to maintain the application development to achieve the goal.
But this then also have a downside that sometimes the user project scope can lost its focus.
Good direction, project management and clear goal of the system will help to maintain the application development to achieve the goal.
Agile helps in bringing the business user and IT closer and lower the possibility of failed project as with waterfall, often that the system design might not touch the detailed operational need of the business user. Agile with its constant short development cycle help to address this.
But there is also a problem compared to the waterfall where in the waterfall, the involvement of the business user is heavy at the start and at the end, but for agile, it need constant interaction with the business user. Very often that the business user always busy and does not have enough time to constantly meet with the IT and review the product delivered, hence this can lead to the downfall of the agile methodology.
But there is also a problem compared to the waterfall where in the waterfall, the involvement of the business user is heavy at the start and at the end, but for agile, it need constant interaction with the business user. Very often that the business user always busy and does not have enough time to constantly meet with the IT and review the product delivered, hence this can lead to the downfall of the agile methodology.
Sorry to be a naysayer but having used agile on several projects I don't find it to be the silver bullet that it's cracked up to be. The assertion that repeated rework and lack of design are things that make developers more effective is clearly misguided. Initially agile just puts lots of pressure on developers to deliver very fast and at the expense of quality. Then when they get used to it they learn to pad their quotes with huge margins for error sometimes five times the reasonable estimate so that each task becomes an epic and is split across many sprints but guess what, they always deliver at the end of the sprint. I find very few project managers or executives in higher management who are willing to subject their time to the same scrutiny that developers have to put up with in Agile. As for the comments on Prince methodology the author clearly has no idea what this is about since Agile methodologies can sit quite happily within the Prince framework.
The reason Agile has been so eagerly adopted is that it is the latest flavour of the month and to be anti Agile is to be anti progressive, not a career enhancing stance for most programmers. This silver bullet like many before it will disappear into the mists of time, another failed solution for overrunning IT projects. Good projects are delivered through good project management not by the latest development fad.
The reason Agile has been so eagerly adopted is that it is the latest flavour of the month and to be anti Agile is to be anti progressive, not a career enhancing stance for most programmers. This silver bullet like many before it will disappear into the mists of time, another failed solution for overrunning IT projects. Good projects are delivered through good project management not by the latest development fad.
Agile thinking has been around for quite awhile. And you are absolutely right that "good projects are delivered through good project management." That is no different for an Agile approach. Agile has key principles that must be utilized in order for the approach to work.
Saying that "We'll do Agile for everything BUT..." is like saying I'll do the traditional waterfall method and gather requirements BUT I'm not going to do a design document or I'm not going to put milestones in my project. You get the idea. That thinking doesn't work for waterfall and it won't work for Agile either.
If you are willing to embrace the approach then it can be a good tool in your toolbox. The article points out that it isn't your only tool and some projects might not be as well suited to an Agile approach. So, again your right it is not a "silver bullet" or "one ring to rule them all".
Lastly, when you have folks that are used to doing things in a particular "waterfall" way it can be hard to switch paradigms. You can't just wake up one day and say that we are going to do Agile from this point forward and we are going to do it flawlessly. It took the trust's IT department 18 months to get up to speed on this approach. It helps if you can find an industry expert or an outside firm to provide some support or training while you take on this new process.
Agile does work. There is plenty of evidence to show that it is a viable and sustainable approach.
Saying that "We'll do Agile for everything BUT..." is like saying I'll do the traditional waterfall method and gather requirements BUT I'm not going to do a design document or I'm not going to put milestones in my project. You get the idea. That thinking doesn't work for waterfall and it won't work for Agile either.
If you are willing to embrace the approach then it can be a good tool in your toolbox. The article points out that it isn't your only tool and some projects might not be as well suited to an Agile approach. So, again your right it is not a "silver bullet" or "one ring to rule them all".
Lastly, when you have folks that are used to doing things in a particular "waterfall" way it can be hard to switch paradigms. You can't just wake up one day and say that we are going to do Agile from this point forward and we are going to do it flawlessly. It took the trust's IT department 18 months to get up to speed on this approach. It helps if you can find an industry expert or an outside firm to provide some support or training while you take on this new process.
Agile does work. There is plenty of evidence to show that it is a viable and sustainable approach.
The reason agile works for us is because I can produce something the next day that _forces_ the business people to pay attention. Usually in the first meeting they're carping and whining about wasting time when we (IT) just need to build them something. They don't answer the questions I want answered and think I'm being picky and don't want to do any 'work.' Same old same old.
Next day, I give them a web page to work on and tell them this is the system unless they want to put some more work into it. Then we start talking about each of the buttons and they realize that if there are 3 different possibilities, I NEED ANSWERS FOR ALL 3 SCENARIOS. They have to put work into it.
That's the user insight that _never_ occurs in the waterfall model. For me, the best part of Agile is that it either forces the users to get involved or it lets the developers know no one cares. It's a time-saver either way.
Next day, I give them a web page to work on and tell them this is the system unless they want to put some more work into it. Then we start talking about each of the buttons and they realize that if there are 3 different possibilities, I NEED ANSWERS FOR ALL 3 SCENARIOS. They have to put work into it.
That's the user insight that _never_ occurs in the waterfall model. For me, the best part of Agile is that it either forces the users to get involved or it lets the developers know no one cares. It's a time-saver either way.
Agile is interesting and as someone other said it could fit into a PRINCE approach. just pay attention to a couple of things. Most project suffer from two critical factors:
1) Lack of project management (you are not able to control your project in terms of managing budget, timelines, scope and quality)
2) Lack of business sponsorship
If you don't fix these issues swithcing to agile project management will make things even worst, since
1) Whitout strong control on the agile iterations everything could happen
2) Whitout strong sponsorship from the business all the approach will rapidly fail since you'll loose the spin from an iteration to the next one
So my personal conclusion is that agile can make a healty project environement even more performing, but if you have a sick project environement it will not solve your problems
1) Lack of project management (you are not able to control your project in terms of managing budget, timelines, scope and quality)
2) Lack of business sponsorship
If you don't fix these issues swithcing to agile project management will make things even worst, since
1) Whitout strong control on the agile iterations everything could happen
2) Whitout strong sponsorship from the business all the approach will rapidly fail since you'll loose the spin from an iteration to the next one
So my personal conclusion is that agile can make a healty project environement even more performing, but if you have a sick project environement it will not solve your problems
What Agile is coming across as is that "forget the planning just do something"!Typical user and management responses. Its the PM who makes a difference and the complexity and lifespan of the project are big influencers. If you want to mess about with MS and desktop jobs maybe Agile is OK. The problem with starting development early is that mistakes are more difficult and costly to correct, something the waterfall method tries to avoid.
You don't necessarily need to have it all planned up front in all cases.
The value of the Agile approach is that the customer gets value from the project with a "potentially deployable product" sooner than with the traditional approaches. Since many times there are unknowns in what the end user really needs, you can mitigate that risk by delivering perhaps some initial core functionality first and then expand upon that functionality as new "needs" arise. This is where the "product backlog" comes in. There is a list of things on the product backlog and you are continually adding new requests from the user. As the product owner prioritizes that backlog some of the new needs may be prioritized above previously entered items. This flexibility means an Agile project is always focusing on the features that provide the customer with the greatest value. Planning is NOT REMOVED but occurs at regular intervals rather than all up front.
On the other hand, it might be difficult to build a bridge using an Agile approach. It would be difficult to start the east bank abutment at one point and then being Agile build the second abutment up river. Some projects may not lend themselves to being Agile and like the bridge may require most or all of the planning up front.
The value of the Agile approach is that the customer gets value from the project with a "potentially deployable product" sooner than with the traditional approaches. Since many times there are unknowns in what the end user really needs, you can mitigate that risk by delivering perhaps some initial core functionality first and then expand upon that functionality as new "needs" arise. This is where the "product backlog" comes in. There is a list of things on the product backlog and you are continually adding new requests from the user. As the product owner prioritizes that backlog some of the new needs may be prioritized above previously entered items. This flexibility means an Agile project is always focusing on the features that provide the customer with the greatest value. Planning is NOT REMOVED but occurs at regular intervals rather than all up front.
On the other hand, it might be difficult to build a bridge using an Agile approach. It would be difficult to start the east bank abutment at one point and then being Agile build the second abutment up river. Some projects may not lend themselves to being Agile and like the bridge may require most or all of the planning up front.
- Keyboard Shortcuts:
- Prev
- Next
- Toggle
