Experience of Digital and Agile working?

[Ray Singh]

I am currently working as a Interim Project Manager and enjoying my role. The comany has advertised a permanant post that I have applied for.
They are looking for a project manager with digital and agile experience. I have some agile knowledge, but can anyone give me a whistle stop tour of agile working?

Of to research google now, but thought I would ask here too.

[Flooble]

If you haven't done it, I really don't recommend you try and blag it. The mindset will be so alien to traditional experience with waterfall or stage gate projects that you are likely to either make a fool of yourself at the interview or (possibly worse) find yourself utterly unable to deliver in the role.

I had one interview (for which I was offered the job, incidentally) for an Agile PM role where the top dog interviewer told me that during the role-play exercise one applicant had broken down in tears.

I know that's possibly not the answer you wanted to hear, but given what happened to you previously I do think it's best to not try a "blag".

[SystemParanoia]

The extra money is better in your pocket than someone else's!

[Wilmslowboy]

As a mentioned above - little chance of winging it.

Best case - see if you can find a few you tube videos - but expect hours of study - it's very different to waterfall etc

There are loads of online quizzes - try one ....this one is specific to scrum

http://www.testingexcellence.com/scrum-online-quiz...

[FredClogs]

I'm not a project manager, but I am an engineer and I have worked in agile environments on and off for years. Agile is basically a way of never declaring any requirements, never designing anything efficiently or properly, never budgeting for more than the time it takes to get to the next sprint and never finishing anything. Its a project managers wet dream because the engineers are responsible for everything.

[Flooble]

Some agile methodologies (e.g. scrum) explicitly state that there are no project managers involved in the project ...

[768]

I'd suggest reading the Agile Manifesto carefully and committing it to memory.

Then read up on scrum, because for some reason invariably that's what people really mean they'll be doing when they talk about agile.

Run away from anyone with a certificate who talks endlessly about doing it "properly".

FredClogs said:

Agile is basically a way of never declaring any requirements, never designing anything efficiently or properly...

No.

[768]

It's dead simple, but many people never get their heads around it. Doesn't work with the way they've been doing Gantt charts for too long.

[stuno1]

Agile is basically working in sprints (chunks of work) to define requirements, design and develop and test an overall solution. The key difference from waterfall is that agile does not wait for all requirements to be signed off, then the full design to be signed off etc

As a result, in theory it makes it easier and quicker to deliver projects. I have been in two organisations trying to use agile methodology and neither have got it working. With nothing being signed off there is little change control and governance leaving each sprint open to change!at any time. People work in silo causing end to end design and test issues etc etc

I am fairly new to this but it seems a mess to me.

[768]

stuno1 said:

Agile is basically working in sprints (chunks of work) to define requirements, design and develop and test an overall solution. The key difference from waterfall is that agile does not wait for all requirements to be signed off, then the full design to be signed off etc

Agile has no requirement for sprints. Scrum does.

stuno1 said:

As a result, in theory it makes it easier and quicker to deliver projects. I have been in two organisations trying to use agile methodology and neither have got it working. With nothing being signed off there is little change control and governance leaving each sprint open to change!at any time. People work in silo causing end to end design and test issues etc etc

It certainly makes aspects of functionality easier and quicker to deliver. Projects, not so much, but it does cope with changing requirements; if your requirements never change it's probably not the right route. People aren't supposed to work in silos, that's the point of pair programming, the scrum daily, etc.

stuno1 said:

I am fairly new to this but it seems a mess to me.

Development often is a mess, usually little to do with the methodology.

[stuno1]

768 said:

Development often is a mess, usually little to do with the methodology.

Cheers for the reply. Maybe the working in silos issue is more of a project co-ordination one than an agile one.

[Flooble]

stuno1 said:

As a result, in theory it makes it easier and quicker to deliver projects. I have been in two organisations trying to use agile methodology and neither have got it working. With nothing being signed off there is little change control and governance leaving each sprint open to change!at any time. People work in silo causing end to end design and test issues etc etc

It isn't really the case that "agile" means "nothing is signed off". To use the Scrum terms, you have a Sprint Review where the product owner determines if the work is "done". In any agile method you will have acceptance and quality criteria, no different to a normal project. One of the key planks of the agile manifesto was to stop working in silos and put the people using the system in a tight loop with the people developing it. The idea was to get away with the waterfall approach of the users being interviewed by a business analyst who wrote a spec, chucking that over a wall to besigned off by managers (not users) who then threw it over the wall to the architects who designed a high level solution thrown over another wall to the developers (and testers) who then chucked it back to the users about six months later. With an end result that was several degrees different to the original requirements thanks to the Chinese whispers and was also by definition a solution to the problem that existed 6-12 months earlier.

stuno1 said:

I am fairly new to this but it seems a mess to me.

All development is a mess as it is inherently invisible and to an extent the ultimate exertion of human brainpower. There is nothing physical to poke or prod and the difference between working and not working may be a single comma in the wrong place. It's like maths and art thrown together. The point of agile was to make several smaller messes which could be cleaned up more easily than a single steaming piled up mess.

If you think about it, the Apollo program was "Agile". They didn't just build a single Saturn V and fling three guys at the moon. Multiple missions, building and improving each time and learning the skills (in fact Gemini was used to develop several items, such as on-orbit rendezvous, which were needed for Apollo). So there's nothing new about it ...

Edited by Flooble on Tuesday 22 November 10:47

[stuno1]

I'd like to work in an environment where agilenis adopted and utilised properly. My last project was waterfall and worked very well with a team of IT and business BA's working collaboratively to elicit requirements from the business, architects, developers and testers. This collaborative approach was very effective in ensuring the business requirements were delivered in a way the business stakeholders wanted/envisioned. No methodology is perfect but big organisations seem to struggle to adopt agile in an effective manner. Too many change practitioners simply don't understand how to utilise agile.

[bga]

stuno1 said:

No methodology is perfect but big organisations seem to struggle to adopt agile in an effective manner.

In my experience that is due to it often being implemented in exactly the way that FredClogs has described. The theory is sound, the implementation less so. That doesn't mean the principles aren't sound.

stuno1 said:

Too many change practitioners simply don't understand how to utilise agile.

In reality agile methods give a perfect opportunity for delivery teams to disappear up their own backsides. If anything stronger governance and change is required to ensure that the relevant change activities are being performed, especially on larger projects.

It may sound like I'm not a fan which is not true, my cynicism comes from seeing so many projects fail to deliver benefits because agile delivery wasn't managed properly or the right delivery method. One of my customers does it very well but they will use non-agile methods to develop a solid MVP & switch to agile to extend the solution.

[FredClogs]

I was being overly cynical, I work mostly in hardware... I can see how agile can work in a pure ongoing software environment, something like Facebook for example where continual changes and ideas occur and implemented to a core product with continual testing... But in hardware land where we start with nothing and the aim is to get back to a blank sheet of paper as quickly as possible so we can start the next clusterfk agile isn't always the best. Plus the sums of money involved in ordering tools for mechanical designs or PCBs etc... mean you'll always have to go outside the agile team to get permissions and sign off, so the engineers never really get the control that they should under a true agile method.

Horses for courses.

[bga]

Agreed. It generally doesn't work for ERP implementations but is great for iterative improvements.

[wiggy001]

bga said:

Agreed. It generally doesn't work for ERP implementations but is great for iterative improvements.

I've worked on a couple of ERP projects that have tried to use Agile. Both have quickly been renamed Fragile as the project falls apart and reverts to traditional waterfall.

[Flooble]

wiggy001 said:

I've worked on a couple of ERP projects that have tried to use Agile. Both have quickly been renamed Fragile as the project falls apart and reverts to traditional waterfall.

I suspect ERP is the last place you'd look to use Agile, the software just isn't geared up for working like that. It's closer to being a hardware project than a software one, with the dependencies and "frozen" aspect to the components.

[AW111]

How about when something is sold as including features that R&D have never heard about?

[wiggy001]

AW111 said:

How about when something is sold as including features that R&D have never heard about?

That's called "consulting".