The Agile process: A fast running train?

Came up with this title during a meeting I had today with some colleagues. It was a meeting which I dialed in remote, so I had a disadvantage from the beginning, but that's not my point.

If you put a lot of people into a room, all of them will probably have something to say about 80% of the issues you're talking about. That's what we're experiencing in our Agile process, and a lot of that is good. Everyone knows what it's all about and everyone can have his say, so no-one is left behind or in the dark.

The problem is, that meetings like these are usually more of a brain storm session. We are doing Agile with SCRUM, so you need to take care of the fact that the actual work should be done in the Sprint itself. In that Sprint you should do people in what they are best.

In my case, I'm looking from a Usability perspective to a project and the team is really brainstorming on a lot. And making decisions while pokering. In Agile, that usually is not a big problem, if you have ideas on improvement, make a new story and if that delivers business value, develop it. But in a lot of cases, certainly in ours, we've experienced that those improvements are not often developed because the project has no budget. So if I want to make Usability improvements I need to fight for that and try to get my point through in the discussion. Well, that's life for a Usability Analyst, I know.

How would we improve that and be more (mature) Agile?

• Recognize the right disciplines in your Agile team, like Usability, Testing, Front End Development, Back End Development, Content Design, Business Process Analysis, etc.;
• Don't design too much in the poker sessions, make sure that the idea of the required functionality is clear so the team is able to poker it;
• Recognize that design (not only visual but also functional, navigational and content design) is part of the development process;
• Choose some form to be clear and unambiguous about function, form and interaction. I prefer making a clickable wire frame or prototype, with detail in those areas where needed;
• From a budget perspective, be clear that your entire budget shouldn't be gone when the stories are finished. That's more like a form of waterfall where you just use the budget and then development is ready. Maybe there's is Business Value in there, but in Agile you should be both iterative and incremental. Do do this properly, you need releasable versions you can make improvements on;

If you do this, you will deliver more Business Value. If you don't do increments, you are still trying to do everything in one shot; and that's not Agile. For the same reasons I make wire frames to let my stakeholders see what the effect of decisions is and what value it delivers, you should do that with the releasable product as well. 

I've been experiencing the implementation of Agile / SCRUM in a large company for quite some time now, and I realized quite awhile ago that the change from Waterfall to Agile is not only learning a new methodology. It's not only changing your mindset, but also recognizing that the current situation is not Utopia, but it should be the road to it. You should always think about these things:

1. How are we going to do things best in our current environment and situation?
2. What is the ideal way of doing things?
3. Who do we want to be and what do we want to achieve?
4. How do we get there?

There's no mistake: going to be Agile needs change management. In the spirit of SCRUM: use retrospectives  to consider how we've done and what we need to do, because doing that is often forgotten in the delusion of the current day.