Project Management Central

Please login or join to subscribe to this thread

Topics: Agile
Is it Agile?

I'm witnessing a situation that seems to have merit, and yet is causing a bit of cognitive dissonance, for me, at the same time.

Several of my peers are working with a consulting firm on a large scale Scrum project. They each have their own agile board with similar columns for their deliverables. At first glance, their boards have twice as many columns as you would expect. It just feels wrong when you look at it, if, like me, you're used to single-team Scrum.

The best way to describe it would be that they are using multiple statuses and sprints to develop user stories to meet the Definition of Ready. Half of the work represented on the board takes place before a developer has written a single line of code.

Is this scaled Scrum, or waterfall broken into sprints?

Have you experienced or seen something similar? How did it work out?
Sort By:

First of all, while I will not answer your question, Agile is not softwtare or IT, is not a process or method. That mean that Agile could be used to create any product, with any process (for example waterfall). Second, in this case you mentioned they are using SCRUM. SCRUM "by the book" is not a method, it is a framework. And as other frameworks you can fill it with any tool and technique best fit to the initiative. But SCRUM has a process defined into it and some "ceremonies" that, if you follow SCRUM "by the book", must not be changed. I worked with Agile from the genesis (including I am part of the group of authors of one best known method: DSDM) and if you ask me how many times I have used a method "by the book" is dificult to me remember too much times. In fact, SCRUM is one of those cases (we are using SCRUM today to create non-software products for example). So, what you describe, could or not could be SCRUM because the important thing is, if you are talking to use SCRUM "by the book", if the framework is following or not. Unfortunatelly, now that Agile is a buzzword, lot of people outside there saying they are working with Agile and that is not right. Perhaps your peers are in that situation.

Agile suggest to create ship-able deliverable in each sprint/iteration and final product/service will be incremental and iterative. This is arguable in practical and in many situation we can't build a ship-able product in 2 or 3 weeks , There are stories called spike which can be done for research/architectural work. In Practical deliverable could be document,diagram...etc not necessarily complete package/working software , but at the same time we can't have all the stories go through multiple sprint/iteration ....if that is the case that is not agile...

I've seen situations such as this. Teams tend to breakdown a task's checklist to smaller tasks. Which is fine for large tasks, but an overkill for small tasks. I've created a trello board for our team to use with our tasks. One of our programmers felt it to be necessary to include information that is more relevant to the PM but he wanted to see the information on the initiate and planning stages of upcoming projects. Made our board more complex than it needed to be for our team.

Sergio and the previous posters all point to the same thing: it is extremely rare to find any framework, method or methodology in its pure form in the "wild".

IMHO at the end of the day, the success of any project relies less on the organizing/management structure and more on the team members. So Aaron, if the consulting firm can make their process work within your organization it doesn't matter what it looks like, only that it works.

Thanks for the responses. The situation is complex, and my jury is still out on two things; 1) whether or not it makes work more complicated, and 2) whether or not it is working.

Whichever version of scaled Scrum is being used, it is not being run by the same book as single team Scrum. I'm not saying it's right or wrong. It's more that I'm trying to come to terms with the approach. A different consultant has asked me about using this approach on my mobile project. Part of my struggle is that this approach seems to give the consultant the ability to report on progress of user stories before development starts, and I'm not sure that the status is really valuable, in my situation. Is it really meaningful to have fifty user stories "ready" for Product Backlog Review or Sprint Planning when you might size fifteen of them and only put seven into the next sprint?

Is it real work, or is it illusion?

Not enough information is available to actually decipher what is the case here. But from the information available looks like scrum of scrums. Each one if working on their own whiteboards then this also indicates that the user stories are not interdependent and maybe independent features.
If a lot of work is done before code is written this doeS indicate using FDD methodology, but still need more info.

Normally a process, tool or technique serves the groups who use the process? Is the process working for the team/group that created the boards or do you think the board adds no value since its not an approach you'd use?

Let's just say that the people who are satisfied with the process and, more importantly, its results, who are not consultants, are a very small minority.

One way I can see this approach working is for the Product Owners to use a Kanban board to keep track of how ready their stories are, prior to Sprint Planning. It's a large project and there are a lot of stories. It doesn't seem like it's working that way.

Please login or join to reply

Content ID:

"If you can't convince them, confuse them."

- Harry S. Truman



Vendor Events

See all Vendor Events