The joys of Agile/Scrum

[D.P.]

DP, Agile isn't a process at all, formal or otherwise. I have a name, and I'm not a process.

Agile is a collection of methodologies and ideologies for managing the software development process - it is a process by definition. Creating software is process. Management is a process.
Hence why everywhere talks about he "Agile Process", e.g. http://www.agile-process.org/
Agile is a modern reincarnation of the 1950s "Iterative and incremental development process" http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=1204375 that was redisocvered as the "Unifoied PRocess" in the early 90s.


The fact that there is an Agile Manifesto and that you can buy books on the subject or study it it on courses makes it formal. Doesn't matter that it is adaptive and flexible, it is still a formal process of software development. The process of writing a formal manifesto outlining the principles has formalized the process.

Randomly banging your head off the keyboard is a process (I call it the "process of stochastic cerebral software development").

 

[Wink]

Sounds like your projects aren't large enough to warrant it right now, but if you want to follow an agile type approach in the future with more complex projects take a look at DSDM.

I think your biggest issue is resource constraints and stakeholder management right now though!

A lot of people seem to have the view that agile means unstructured, that is NOT true.

 

[davetherave2]

The important thing I got from the videos and other material is that keeping everyone involved from product owner/stakeholder down to developer is part of the battle.

Yes the majority of our prpjects are very short time scale/ relatively simple so can be completed in a couple of days but I don't see why some of the principles couldn't be applied. Such as the retrosepective, daily scrum meetings, etc. The more I think about it some of our website builds are using a very loose scrum approach.

With a fundemental change to key business software within the business, scrum will be able help us manage delivery of it better.

Although not really my role (should be the dev manager) I want to try and rebuild the confidence within the business of the dev team as we have had a rough time of it over the past year or two. This is down to a number of factors that I will not bore you with, if they can see change happening for the better in the team and how it interacts with the business I see it as a win win for us if the changes are positive.

 

[Haircut]

You really do need everyone to be on board to do things properly.
I've worked on projects that were properly agile and on others that were 'agile' (making quotation marks in the air with my fingers as I say that!)

The first sort can work really well, the second sort never do.
I remember on one project where we developed in iterations, had morning stand-ups and retrospectives at the end of each iteration, yet we were forbidden from having any contact with the end users because someone somewhere thought that it wouldn't work.

You can be ticking pretty much all the boxes, but what it all really boils down to is being able to deliver the stuff that the client needs as quickly and efficiently as possible.
If you can work things so that that's possible then great, but if not all the stand-ups in the world won't help.

 

[davetherave2]

The development team is completely on board with moving to an agile/scrum development cycle.

I understand that there may be some projects which may not be completely suitable for this but if we can structure our bigger projects in this way then I see it as a positive move for us as a team and hopefully we can be more pro-active rather than the constant firefighting we currently do.

The more I am learning about this process the more I think "if only we had done it that way for this project it would have been delivered in half the time".

I think the main issue we have at the moment is that we as a development team are being given vague requirements and expected to come up with the solution and all the features and a lot of the time guess what the end product should be. (We develop a lot of internal applications rather than external) So if we can get a better picture of what our clients (internal and external) require then that is part of the battle.

I would rather we embrace this together both as a development team and the stakeholders of our projects to show them how much better we can work in partnership rather than some of the current running battles we have.

Once again thanks to everyone that has contributed I have a lot to think about.