Reply to: Non Agile Technical Roles

[tomtomagain]

To all you agile-haters out there.

How would you like to work? Describe your perfect environment.

[VillageContractor]

Exactly, which is why some orgs are simply better not doing agile but simply using some of the tools that have sprouted up around it but not using others.

Yes - but they need someone experienced who knows what to do and what not to do. That's where I come in

[LondonManc]

Agile uses a lot of smart and simple processes that can be used anywhere. Not all organisations can become agile on day 1 or day 365 so sometimes you have to tailor your adoption to suit you. But if it's done badly it will go horribly wrong.

Exactly, which is why some orgs are simply better not doing agile but simply using some of the tools that have sprouted up around it but not using others.

[VillageContractor]

There are some good tools and methods that Agile uses; rather that declaring the project as agile, declare it as hybrid; waterfall methodology with agile techniques that work in a waterfall environment. Use daily scrums and a story board for visibility and for short term stage-planning. Waterfall can fall victim to analysis paralysis but at least the senior management get a plan to hold someone accountable to.

Agile uses a lot of smart and simple processes that can be used anywhere. Not all organisations can become agile on day 1 or day 365 so sometimes you have to tailor your adoption to suit you. But if it's done badly it will go horribly wrong.

[LondonManc]

There are some good tools and methods that Agile uses; rather that declaring the project as agile, declare it as hybrid; waterfall methodology with agile techniques that work in a waterfall environment. Use daily scrums and a story board for visibility and for short term stage-planning. Waterfall can fall victim to analysis paralysis but at least the senior management get a plan to hold someone accountable to.

[Cirrus]

Are you Shia or Sunni?

It's all religion.

I said to my boss "We're running in an agile way on Project X"

He got aggressive and said "You're agile: so where's your backlog; where's your kanban"

He runs a Scrum-type set-up with about 3 developers out of a team of 50; requirements have to be submitted 3 weeks before the sprint; lots of people standing up all the time and loads of post-it notes.

Agile originally meant two things. The first was anti-waterfall ie waterfall is a load of rubbish so consciously avoid all the nonsense bits (eg toolsets, frameworks, specs etc). The second bit - unfortunately - is try our alternative religion. The founder members were also the purveyors of their own methodologies - Scrum, XP, Crystal, DSDM etc.

The former is no good to pointy hats so the latter has prevailed: agile instead of saying Islam makes no sense in the modern world has merely substituted replacement religions.

[ChrisFromGreece]

+1 to VillageContractor

The CSM, CSPO and CSD certifications from Scrum Alliance (and the similar ones offered by Scrum.org, etc.) are introductory courses where you attain basic knowledge of the framework and the particulars of a specific role.

Completing a 2-day course should never allow you to claim to be an Agile Coach and companies who are serious about their Agile Transformation should be a bit more diligent with their search for an Agile Coach. Experience as well as continuous education and contribution to the Agile community should be a few of the things to consider while recruiting for an Agile Coach.

To me it's similar to the tech certs. You are not a Java expert if you got the Oracle Java Cert and you are not automatically an Enterprise Architect cause you got the TOGAF cert.

[VillageContractor]

Most people dislike agile because they've sen it done wrong. I see a lot of Scrum Masters/PMs and Agile coaches who have gone on the 2 day CSM course and think they know everything.

It's even worse when you get companies who want to be agile but don't really want to do everything that makes them agile. They want stand ups and buzzwords but not the organisational change that will actually benefit them.

[ChrisFromGreece]

Waterfall would mean that business had to think hard of the end to end picture, it would have left me to focus on business and getting a commitment from them on what they want and clarify the calculations, instead of me wasting my time with dev and test ... waterfall means the project team can first focus on requirements, once that signed off then on development, and ironing any issues, then on testing... these stages can overlap a bit but not totally as in Agile...

You can always say oh the fault is not with the method its with the way its applied, but I haven't seen any methodology applied perfectly, however Agile makes a pig ear of all project I worked on, it maybe suitable for the business, or indeed developers as both can blame each other, but not for the project team !!

Anyone here is welcome to join Agile lovely madness, not me ...

Not trying to convince you about anything here and it's great to hear about peoples' experiences; it's just that some things don't make sense to me.

As a PO that is exactly your job: focus on business and getting a commitment from them on what they want and clarify the calculations if that functionality is to be included and delivered in the next Sprint(s). Don't see how this is different to do under Waterfall. You still need to clarify the requirement on way or the other.

Seems that you were "wasting time" because the requirement was not properly defined/clarified. This has nothing to do with Agile... you would have the exact same issue with Waterfall.

Having said that, weren't the User Stories written signed-off by the business? If not, then you are not doing Agile properly and not really fair to say that Agile is not working.

Sorry to say, but by the looks of it, you are at the other end of "applying the methodology perfectly"

[SandyD]

Wait, I may be missing something here...

Never had a project in Banking with no PM... well you can and instead you can have a PO.

So if the business signs off and commits to the requirements how does that solve the problem that the developers and testers don't understand the functionality?

And why is that massively different to describing that requirement in a User Story with Acceptance Criteria and signing it off as a Product Owner?

You also said that even the business didn't know what they wanted or how the functionality should work. How was Waterfall helpful in that situation compared to Agile?

To me it seems that trying to be Agile was quite useful in exposing the following (transparency):

• Lack of business knowledge from Devs and Testers
• User Stories that did not contain enough information for Devs to complete their task
• Opportunity to introduce changes that can be picked up in the next Sprint (rather than introduce a CR to go through all the necessary sign-offs, etc.)

Waterfall would mean that business had to think hard of the end to end picture, it would have left me to focus on business and getting a commitment from them on what they want and clarify the calculations, instead of me wasting my time with dev and test ... waterfall means the project team can first focus on requirements, once that signed off then on development, and ironing any issues, then on testing... these stages can overlap a bit but not totally as in Agile...

You can always say oh the fault is not with the method its with the way its applied, but I haven't seen any methodology applied perfectly, however Agile makes a pig ear of all project I worked on, it maybe suitable for the business, or indeed developers as both can blame each other, but not for the project team !!

Anyone here is welcome to join Agile lovely madness, not me ...

[LondonManc]

This was a project 2 years ago ... The developers insisted it should be agile, I never had a project in Banking with no project manager !!

Sprint were 2 weekly, yes there were use cases, but functionality was very very complex, plus them being in India and they were just technical had no clue about the brokerage in IB meant a lot of explaining and checking of how to calculate each product brokerage... heck even front office traders had issues committing and agreeing how its calculated !!
To do automated test cases, you'd need to understand functionality ... so hence had to meet with them over and over !!

IMO water fall, firm signed off specifications are best with the business to commit to requirements, even with the inevitable change !!

I know there are many who are very pro Agile ... me NOOOOOO thank you.

With complex calculations that rely on specific data feeds, signed off, nailed down specs are a must, especially when you look at the lead times in many large places to get things done and re-done.

Agile has its place and must be signed off from the top. In your case I'd also point to members of the team not being good enough, especially your main guy if he can't design a database for you.

[ChrisFromGreece]

This was a project 2 years ago ... The developers insisted it should be agile, I never had a project in Banking with no project manager !!

Sprint were 2 weekly, yes there were use cases, but functionality was very very complex, plus them being in India and they were just technical had no clue about the brokerage in IB meant a lot of explaining and checking of how to calculate each product brokerage... heck even front office traders had issues committing and agreeing how its calculated !!
To do automated test cases, you'd need to understand functionality ... so hence had to meet with them over and over !!

IMO water fall, firm signed off specifications are best with the business to commit to requirements, even with the inevitable change !!

I know there are many who are very pro Agile ... me NOOOOOO thank you.

Wait, I may be missing something here...

Never had a project in Banking with no PM... well you can and instead you can have a PO.

So if the business signs off and commits to the requirements how does that solve the problem that the developers and testers don't understand the functionality?

And why is that massively different to describing that requirement in a User Story with Acceptance Criteria and signing it off as a Product Owner?

You also said that even the business didn't know what they wanted or how the functionality should work. How was Waterfall helpful in that situation compared to Agile?

To me it seems that trying to be Agile was quite useful in exposing the following (transparency):

• Lack of business knowledge from Devs and Testers
• User Stories that did not contain enough information for Devs to complete their task
• Opportunity to introduce changes that can be picked up in the next Sprint (rather than introduce a CR to go through all the necessary sign-offs, etc.)

[SandyD]

For one Agile doesn't have a PM role, but I'll park this for now.

Apologies for the questions below, but bear with me...

• Where exactly are you Agile?
• Is it because you have the "prescribed" Agile meetings?
• How big are your Sprints and how often do you release in production?
• How big is the team and is it cross-functional?
• Why do you need to explain again and again the functionality? Aren't requirements being defined as User Stories with proper acceptance criteria?
• Test Lead??? Are you not following TDD? DevOps pipeline with automated tests?

Clearly from what you say I don't see any collaboration or communication between your team members.

Where exactly are you Agile?

This was a project 2 years ago ... The developers insisted it should be agile, I never had a project in Banking with no project manager !!

Sprint were 2 weekly, yes there were use cases, but functionality was very very complex, plus them being in India and they were just technical had no clue about the brokerage in IB meant a lot of explaining and checking of how to calculate each product brokerage... heck even front office traders had issues committing and agreeing how its calculated !!
To do automated test cases, you'd need to understand functionality ... so hence had to meet with them over and over !!

IMO water fall, firm signed off specifications are best with the business to commit to requirements, even with the inevitable change !!

I know there are many who are very pro Agile ... me NOOOOOO thank you.

[ChrisFromGreece]

I am glad to see developers here also hate Agile, as a BA/PM hate it with passion, now I run away when agents mention Agile to me.... my last project daily grind: 8:30 Stand up with India, end up explaining for the 1000's time what they were supposed to do this sprint, not to mention backlog items. 9:00 So many issues and queries from the stand up, so I spend 30 minute with dev lead explaining going through requirements, then 30 min with Database architect from India (Of course at the end I end up designing his databases and entity relationship for him), then 30 minutes with Test lead, they needed to explain to me why they couldn't test previous sprint, they needed me to explain requirements and flows all over AGAIN ... even though I spent days explaining it to Dev and them, but dev just can't be bothered to speak to the testers who sit next to him in India !!
Then 30 min or more meeting with business for next sprint requirements, then 30 minutes with Program management updating progress, then an hour or so speaking to project members reporting to me in London, after 2pm then am free to do my work, which is checking last sprint test results, investigating errors, preparing next sprint requirements, and designing next test cycle cases... by around 8pm am dead and I didn't even get to have a lunch break...
End of the week, big status report, of course most sprint end up with more items on the backlog than actually delivered !

And this wasn't my first Agile project, almost all of them end up in this mess...

Unless am starving I wont take a role involving Agile ever again !!

For one Agile doesn't have a PM role, but I'll park this for now.

Apologies for the questions below, but bear with me...

• Where exactly are you Agile?
• Is it because you have the "prescribed" Agile meetings?
• How big are your Sprints and how often do you release in production?
• How big is the team and is it cross-functional?
• Why do you need to explain again and again the functionality? Aren't requirements being defined as User Stories with proper acceptance criteria?
• Test Lead??? Are you not following TDD? DevOps pipeline with automated tests?

Clearly from what you say I don't see any collaboration or communication between your team members.

Where exactly are you Agile?

[stek]

Sounds like a complete loads of old bollocks to me, sing if you're glad to be techie...