CV achievements in an Agile world

[chicane]

I'm just brushing up my CV in anticipation of finding a new contract and it's got me thinking about something. It's often said that a contract CV should focus on highlighting specific and measurable accomplishments delivered whilst in each contract.

Doing so as a contract developer wasn't particularly difficult in the pre-Agile days of software development when project delivery was less regimented and you could single yourself out as a high achiever/lead developer/architect simply through leading by example and generally acting as a guiding light within the team.

In today's Agile world, it seems to be increasingly common to treat developers as a commodity, with each one in a team being relegated to picking up tickets and passing them through for code review when ready. There's less scope for a team to shape itself organically based upon the individual strengths of the team members and the responsibilities they wish to carry as individuals. Stepping out of the Agile mould to be a "hero" would seem to be frowned upon.

Onto the question then - how do the contract developers here manage to make their CV stand out from the crowd when detailing their contract history in Agile software development roles?

[LondonManc]

Call yourself a "high velocity individual", commonly referred to as "The Kanban Kid".

In all seriousness, you can still sell your major deliverables - whether that be features or epics or a system. It's just a different way of delivering "stuff" to waterfall or JFDI.

[northernladuk]

Surely if that is how you work in your Agile environment then that is what they will be looking for in the next gig so you just list your activities as normal. The process hasn't really changed, just the type of content. The client wants to see if you can work in an Agile environment so demonstrate as you would normally. I very much doubt if that is how it works in an Agile environment they will be looking for something different in your CV. That just doesn't make sense.

That said even though you did work in the way you say you still must be working to deliverables that you can demonstrate. Unless, that is, you had a particularly bad gig and that experience isn't really what a client would normally be looking for?

[AndrewK]

Not sure how that is related to Agile. In any methodology, you build project X using technology Y with Z colleagues.

[LondonManc]

Not sure how that is related to Agile. In any methodology, you build project X using technology Y with Z colleagues.

I think it's because the OP hasn't worked using Agile before. It can be a bit strange if you've JFDI'd your way through large chunk of work or used waterfall to deliver projects.

[SimonMac]

Most hiring processes are waterfall anyway so it doesn't really matter

[Lance]

Isn't agile just a method to run a project that hasn't got any useful/valid requirements?
Or the requirements are almost certainly going to change as the project progresses?

On that basis your flexibility and versatility, to meet changing needs, is what to demonstrate. The project methodology is irrelevant, it's your ability to meet the needs that matters.

[BigDataPro]

You are thinking too much. Big companies call their current ways of working as "Agile" to please senior management. For them if you sprinkling few keywords like Standup, Sprint Planning, Burn down chart, Jira, User story, Acceptance Criteria, Estimation, WIP, BDD is more than enough. Smaller companies who actually do Agile wouldn't focus too much on it unless you are joining as a Scrum Master. All they need to know is that you are aware of Agile practices.

[AndrewK]

I think it's because the OP hasn't worked using Agile before. It can be a bit strange if you've JFDI'd your way through large chunk of work or used waterfall to deliver projects.

Not sure how Agile is related to chunk of work. I can do Agile alone and work on huge waterfall project. As well as opposite.