Any software developers out there who can help ...

[Gwylan]

..this isn't a BG plea for technical assistance. This is a bit off-beat for NSC but I know there are a few software bods out there so someone may be able to help. Trying to source someone is certainly taking my mind off Derby

I'm writing an article about software teams who have looked to move to an Agile/DevOps environment but found it wasn't for them. Is there anybody out there who's been in this boat who can talk about it? (preferably using your name but I could accept an anonymous contributor). The article is for The Register BTW

 

[essbee]

Hi Gwylan -

That's an interesting issue - I only know people who would praise agile or refinements of it -
But I'd be interested in seeing the end article.

 

[Springal]

Someone who writes for the register

 

[Mayonaise]

Interesting!

I can talk to you about successfully making that transition and would never want to go back but I guess that is not what you are after for this.

 

[JCL666]

The only time I've found transitioning to an Agile set up to be a negative, and possibly fail, is when there isn't sufficient buy in from senior management types, or that stakeholders active in the process try to circumnavigate the Agile "rules".

 

[8ace]

or that stakeholders active in the process try to circumnavigate the Agile "rules".

Yep, people who are late for the daily meeting, people who sit down for it and people who talk too long.

 

[Postman Pat]

The only time I've found transitioning to an Agile set up to be a negative, and possibly fail, is when there isn't sufficient buy in from senior management types, or that stakeholders active in the process try to circumnavigate the Agile "rules".

Absolutely this, trying to run an Agile project with Prince 2 project management is a nightmare.

Since the transition to Scrum we haven't looked back. As a product owner I love the freedom myself and the development team now have to work on the stuff we see as most important.

 

[Gwylan]

Hi Gwylan -

That's an interesting issue - I only know people who would praise agile or refinements of it -
But I'd be interested in seeing the end article.

Interesting!

I can talk to you about successfully making that transition and would never want to go back but I guess that is not what you are after for this.

Yes, that's what I've found talking to regular contacts

Absolutely this, trying to run an Agile project with Prince 2 project management is a nightmare.

Since the transition to Scrum we haven't looked back. As a product owner I love the freedom myself and the development team now have to work on the stuff we see as most important.

That sounds interesting. Can you spare 15 minutes this week to talk about it?

 

[FatSuperman]

Does anyone use agile methods with large third party, offshore, outsourced services?

 

[Tricky Dicky]

I did Agile at 3 different places, and if it's done properly it really can be very good. If it is done half-heartedly, and not everyone buys into it, it's pretty much a waste of time.

Personally I loved it, but it took quite a while to get to that good place. We start with a team where people had their own specialities and ended up where anybody could work on anything.

 

[Brovion]

Does anyone use agile methods with large third party, offshore, outsourced services?

Yes. We've got an outsourced organisation (in Russia) but our company also has a presence in Poland so we have a Polish dev team as well. As you can imagine there are 'challenges' to this but all in all the system works.

I accept the drawbacks that people have outlined (especially that very senior management have to buy into it), but like others I'd never go back, and if ever found myself in a large organisation that didn't use some form of Agile I'd consider myself to be in the dark ages. At our place the senior management and product owners all accept that if they want something done in a panic then something else has to come out of the sprint to make way. It's actually given them a sense of discipline.

It does take effort though, sprints don't run themselves and things like backlog grooming and story pointing are really important. However once a team knows their velocity and the sprints aren't too short (we do fortnightly so we aren't in an endless round of restrospectives and planning meetings) the system works like a dream.

Oh, and make sure the chickens attend stand-up!

 

[Tricky Dicky]

Yes. We've got an outsourced organisation (in Russia) but our company also has a presence in Poland so we have a Polish dev team as well. As you can imagine there are 'challenges' to this but all in all the system works.

I accept the drawbacks that people have outlined (especially that very senior management have to buy into it), but like others I'd never go back, and if ever found myself in a large organisation that didn't use some form of Agile I'd consider myself to be in the dark ages. At our place the senior management and product owners all accept that if they want something done in a panic then something else has to come out of the sprint to make way. It's actually given them a sense of discipline.

It does take effort though, sprints don't run themselves and things like backlog grooming and story pointing are really important. However once a team knows their velocity and the sprints aren't too short (we do fortnightly so we aren't in an endless round of restrospectives and planning meetings) the system works like a dream.

Oh, and make sure the chickens attend stand-up!

I'd agree with that. 2 week sprints seemed about right to me, but the admin overhead can be tedious to some, but very important. Everyone has to attend scrums - and you must stand up !

We used those Agile playing cards you can buy for a while, to estimate task size, but that didn't work too well.

 

[Shropshire Seagull]

I was a developer back in the very early days - pre and transition into windows and worked on a project under DSDM principles [the forerunner to Agile]. I've since been involved in analysis / design and test in software engineering but for the last 15 years, project and programme management. During the last 25 years I've worked using both Waterfall and Agile. The MOST IMPORTANT thing to consider is what the deliverable is. Some things can be Agile delivered, but not everything. There are occasions where a degree of waterfall approach is required, usually to address risks and also cost control. There is never a one-size-fits-all approach, it's always horses-for-courses. The real skill is knowing which to adopt and in which phase of a project.

Interesting subject [for me at least]

Under DSDM is was called Rapid Application Development and the theory was all around iterative and time-boxed development. Fine if the solution can be worked out as you go along but there were aspects that were critical to the foundation that needed to be designed very early in the project but the "requirement" was not forthcoming and made trying to keep the principle of nothing gets thrown away very difficult to keep to. Time boxing is a great concept, but sometimes we found the time box needed to be extended as the module was in no fit state to be progressed. Superb learning opportunity.

Hope this helps ....

 

[Brovion]

I'd agree with that. 2 week sprints seemed about right to me, but the admin overhead can be tedious to some, but very important. Everyone has to attend scrums - and you must stand up !

We used those Agile playing cards you can buy for a while, to estimate task size, but that didn't work too well.

Really? we've found the 'cards' system (we've all got the app on our phones) works brilliantly. Obviously the testers are part of the team and what might be a quick one-point dev fix they'll often mark as a three as they've got to test it on all the supported browsers and devices. You're right about the effort though . The problem we had at first was the organisation and the fact that the tickets were rubbish, we'd get stuff like: "As the product owner I want the home page to look different"

Gradually though the product owners and business analysts (BAs) learnt the difference between things like epics, stories, technical tasks and bugs. They can split the work down, they give adequate descriptions and acceptance criteria, and it's very rare now that we have to reject a story as having insufficient information. The POs and BAs will also prioritise the backlog, we know our velocity (in points) so in sprint planning we'll storypoint the most important tickets until we're close to velocity and say that's the sprint. Then we'll add a few more as stretch tasks (still left in the backlog). Takes us about an hour, tops, once a fortnight. We've also got a full-time scrum-master who doesn't do anything else except manage the sprints for the different teams. That's made a difference.

I too would be interested in Gwylan's article, I wonder why people have gone backwards? It might be lack of resources, as I've inferred at our place as devs we have nothing whatsoever to do with the admin and you don't get things like a senior dev doubling up as scrummaster.

 

[FKalinx]

Hi Gwylan,

My boss who is a great software architect (serial entrepreneur; he built one of the world's first systematic hedge funds in 1983 that continues to prosper) has written an anti-agile article here: http://digitalanimal.com/blog/slaying-the-agile-dragon-the-game-of-thrones-methodology/?AT=Pz0d87. He feels strongly about the topic and may be interested in being interviewed. If you PM me more details, I can ask him.

F

 

[Westdene Seagull]

Someone who writes for the register

I once leaked something to The Register because my then employer, Capita, were lying through their teeth to the press.

 

[Tom Hark Preston Park]

Really? we've found the 'cards' system (we've all got the app on our phones) works brilliantly. Obviously the testers are part of the team and what might be a quick one-point dev fix they'll often mark as a three as they've got to test it on all the supported browsers and devices. You're right about the effort though . The problem we had at first was the organisation and the fact that the tickets were rubbish, we'd get stuff like: "As the product owner I want the home page to look different"

Gradually though the product owners and business analysts (BAs) learnt the difference between things like epics, stories, technical tasks and bugs. They can split the work down, they give adequate descriptions and acceptance criteria, and it's very rare now that we have to reject a story as having insufficient information. The POs and BAs will also prioritise the backlog, we know our velocity (in points) so in sprint planning we'll storypoint the most important tickets until we're close to velocity and say that's the sprint. Then we'll add a few more as stretch tasks (still left in the backlog). Takes us about an hour, tops, once a fortnight. We've also got a full-time scrum-master who doesn't do anything else except manage the sprints for the different teams. That's made a difference.

I too would be interested in Gwylan's article, I wonder why people have gone backwards? It might be lack of resources, as I've inferred at our place as devs we have nothing whatsoever to do with the admin and you don't get things like a senior dev doubling up as scrummaster.

In my experience Agile doesn't work in big blue chips. For sure you can develop a fairly basic wizzy new front end, but the minute you try and make it speak to clunky old backend mainframe systems, the venerable and cynical old lags with zero in the way of social skills or dress sense who maintain those ancient systems want nothing to do with the cards and the cuddly toys and the cowboy code and will, probably.correctly, not play ball and end up sabotaging the endeavour.

 

[FamilyGuy]

The only time I've found transitioning to an Agile set up to be a negative, and possibly fail, is when there isn't sufficient buy in from senior management types, or that stakeholders active in the process try to circumnavigate the Agile "rules".

Absolutely this!

 

[Gwylan]

I've had some great responses but I need to have some longer conversations about this. Like I said, these could be anonymous (although I'd prefer them not to be). But if they are, I would still need your name (I need to know even if you're not in the article) and position and type of company (eg team leader with a British finance company).

Anyone willing to talk, please PM me. It's not painful, I'd need about 15/20 minutes on the phone

 

[FamilyGuy]

I was a developer back in the very early days - pre and transition into windows and worked on a project under DSDM principles [the forerunner to Agile]. I've since been involved in analysis / design and test in software engineering but for the last 15 years, project and programme management. During the last 25 years I've worked using both Waterfall and Agile. The MOST IMPORTANT thing to consider is what the deliverable is. Some things can be Agile delivered, but not everything. There are occasions where a degree of waterfall approach is required, usually to address risks and also cost control. There is never a one-size-fits-all approach, it's always horses-for-courses. The real skill is knowing which to adopt and in which phase of a project.

Interesting subject [for me at least]

Under DSDM is was called Rapid Application Development and the theory was all around iterative and time-boxed development. Fine if the solution can be worked out as you go along but there were aspects that were critical to the foundation that needed to be designed very early in the project but the "requirement" was not forthcoming and made trying to keep the principle of nothing gets thrown away very difficult to keep to. Time boxing is a great concept, but sometimes we found the time box needed to be extended as the module was in no fit state to be progressed. Superb learning opportunity.

Hope this helps ....

Have you revisited DSDM recently? Like any good setup of tools it has evolved with experience.
Have a look at DSDM.org and also at AgilePM from APMG, which was developed by DSDM.