Strange experiences with SCRUM

80 posts in this topic

Interesting read.  Scrum is a process not a religion.  If part of it doesn't fit into a particular project get rid of it as opposed to jamming it in somehow in order to feel good about yourself.

2

Share this post


Link to post
Share on other sites

Just shows one should read the whole thread.

I saw this and thought " Groan- not more rugby"!

1

Share this post


Link to post
Share on other sites
On ‎09‎.‎08‎.‎2013‎ ‎14‎:‎01‎:‎54, Metall said:

I HATE our so-called Scrum Masters/Agile Trainers*.

Below my experience with these people - please let me know if your company uses SCRUM, and how your experience was.

 

 

While I've never done a scrum project, I'm currently in my first job using Kanban. Personally, I love it. Everything is very transparent, you don't get overtasked (each person is only allowed a max of two tasks at any one time), and you can't "hide" anything.

 

Just out of curiosity @Metall, are you still using scrum? Still hate it?

0

Share this post


Link to post
Share on other sites

It's been over 3 years since I last did a scrum project (CEO demanded we use the methodology) - by the time we got done with all the meetings / tracking for all the sprints, it cratered the company so I'm not a big fan.  I've not used Kanban but after the prerequisite 15 second Google search, it kind of looks like a Trello board with a little workflow thrown around it ... am I missing something major?

1

Share this post


Link to post
Share on other sites
14 minutes ago, chooyo said:

I've not used Kanban but after the prerequisite 15 second Google search, it kind of looks like a Trello board with a little workflow thrown around it ... am I missing something major?

 

I don't know. I only know how it is used here and I don't know what a Trello board is... :D

 

You are confronted with, and have to give updates on, your (up to) 2 topics every day. Total of 10 or 15 minutes for the team. That means you are pretty well informed concerning every topic active at the moment. That's the part I like about it. There's also stuff like a "retrospective" meeting at the end of a "sprint" phase, in which things are openly discussed concerning what went right and what didn't and what we can do better in the future.  I've only been working here for a couple of months, so I don't know the ins and outs myself yet.

 

From what I've gathered, they mixed Kanban with Scrum to get a kind of hybrid.

0

Share this post


Link to post
Share on other sites

Sounds like it's a leaner Agile implementation while retaining the end reporting that's so important ... it'll be interesting to hear how it all works out in terms of deliverables and managing customer expectations.

1

Share this post


Link to post
Share on other sites

My boss is a fad guy and is head over heels for SCRUM right now.  I've been looking at it as well as Kanban and the difference is that Kanban is continuous, each person doing 1-2 tasks until done and then get new ones from the backlog while SCRUM they already picked x tasks from a list that they want to do in a sprint of x weeks and new tasks will have to wait for the next sprint.

 

Sure you can mix them all and make them work for you.  Personally I think it might help with organizing when done right and you are making sure noone falls behind and that noone is unable to work because they are waiting for someone else but for me and my boss, I don't actually think we need it.  There's only the two of us and we work on different projects.  At the most, we could possibly use it if we are ever asked to manage a project.  My boss might be, myself, probably not :) 

1

Share this post


Link to post
Share on other sites

The problem I have with Scrum (and similar technologies) is that it isn't suitable for long-term development. It may work great if you need to churn out something relatively simple in a few months, but I work on a "shrinkwrap" enterprise product that's more than 15 years old. Scrum done corporately doesn't allow for non-productive time, and you have to really squeeze it to be able to resolve larger technical debt issues, especially if the effort exceeds a "sprint". It is also too meeting-heavy for small (like our 3-dev) teams.

 

The Agile Manifesto, however, technically says some valid things, prioritizing one thing over another, but -- and this is critical -- it only prioritizes. when it states "Working software over complete documentation", that does not mean there isn't to be any documentation... or that incomplete documentation is fine, or even an aim. It just says that if you have to choose between the two, you should choose the former.

 

Of course, it gets fubared when the corporates get a hold of it...

3

Share this post


Link to post
Share on other sites
On 9.8.2013, 18:35:57, kludgie said:

Anywhere I've worked that says they "do scrum" doesn't.

 

It's something "cool" they put on the job ad, like having an on-site barista and free pilates classes.

 

Apparently scrum entails having a "stand up" meeting the odd morning at 10.30 when most of my fellow developers have managed to drag their arses into the office.

 

Not forgetting the occasional sprint planning meeting which usually lasts an afternoon and sets a number of spurious actions which will remain partially tracked until the next sprint plan when they will be extended.

 

We also have this thing called a "kanban board" which appears to be used as a proving ground for how long a post-it note can remain stuck to a wall before it falls off.

 

As for "scrum masters", one I worked with even had a certificate stating he had successfully sat in a room for a couple of days while someone prattled on about "User Stories" and "Blockers".

 

Needless to say, he knew jack shit technically and we could lead him a merry dance whenever required, methodology expert or not...

 

Goddamn, this is good. 

0

Share this post


Link to post
Share on other sites

Pure SCRUM rarely works.

So you need to adapt it to your needs. I've had excellent success in bringing the concept to my company, but I had to loose the dogmas and adapt it.

In my case, these are the differences:

- using hours for estimates instead of story points. We spend a lot of time estimating.

- 4 Product Owners instead of one.

- team with specialists

- decoupling of sprints and releases

- I am still the project manager (does not exist on scrum), plus product owner. I am now in the process of delegating the position of Scrum Master to someone else.

- velocity is calculated in hours per person per day. Capacity is calculated in hours per person per sprint.

- a sprint matches exactly one calendar month

- we allow significant scope change during sprint. This is handled with a buffer.

 

My team size is 8 and growing to 11 or more.

 

Pure SCRUM can work with simple software projects, like web development (yes, they are generally simple) but completely fail in complex projects.

 

@Gwaptiva, I disagree, SCRUM can work for long term development, but not in a pure form. Technical debt issues can be decomposed to simpler tasks and planned for a sprint. I agree that it does not work well for teams <=3.

 

1

Share this post


Link to post
Share on other sites

yes this is my experience too (in response to @Gwaptivas comment)

 

it's also damned difficult to work architecture, design or sense into a project built exclusively in sprints...it can be knitted together with some side work done by those who are (hopefully) not on the hook for "user-story" driven tasks.  But if the scrum implementation is fanatical, it's nigh impossible as the short-term focus does not support this level of cohesion or planning outside of fairly boiler plate scenarios. 

 

Large projects tend to hit a sort of intractable point of...gridlock? once they reach a certain stage of development, but this is especially true, and it happens much faster, when they are essentially hacked together "as needed", which scrum encourages to varying degrees.

 

 

1

Share this post


Link to post
Share on other sites

@MikeMelga Good call on the points to hours. We used the SP thing (forced by JIRA) for a bit, but both of us (3rd dev only arrived in December) used 1 SP = 4 hours, so we formalised that :)

 

But, I'm currently developing an entirely new module, and apart from looking at the business reqs, I've done no formal planning for it. Considering that we still suffer from the "It has to be done by date x, and it has to have all these features, and you cannot have more resources" syndrome, it doesn't matter, other than that it saves me oodles of time typing JIRA tickets :)

 

We're slowly progressing to Anarchy :)

2

Share this post


Link to post
Share on other sites

my 2 cents for this topic :

 

I use scrum, and I hate scrum!

 

And besides i hate all those so called "scrum experts" : Very strict people that have a very strict idea how  scrum should work.and THEIR way is always the best!!! ( funny to see them fighting with each other....hahahaha) 

 

In my case there are more than one project manager in our team, and our team interact

with teams from different companies, which have their own project managers.

 

I work with JIRA (i think its a standard in big companies) ,

in my case 1 SP = 4 hours. and in my last project there was NO buffer. (everybody was exploding of joy...NOT).

 

I switch recently from a very strict scrum project where people behave like drones to a very flexible scrum project. 

its interesting to notice where people are normal (not autistic drones) how successful this project in the global picture is,

even with far less SP made, and FAR less stress.  

 

this because ín my experience some scrum items are just stupid.

simple example: some items, if  people COMMUNICATE they would realized that those items

could be fused into one, and save a lot of time. 

 

...but noooooo, some informatic drones want to do everything like robots,

without noticing that they hitting hard the Turbo pedal...--but the car has NO wheels. 

 

my personal "like" goes to the V-modell. 

0

Share this post


Link to post
Share on other sites

I work on a long-term large SCRUM project and it works fine.  I think the key is to keep things flexible.  If you need time to investigate something, then you write a story to spend some time investigating something, estimate it, and plan it into the sprint. Same for architecture.   If something will take longer then expected, then you re-estimate it.  One adaptation that we have had to make is to break into expert teams that are responsible for different parts of the overall application.  The project is simply too big and complex to have people having to gain new expertise because they are working on something entirely new to them each sprint.  

0

Share this post


Link to post
Share on other sites
2 hours ago, Gwaptiva said:

@MikeMelga Good call on the points to hours. We used the SP thing (forced by JIRA) for a bit, but both of us (3rd dev only arrived in December) used 1 SP = 4 hours, so we formalised that :)

You can use hours in Jira, in fact, that's what I'm doing. Jira does NOT force you to use SP.

 

Story points are only useful in some situations, when developers are not specialized and when the average task is small. Unfortunately the SCRUM evangelic demand that we use them.

 

Quote

 

But, I'm currently developing an entirely new module, and apart from looking at the business reqs, I've done no formal planning for it. Considering that we still suffer from the "It has to be done by date x, and it has to have all these features, and you cannot have more resources" syndrome, it doesn't matter, other than that it saves me oodles of time typing JIRA tickets :)

 

We're slowly progressing to Anarchy :)

You are suffering from the classical engineering problem. There are many solutions to solve it, but basically you have to be a project manager and not a scrum master to solve it.

The first thing that SCRUM brings is transparency. You allocate your tasks to your sprint and you can see that the deadline cannot be met.

It becomes obvious to the POs, stakeholders that something has to give.

 

So how do you solve it? Just saying it can't b done it is not enough. You need to gain leverage over your boss. There are several tricks on how to do this, but it would take me a few hours to cover some of the tricks. My favorite trick is going around the boss and convincing other team leaders that we need more manpower. They will do the job for you and force your boss to hire more people. 

You have to study the chain of command to understand how you can manipulate anybody in your company.

0

Share this post


Link to post
Share on other sites
1 hour ago, esqualidus said:

my 2 cents for this topic :

 

I use scrum, and I hate scrum!

 

And besides i hate all those so called "scrum experts" : Very strict people that have a very strict idea how  scrum should work.and THEIR way is always the best!!! ( funny to see them fighting with each other...hahahaha) 

I love scrum but I hate "scrum experts". Ideological idiots. The least agile persons on the planet! They make you follow it strictly!

Quote

 

I work with JIRA (i think its a standard in big companies) ,

in my case 1 SP = 4 hours. and in my last project there was NO buffer. (everybody was exploding of joy...NOT).

If you are using 1 SP = 4h, your scrum master is an idiot and he does not understand what a story point is.

Either you use story points or hours, story points is not a unit that can be converted to hours.

 

Quote

my personal "like" goes to the V-modell. 

V-Model has very limited use these days. SCRUM is quite powerful, but most scrum masters are idiots with a "scrum master" diploma.

0

Share this post


Link to post
Share on other sites
1 hour ago, BradinBayern said:

I work on a long-term large SCRUM project and it works fine.  I think the key is to keep things flexible.  If you need time to investigate something, then you write a story to spend some time investigating something, estimate it, and plan it into the sprint. Same for architecture.   If something will take longer then expected, then you re-estimate it.  One adaptation that we have had to make is to break into expert teams that are responsible for different parts of the overall application.  The project is simply too big and complex to have people having to gain new expertise because they are working on something entirely new to them each sprint.  

Correct. That is a good approach.

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now