Non Agile Technical Roles

[TheGreenBastard]

The Agile Manifesto is so simple that most of the people I have chatted to have misinterpreted it.

Prime example: “Working software over comprehensive documentation”

To many that means NO documentation.

The difficulty lies in the transformational complexity and not the actual implementation of it.

Case in point: you're saying it's being done wrong, because your interpretation of vague statements is the one true way(tm).

[ChrisFromGreece]

Case in point: you're saying it's being done wrong, because your interpretation of vague statements is the one true way(tm).

If anyone thinks that by reading 4 sentences they can practice Agile, then trust me there are other bigger problems that need to be addressed.

[LondonManc]

That means that the effort to move from a Waterfall mindset and approach to an Agile one is massive compared to actually being Agile and operating as such (the implementation of it).

If you start a brand new project as an Agile project it will go a lot smoother than transitioning one mid-ways from Waterfall to Agile.

But that's a given for any type of project methodology move, even stopping where you are in Agile and switching to Waterfall (or V-model for that matter).

That's no different to, for example, switching your BI toolset from Cognos to BusinessObjects versus implementing BusinessObjects from scratch and holds true in most aspects where you're switching between ways of doing things versus starting from scratch.

[ChrisFromGreece]

But that's a given for any type of project methodology move, even stopping where you are in Agile and switching to Waterfall (or V-model for that matter).

That's no different to, for example, switching your BI toolset from Cognos to BusinessObjects versus implementing BusinessObjects from scratch and holds true in most aspects where you're switching between ways of doing things versus starting from scratch.

Maybe I should have made the "mindset" word bold and underlined

[LondonManc]

Maybe I should have made the "mindset" word bold and underlined

No, it's fine. I mentioned that Agile is a mindset earlier. The problem is that agile is either done in its entirety or done badly. Switching methodologies part way through a project is a red herring; paying casual attention to Agile and simply creating an agile story board and having scrums because you've heard agile is good is the problem. Starting a project as waterfall and seeing it through as waterfall is fine. I'd personally say that I've seen most success with agile come with websites and similar things where delivering small pieces of functionality into production is appropriate. People simply using agile as an excuse not to make proper project plans is something I wouldn't be keen to be part of.

[MrMarkyMark]

No, it's fine. I mentioned that Agile is a mindset earlier. The problem is that agile is either done in its entirety or done badly. Switching methodologies part way through a project is a red herring; paying casual attention to Agile and simply creating an agile story board and having scrums because you've heard agile is good is the problem. Starting a project as waterfall and seeing it through as waterfall is fine. I'd personally say that I've seen most success with agile come with websites and similar things where delivering small pieces of functionality into production is appropriate. People simply using agile as an excuse not to make proper project plans is something I wouldn't be keen to be part of.

Completely this.

[ChrisFromGreece]

No, it's fine. I mentioned that Agile is a mindset earlier. The problem is that agile is either done in its entirety or done badly. Switching methodologies part way through a project is a red herring; paying casual attention to Agile and simply creating an agile story board and having scrums because you've heard agile is good is the problem. Starting a project as waterfall and seeing it through as waterfall is fine. I'd personally say that I've seen most success with agile come with websites and similar things where delivering small pieces of functionality into production is appropriate. People simply using agile as an excuse not to make proper project plans is something I wouldn't be keen to be part of.

Agreed in most part, disagree with the Agile being successful with websites or where small piece of functionality is possible.

I would argue that a great use case is a massive regulatory project such as MIFID-II. You can keep deploying in production throughout the project so that you prove that particular functionality (whether it's transformations, a new service for the entity hierarchy rollup, etc) even if End-to-End testing is not possible both from your end and the regulators' one.

Things can also be mocked out to remove possible dependencies and when actual implementations come into play (from the dependencies) you hook up to them and start refactoring... as they never work as they should.

[Dark Black]

My last contract, the code review would pull up anyone who commented their code. Part of the agile process was to not comment code, it was seen as a pointer to obscure code and a time waster.

Seriously...?

I'd walk away from any contract like that since whoever came up with that obviously had no idea on long term code maintainability.. It doesn't need to be obscure, commenting code properly can save a lot of time later for someone else when trying to sort out problems.

I can't believe that's part of the agile process to be fair.. just someone being a complete twunt..

[ChrisFromGreece]

Seriously...?

I'd walk away from any contract like that since whoever came up with that obviously had no idea on long term code maintainability.. It doesn't need to be obscure, commenting code properly can save a lot of time later for someone else when trying to sort out problems.

I can't believe that's part of the agile process to be fair.. just someone being a complete twunt..

It is indeed a bit extreme, since it's nowhere prescribed as part of any agile process (as far as I am aware).

Yet am an advocate of less comments than more in the code since it quickly becomes noise. Code should be self explanatory... if you need comments all over the place, then maybe you need to rethink the design?

[The Plantswoman]

Agile is a mindset and if not everybody is in it, it will fail.
It also depends very much on the industry. I've just delivered something that had a nailed down spec from the start. I severely doubt that it would have benefited from an Agile approach, but can see how certain things can be delivered (having been part of an agile team many moons ago).

As you say, those using agile as an excuse not to document what they do will struggle. That said, I'd make sure all code is thoroughly commented so that no other documentation is needed. Declare a standard then you only need to document the non-standard

Yes indeed.

And, for example, wasting my time on voting for what feature of the last sprint should appear on the "cool wall" during a sprint retrospective is NOT what I ever signed up for.