I find Scrum stand up meetings humiliating

[oscarose]

Not sure how you draw that conclusion. I've only mentioned the extremely bad examples.

Some are better than others but fundamentally I believe SCRUM is flawed. Actually I'd refine that by saying I fundamentally believe that Waterfall is better.

I'd say 'horses for courses' and invest time (lots) in training if you're going Agile.

[SueEllen]

I'd say 'horses for courses' and invest time (lots) in training if you're going Agile.

It's not training that's needed but a mindset shift.

Most managers don't trust their team to do the job of delivering working software, and most product owners don't know what the f*** they want.

[SpontaneousOrder]

It's not training that's needed but a mindset shift.

Most managers don't trust their team to do the job of delivering working software, and most product owners don't know what the f*** they want.

And... training doesn't generally work - anyone who's interested in knowing their stuff can just read a few articles on their own. If it doesn't make sense (because bulltulip id published) then they will persevere until it does makes sense and they can see what is true and what isn't.

When you have to start training (unless it's complimentary to an already positive & proactive attitude), then you know your dev culture is ****ed.

[DigitalUser]

Not sure how you draw that conclusion. I've only mentioned the extremely bad examples.

Some are better than others but fundamentally I believe SCRUM is flawed. Actually I'd refine that by saying I fundamentally believe that Waterfall is better.

There are a lot of charlatans who have commoditised and destroyed the original intent of Agile (or cash-cow, as it probably should be more aptly named in it's current guise), but that doesn't mean that agility (which was the true intent behind the manifesto for Agile software development) is a bad thing. Quite the opposite, in fact.

[rocktronAMP]

Not sure how you draw that conclusion. I've only mentioned the extremely bad examples.

Some are better than others but fundamentally I believe SCRUM is flawed. Actually I'd refine that by saying I fundamentally believe that Waterfall is better.

Dude, you need to expand your horizons beyond your current experiences. There are folk who have found value in Agile thinking and development. You just have not been exposed yet. Waterfall was the methodology I practiced in software houses way back in the 1990's. Would I go back to big up front design again, endless project initiation documents, rounds of design meetings and task based project management? No, not if I could help, for 90% of projects.

I would have rather keep the unit tests, the test driven development, continuous integration, JIRA, release often, release early, the technical stuff. As DeMarco and Lister wrote back in the late 1980's our main battle is on the social side of software development correct. [Peopleware - Google it]

"Individuals and interactions over processes and tools"

We still have a long way to go.

[oscarose]

It's not training that's needed but a mindset shift.

Most managers don't trust their team to do the job of delivering working software, and most product owners don't know what the f*** they want.

How?

And... training doesn't generally work - anyone who's interested in knowing their stuff can just read a few articles on their own. If it doesn't make sense (because bulltulip id published) then they will persevere until it does makes sense and they can see what is true and what isn't.

When you have to start training (unless it's complimentary to an already positive & proactive attitude), then you know your dev culture is ****ed.

Exactly the problem. A few bright sparks read a few bits and bobs and think they can transform their company to 'Agile' at the drop of a hat!

[oliverson]

Dude, you need to expand your horizons beyond your current experiences.o.

Talk about patronising. I think you're pretty well suited to 'agile'.

[d000hg]

They can seem pointless but when you're stuck with X, you are more likely to remember "oh, Y was working on X" - in even a smallish dev team it can be hard to know who knows about some parts of the system.

[oracleslave]

task based project management?

All projects, are fundamentally a list of tasks. Very simply put, who does what by when is all a project is. If you don't know the answer to who is doing what by when for the tasks identified in your project ( at whatever high level you have defined the tasks ) then for me you are not managing.

In other words, irrespective of methodology, when it comes to project management it should still all boil down to this fundamental principle and therefore task based management is not something that can be avoided. To do so as a PM means you are not managing.

[rocktronAMP]

All projects, are fundamentally a list of tasks. Very simply put, who does what by when is all a project is. If you don't know the answer to who is doing what by when for the tasks identified in your project ( at whatever high level you have defined the tasks ) then for me you are not managing.


In other words, irrespective of methodology, when it comes to project management it should still all boil down to this fundamental principle and therefore task based management is not something that can be avoided. To do so as a PM means you are not managing.

There is always a list of stories (and they are broken into tasks) - probably I am preaching to the converted already
Sorry for my obtuseness. I meant to say, that projects where you are told what task you should be doing.

And some project managers do become excellent Agile SCRUM masters and therefore "manage" a self-organising team very well. They take the load off the designers, developers, testers and business analysts with *managing-up* and managing across to the stakeholders / customer. They manage down well to ensure that the sprint is not interrupted by sudden and imprecise change requests.


In SCRUM, the team (or individuals) "push" tasks across the board: PENDING -> IN-PROGRESS -> TESTING -> DONE

As a developer IN-PROGRESS when I finish the developing the issue, I tell the tester to start testing, after the moving the sticky note to the TESTING bucket

In the Lean philosophy, (KANBAN) the team (or individual) "pull" tasks across the board: PENDING >- IN-PROGRESS >- TESTING >- DONE

In this mode, the tester who is twiddling her thumbs after completing a test comes to me, and asks "Rock, are you going to be finished with story 12345 anytime soon, is it ready for test?" She looking for more work to do in the project - lean supposedly encourages more proactivity, stop the assembly line if the process in broken. If I finish the story 12345 soon, the tester might have gone out for a tea break, I still push the sticky note over to TESTING for her to pick up.

A couple of years ago, I contracted in an environment where they used both: SCRUMBAN.