How long before MF has his breakdown?

[Mich the Tester]

But the advantage agile is that you should discover the mistake quickly.

And that it will be so obvious to any half competent new recruit what happened, why it happened and to put in place escape procedures asap.

Indeed. However I think what some people underestimate with Agile is the demands it places on both dev team and customer. The collaboration aspect is crucial, and you can have the best dev team in the world but if your users and product owner are fools you'll still end up with a big pile of crap, because collaboration with fools can only lead to a mess. But yes, the big advantage is you get the pile of crap quicker so you can start solving the problem sooner.

[d000hg]

Indeed. However I think what some people underestimate with Agile is the demands it places on both dev team and customer.

Very true.

[original PM]

Indeed. However I think what some people underestimate with Agile is the demands it places on both dev team and customer. The collaboration aspect is crucial, and you can have the best dev team in the world but if your users and product owner are fools you'll still end up with a big pile of crap, because collaboration with fools can only lead to a mess. But yes, the big advantage is you get the pile of crap quicker so you can start solving the problem sooner.

indeed - 80% of the requirments delviered in 20% of the time.

P1sses of some BA's though as they cannot spend months and months gathering requirements to the nth degree which would have become obvoous at the first iteration/increment.

It requires everybody to be committed to delivering the project - which also means it quickly highlights those that are not - which is normally the business/customer as they expect to chuck the most basic requirements and have a fully working system with no bugs within 3 days.

But like any project methodology it is no substitute for 4 or 5 people with the right skills committed to delivering the project.

[MarillionFan]

indeed - 80% of the requirments delviered in 20% of the time.

P1sses of some BA's though as they cannot spend months and months gathering requirements to the nth degree which would have become obvoous at the first iteration/increment.

It requires everybody to be committed to delivering the project - which also means it quickly highlights those that are not - which is normally the business/customer as they expect to chuck the most basic requirements and have a fully working system with no bugs within 3 days.

But like any project methodology it is no substitute for 4 or 5 people with the right skills committed to delivering the project.

Been a tricky one to be honest. Classic 20/80.

The agile team had developed off a technical FRD and developed stories after discussion with the business. They had demoed functionality as they went and the business had said 'looks about right' before the project went into a hole for a few months. The developers finished up.

The business did not test the resulting code or product. Everyone could demo it though and there were 10
Test records in it. It's supposed to be a major enterprise deployment.

New people arrive. Get a demo from the only two business SMEs left. The business has no documented processes and from a BPM maturity perspective are at the first level. Hero worship and get tulip done is the level they are at.

Everyone new asks what the business requirements are!

So in a mixture of (a) Document the high level business processes (b) SME demo (c) Reverse engineer the code - we attempt to fill in the missing documentation. Only stories exist for the first half. They developed other stuff not documented anywhere.

Needless to say if the business processes had been understood, the business bothered to test properly and engage coupled with the agile team this would have worked. But the lack of ownership and business maturity means that at the end, the product is no more than a simplistic prototype , a selection of good ideas badly implemented and the mooted 'go live for next month' is to be pulled and I've placed a 4 month delay on the project as there is so much they didn't think about.

[Mich the Tester]

Been a tricky one to be honest. Classic 20/80.

The agile team had developed off a technical FRD and developed stories after discussion with the business. They had demoed functionality as they went and the business had said 'looks about right' before the project went into a hole for a few months. The developers finished up.

There's the problem; an Agile team should never go into a hole for a few months; you have to have continual contact with the customer, at least via the product owner.

Of course it's the PO and business responsibility to be involved, but the responsibility of the team to tell them what the consequences will be if they don't get involved.

[MarillionFan]

There's the problem; an Agile team should never go into a hole for a few months; you have to have continual contact with the customer, at least via the product owner.

Of course it's the PO and business responsibility to be involved, but the responsibility of the team to tell them what the consequences will be if they don't get involved.

The Product Owner left. The project had been kicked off at the beginning of the year. In May I joined as a contractor with another mate who took on that role. He lasted 3.5 months and took on everything. 3.5 months later he burnt out and quit. Fast forward two months. I go perm and take the role. Lo and behold I'm up PO.

I phone my mate up and bollock him for a lack of documentation. He sites the project as a piece of tulip, says it won't work and one of the reasons he quit.

I push the ownership back on the business and take on the role of BA/Programme Manager. After 3/4 weeks of very intensive hours its obvious what went wrong and yesterday after trying to sort it out for the proposed deadline had to admit that even though we could demo the system at a major launch in 3 weeks it would never be ready a month later for proper rollout.

Now interested what approach I should take. Being trying to produce a classic all encompassing BRD but that's taking an age and some BR constantly involving. So what would be the best approach to meld BR to agile Mich?

[Mich the Tester]

The Product Owner left. The project had been kicked off at the beginning of the year. In May I joined as a contractor with another mate who took on that role. He lasted 3.5 months and took on everything. 3.5 months later he burnt out and quit. Fast forward two months. I go perm and take the role. Lo and behold I'm up PO.

I phone my mate up and bollock him for a lack of documentation. He sites the project as a piece of tulip, says it won't work and one of the reasons he quit.

I push the ownership back on the business and take on the role of BA/Programme Manager. After 3/4 weeks of very intensive hours its obvious what went wrong and yesterday after trying to sort it out for the proposed deadline had to admit that even though we could demo the system at a major launch in 3 weeks it would never be ready a month later for proper rollout.

Now interested what approach I should take. Being trying to produce a classic all encompassing BRD but that's taking an age and some BR constantly involving. So what would be the best approach to meld BR to agile Mich?

Don't be the PO; that should be someone from the business; someone good who understands the business and not just someone they can miss for a while; he should be involved in scrum meetings at least once a week, saying what he wants, what he doesn't want and giving the priority; he should also be on call to answer questions from devs and where necessary sit with them to work through a story. The business simply has to make this capacity free for you and otherwise the whole thing will fail. Tell them that if you get that cooperation then you can start providing working functionality in two weeks; not all the functionality but the bits THEY decide are most important. Never try to set priorities for your client.

[MarillionFan]

Don't be the PO; that should be someone from the business; someone good who understands the business and not just someone they can miss for a while; he should be involved in scrum meetings at least once a week, saying what he wants, what he doesn't want and giving the priority; he should also be on call to answer questions from devs and where necessary sit with them to work through a story. The business simply has to make this capacity free for you and otherwise the whole thing
will fail. Tell them that if you get that cooperation then you can start providing working functionality in two weeks; not all the functionality but the bits THEY decide are most important. Never try to set priorities for your client.

Ok on your definition then I am the PO in this case. I am in the business. Be careful what you inherit. :

[Mich the Tester]

Ok on your definition then I am the PO in this case. I am in the business. Be careful what you inherit. :

Yep, so you need someone who really knows the business well and knows what it needs, because I can't believe you've been there long enough to know that; that person can and must support you if you can't avoid the PO role. Serious, the Agile projects that I've seen fail went wrong for precisely the reasons you've given in your story; lack of client involvement, devs locking themselves in a room for weeks on end etc etc. It's not about project delivering to business, but project and business collaborating quite intensively; they might not have known that when they started the project though.

[MarillionFan]

Yep, so you need someone who really knows the business well and knows what it needs, because I can't believe you've been there long enough to know that; that person can and must support you if you can't avoid the PO role.

Well that's the point. The SMEs are at bursting point. Only two people know the processes in detail and still not end to end. I now own 'systems and processes' which bearing in mind is missive in its own rights & requires huge business knowledge its a struggle. Hence my plan to kick off a BPM project. Start to get business processes documented in a meaningful way. Align them to people & systems, break it into chunks. Bring people in to cover the bases.

Trying to do all of this when effectively sitting in the middle of a blender is tricky. Maybe it's a good thing I could identify we needed to pull the plug for a while on the new launch.