[Closed] Softwaredeveloperists - do you use "scrum" methodology?

Yep. Use it at a university in house development

Know lots of other software devs who use it for all development

Yes. Take a look at kanban or scrumban too.

Yes we use it a lot and so have my other companies. Like any methodology it helps to understand how it fits into the big picture and whether it relates to your project. I've found it most useful working on projects where continuous improvement is the goal rather than one big bastard release at a time. That said I know people who are perfectly happy with the latter so YMMV.

Yes - but almost never exactly scrum. It’s an Agile methodology and absolutely should be adjusted to meet the needs of your team and the project in hand. Be agile with Agile…

Rachel

Yeah, I've used it to varying degrees on different projects.

[b]*IF*[/b] it is done right then it is a good system.

Sadly loads of people make a half-arsed job of it and then blame the methodology.

So I am a fan of Scrum / Kanban and have seen it used properly, however I see a lot more of it used as a smoke-screen to say they're Agile.

e.g. You know the team is not agile when the first thing they ask is where are the requirements?

The Agile Manifesto (I do love a good philosophical Manifesto 😀 this isn't quite the level of the [url= https://en.wikipedia.org/wiki/Blast_%28magazine%29 ]Vorticists[/url])
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

...where are the requirements?...

I'd love our place to adopt to the Agile method, but the way projects get funded here means that it's 'difficult' to implement.

I can see it getting implemented for small incremental changes but projects seem like a big leap from where we are at the moment.

Yes the trouble is that Agile; i.e. self empowered teams means ripping up a lot of the organisation's hierarchy.
For example - how can you have individual performance rewards (that set team members against each other) when it's all about a team's performance?

The focus on real delivery over documents means all those self-serving tin-pot administrative politicians lose their power base.

The high profile successful implementers (AFAIK) have been in a real backs against the wall situation.

spent 18 months on a project the used agile and even became a certified scrum master. when it works its pretty good but but its has it limitations, I remain a fan.

At my new place all the senior management are harping on about agile and its a bit like the emperors new clothes...none one of them dare stop and admit the are not really sure what it is!!

e.g. You know the team is not agile when the first thing they ask is where are the requirements?

Well what's your starting point then?

It sounds like project management without any management.

You know the team is not agile when the first thing they ask is where are the requirements

Agile doesn't mean no requirements. You need to know what you are going to commit to build in your sprints otherwise you spend too much time churning and not enough time building.

That's my experience Mackem.

It sounds like project management without any management.

Project management has it's place, but they don't run the team or set goals for sprints. Think of them as a interested stakeholder.

Done properly, it works well.

It's almost never (IME) done properly.

"We're Agile", often means "we're winging it"

Also my experience. In fact, I've never, in 4 years of working with Agile methodology, heard anyone but a PM say " this Agile stuff is bloody great". Quite the opposite.

Mmm, as a non tech person I've gone into a tech firm who use agile, and broadly it works well, and is liked by the devs. No PMs though, they don't like it.

In fact, I've never, in 4 years of working with Agile methodology, heard anyone but a PM say " this Agile stuff is bloody great".

Then I reckon you've not seen it done correctly.

Done properly the developers should like it, as it gives them ownership of clearly defined sub-tasks with well defined end points and something to show for it, plus it stops them getting shafted by scope creep.

I've encountered, as a developer, various versions of Agile and Scrum in projects since 2006 for a variety of clients. Sometimes it works incredibly well, other times it doesn't. I've never thought that was a fault of the methodology.

Is it a prototyping approach? (Except the "prototype" should be fully featured) ie improve, give to user, get feedback, improve, give to user etc etc

Despite my discussion earlier in the week / month on another topic, I'm all for Agile (XP - got the buckyball t-shirt, scrum) methodology - but as GrahamS says (we agree pretty much!) it needs to be done properly with everyone taking their role/responsibility seriously..

Definitely used to be in the one big bast@rd release environment and didn't like it (who does - many a weekend ruined by that...) Even little bits like continuous release, specification is what the client says, automated testing is a clear improvement.

FWIW I'm now in a small, loose team of freelancers and it has helped - have tried to at least get some of the repeatable tests, code coverage, aspects included.

So, yes, many aspects to it - was there 12 principles according to Beck / Cunningham ? - but at least some will be helpful in whatever you apply it to..

ime what works is making sure you get designers who can design and coders who can code (and even managers who can manage), irrespective of the method as they will have the ability to make the method 'good'.....

Is it a prototyping approach?

Not really, but sort of.

One of the aims is to avoid a development team hiding away for 12 months, working away towards one monolithic release, which the client inevitably hates.

So at the end of each "sprint" (typically 2-3 weeks) you have "something" which you release and ideally demonstrate.

Incremental and prioritised steps towards and end product.
The client has visibility of this throughout development, so they don't get any nasty surprises. And they also have visibility of how any requirement changes and feature creep they request will impact on the schedule or feature set.

didn't mind it when we used it, but I don't think it's quite the panacea the devotees would have you believe. One of the things I didn't like was sprint backlog, the idealistic anyone can pick up a task never happens in reality, for various reasons, some task require very specialized knowledge, the competitive ****s are usually loudest and try and muscle in on the "plum tasks" leaving the less vocal guys to pick up the dull boring tasks (sprint after sprint) and become resentful. I was in the specialist camp so my tasks would be no different no matter what process was used 🙄

I ran an operational support team in an 'agile' environment and we were expected to adopt Scrum for project work to fit in with the Dev team. After a few months of painful learning the team adopted Kanban instead and didn't look back; done properly it works very well.

I remember hearing lack-of-requirements being espoused by some manager, it didn't take long for the scrum teams in his remit to stick something like this up on the wall;

[img] &f=1[/img]

What line of work do you want to use it for? I'm in a business that heavily uses it, but not in a software dev role myself. We've adapted it to develop processes for the marketing department. Also use it for my team, in the marketing department. I like it, and it certainly works in our business, though can't see it working in some places I've been in the past.

We develop software in-house and are in theory agile but we are driven by our commercial teams which always makes being truly agile difficult.

The main issue I have with agile in our enviroment, after 4 years of trying to get our developers, testers and product teams to be more agile is that we have to deliver to a strict schedule which basically means we are nearer a waterfall process.

if you can start with a clean slate or have the full support of your SMT it can be made to work and work really well! Good luck.

One place I worked at the whole company signed up to Agile and SCRUM and it kind of worked.

Other places it's little more than a box ticking exercise so they can say they do Agile but then it goes out the window when sales have sold something that doesn't exist and promised it by the end of the week and you haven't planned for it.

SCRUM is an effort to implement a process in the world of Agile which is really about the opposite of formal processes that get in the way of delivering.

Forget SCRUM, just be Agile. The things I like about Agile are in getting everyone to agree on the next delivery content, and being able to deliver a buildable and workable product at almost any time (doesn't have to be complete). Screw stand up meetings, story boards, spending half the week in planning meetings for the next Sprint and all that balls.

Just do the backlogs, quick agreement on tasks that will be in the next build, do the builds on regular intervals, do bucket loads of unit testing and use continuous integration with tests run on each build.

I think I'll pull up a chair. I'm sure this thread could develop nicely into Bullshit Bingo.

we have to deliver to a strict schedule which basically means we are nearer a waterfall process.

You can hit deadlines with agile/scrum approaches.

If anything they should be slightly better at hitting hard deadlines because you know your burndown rate, and you know the size of the stories/features in your backlog, so you get a nice prediction of what features you can complete for the deadline.

The agile trick is that if the deadline is immovable and you can see you won't hit it then you sit with the product owner go through the backlog and decide which features to drop - rather than the waterfall approach of frantically shouting "word harder you bastards" then delivering a half baked product with no complete features.

DrJ, I'd recommend reading Scrum from the trenchs and The Phoenix project for more information as well as plenty on Mountain Goats website.

Personally a daily standup is great in any team, but keep it to 10 minutes and just the usefult facts.

Retrospectives are just about learning what is working and what isn't so a feedback loop on your process.

There are good and bad features to most things, but Agile and scrum are the most sensible approaches I've come across for development so far.

+1 for everything Graham S is saying here.

I also agree with many other points including Towzer's that if you have good people involved, who know what they are doing, they can turn most methods to success (...this in my experience is sometimes through knowing when to bend or break 'the rules' of the methodology...)

Within the 'people' you also have to include stakeholders. If you've got difficult stakeholders who don't understand the nature of software development, don't understand evolution and how to use that to the advantage of refining design and also actually making progress, then you've a recipe for a painful disaster.

The key to agile methods isn't that the method of moving postits or in TFS or whatever, is somehow magic - it's understanding what's [i]behind[/i] those methods and then tuning your approach, given your deeper understanding.

Agile methods are definitely NOT an excuse for lack of planning and lack of design work, it just changes how and when you go about that deign and planning, and what you are aiming to achieve.
For example on an agile project the designs I create (as a software architect) will often be as much about mitigating risk of direction changes in stages anicipated to be coming later, as they will be about creating the 'best' design technically.

I could go on and on and on about this for ages. Can you tell I am a fan?

Agile methods speak to me very deeply about the nature of things, not just software development but also life generally.
As a species we just don't have the mental capacity nor the clairvoyant skills to predict how things will go on a big task and very far out in advance.
This is why BDUF (big design up front) projects often fail. It is also why it's really hard to spec out a big building job (e.g. a house extension to a very fine level of detail (this is why builders moan about spec changes late in construction jobs). People shouldn't beat themselves up. This is all natural and should be expected! Agile gives you the tools to deal with it.

But the conditions have to be right and it's best to understand what is behind the methods.

PPS it's also worth looking at how agile methods (continuous delivery) help to reduce project risk profiles, also how techniques like code reviews, discussing the design, shared responsibility for coding and testing, test frameworks and unit testing help to reduce future risk of knowledge leakage about the solution to protect the health of the solution longer term.

Sorry I will shut up now!

Have a read up on some of the other methods
https://en.wikipedia.org/wiki/Software_development_process#Approaches

All things work when applied and done well, however.....
If people are more concerned with the methods than job it's going to go wrong. It's a tool not a religion!

Not so much scrum in particular, but so-called "agile" approaches - emphatically yes!

Fundamentally, it is very rare in my experience that people buying custom software have a very clear idea of what they want. So using approaches that result in an increasing cost of change as the project progresses generally result in poor outcomes. Agile approaches focus on ever-shorter feedback loops with a view to keeping the cost of change flat as the product evolves. I imagine that many of these techniques are not only generally applicable, but have been used in other industries for years.

The principles in the agile manifesto might be a good place to start. Or I met the author of a book called "being agile in business" last year. Can't vouch for it specifically, but she was definitely applying the techniques in other sectors, so could be a useful insight.

When it works, it feels marvellous for everyone in the team.

Does anyone have any experience of trying to work in an agile fashion as a one man band? Does it even make sense in that situation?

You can absolutely apply the concept of agile to a one-man band.

Obviously you won't be doing stand ups and having discussions with yourself but you can absolutely set yourself sprints with small but achievable goals with the idea of delivering at the end of your sprint, all of the concepts about small developments and small deliveries still apply.

Something like [url= http://trello.com ]Trello [/url]is great for agile one man bands.

I try it from time to time as a freelance if I'm the only person working on the project, but the stakeholder thing still needs to apply really. Need to have absolute agreement on exactly what is being delivered in the "sprint" or whatever silly name you want to give the build cycle.

It's no use if you're busy working on the current one and the goal posts change.

To a developer this is the biggest benefit of Agile. If done right people absolutely cannot change the goalposts before the next build release. If they want something extra then they have to wait for the next one and accept that's the way it is.

It's also the hardest thing to achieve in my experience. Almost always someone will be jumping up and down demanding something tomorrow because they've promised it to someone and supposedly some big deal is riding on it. They don't mind if it's only a prototype/beta/alpha quality and no integration testing, but in reality it must be production delivery and needs to be complete and reliable, and any bugs or missing features will equal shit hitting fan. 😉

They don't mind if it's only a prototype/beta/alpha quality and no integration testing, but in reality it must be production delivery and needs to be complete and reliable, and any bugs or missing features will equal shit hitting fan.

This is a real tricky bugger to deal with. We have a load of problems borne of a legacy of this where I currently work. I.e. devs in the past being too helpful (even, being bullied) in order to hit dates.

Stakeholders then subsequently conveniently forget that their past behavior - i.e. lack of proper [/i]investment[i] in making systems robust, and mounting technical debt, is actually the the cause of their current woe.
Oh yes and of course it's all Dev's (or ops or whoever other convenient teh team's) fault for their unwise investments.

We have had some success recently though, by assigning a product owner role from amongst stakeholders. Product owner is responsible for product viability and making investment choices. It's tech's respnsibility to make owners aware of the risks and problems in the estate, owner's choice whether to invest in remediation or not. Therefore your product, I'll tell you what your problems are, your investment choices to balance risk remediation with new features.

Just bedding in, but in some areas working well already

It's no use if you're busy working on the current one and the goal posts change.

That goes back to the idea of letting the client (Product Owner) see the impact of their request.

If they absolutely need something then you can say "Okay, we can do that. What shall we drop from the sprint to make room for it?". Or even, "Okay that sounds really important, shall we abandon our current sprint and start a new one with this as the goal?"

Sprints should only be a couple of weeks long so any tasks in a sprint should be fairly small.