Say for example, you are in charge of a particularly large project, with a big time frame, and you and your team decide that Agile would be a better methodology to follow. Is it practical/possible to change from one methodology to another during a project?
2 Answers
It is definitely possible to adopt an Agile approach on an existing traditional project. I have seen this done many times and although the results varied there was always recognisable benefit.
Remember that Agile is an approach to doing development. There are a wide variety of Agile frameworks and techniques that can potentially be useful. You don't have to adopt them all right away.
One thing I would recommend is that you clearly identify the reasons for switching to Agile. Do you want to be more adaptable to change? Do you want to have more frequent releases? This will help you to determine what aspects of Agile you chose to follow.
Things that are likely to provide early benefits include:
- Looking to do interim releases rather than waiting until the end of the project
- Doing regular retrospectives where the team discusses ways they can improve
- Engage regularly with your end users, perhaps using showcases to demonstrate work that is 'done'
- Prioritising your requirements so that the team is working on the most important things first
answered May 9, 2016 at 21:04
If it's a particularly large project then agile probably isn't a good idea. However, I think that we could easily be talking about a personal interpretation of 'particularly large'. I use the term to describe 100's of programmers and many more testers, managers, designers, architects, stakeholders, etc. on a multi-year project costing tens of millions of pounds/dollars/euros and spanning many business centres, possibly internationally. I'm thinking of programmes to generate control systems for new nuclear reactors, or the James Webb telescope/satellite. Projects this size shouldn't be agile.
If you mean something smaller then you probably should have been agile to being with -- this is 2016, not 1998 -- this stuff really isn't up for debate any more. What were you thinking by not trying to be agile in the first place?
Anyway, none of that will help. You should change to an agile approach as quickly as possible. Start by breaking your project into features and your requirements down into stories, store them in jira. For each story provide a cost, preferably in money, and a value, also in money. Then have the stakeholders (all of them -- product-owner, business, users, ops, devs, testers) prioritise the stories. Then start feeding the team the stories, tracking how they progress on a kanban board. If you're going too slow, start limiting work in progress and you'll go faster. Practice TDD, BDD, DDD, CI and CD. Feed stories sequentially to the devs via jira, and track their progress the same way.
Do all of this. Do it now. If you hurry you might just save your project and your shareholders might not eat you alive for having failed in your fiduciary duty to control risk (which is what agile is for).
And, above all, have fun. It's meant to be fun.
-
2No offense, but context is everything - without a LOT more info from Sam, simply prescribing "agile ASAP" (even for a tiny project) isn't very responsible. It ignores predictability of inputs/outputs, platform/service constraints, his org's culture, expectations, team personnel, partner relationships, and on and on. Commented May 9, 2016 at 20:56
-
1I didn't dictate the form of agile -- that is open to debate. However, waterfall and V don't manage risk and as such are open to criticism on this basis. Further, we all know that waterfall is actually damn near impossible, except in the extremely expensive environments I highlighted above, and that one actually ends up with both no development process and a formal system of lying to one's stakeholders and methods of justifying those lies. Make the decision to become honest now, and decide how to implement that later based on your organisational variables. Sorry if my suggestion wasn't clear. Commented May 9, 2016 at 21:04
-
1"Waterfall" is not impossible (and is actually beneficial) in situations where the development is highly repetitive and predictable, and the risks are tied to maintaining revenue (contracts, relationships, perception, etc.) rather than product fitness. That's what I mean by context, sorry if that wasn't clear. I am by no means a waterfall proponent - I've done far more agile overall, and prefer it - but it simply isn't appropriate in all situations. Commented May 9, 2016 at 21:11
-
Waterfall is not impossible; try being Agile in a construction environment where concrete must be mixed and set within certain timeframes whilst concurrent activity must take place or else counter-charges start to roll in. There is no collaboration over following a plan when building a skycraper. Commented May 10, 2016 at 10:01
-
Check the Chaos report from the Standish Group: Teams < 50 get about 25% improvement from Scrum; Teams > 50 get around 200% improvement from Scrum. Bottom line: Always use agile methods, especially on large projects... Commented May 15, 2016 at 18:03