Reply to: ThoughtWorks

[LondonManc]

Eggheads?

Panel game. Generally 1 vs 1.

[fidot]

Which is an analogy of why quiz teams with more than four are not great.

Eggheads?

[LondonManc]

Pair Programming is old hat nowadays....

May I introduce you to Mob Programming – All the brilliant people working on the same thing, at the same time, in the same space, and on the same computer Why only have 1 backseat driver when you can have 5 including the product owner and the BA....

Which is an analogy of why quiz teams with more than four are not great.

[VillageContractor]

Moniker

Interesting observations: what is your opinion on LEAN and SCRUMBAN?

In my contracting career today, I have not yet found a company that was working as proper LEAN: down the tools, stop the assembly line.

Lean is the basis for Kanban - continuous improvement. Lean gives you tools to highlight bottlenecks and how to improve on existing process.

ScrumBan is neither Scrum or Kanban. It essentially is a ScrumBut (which is what most companies do). I've rarely seen companies who do Scrum by the book

[eek]

Pair Programming is old hat nowadays....

May I introduce you to Mob Programming – All the brilliant people working on the same thing, at the same time, in the same space, and on the same computer Why only have 1 backseat driver when you can have 5 including the product owner and the BA....

[LondonManc]

Have you heard of "SCRUM-BUT"?

We do "SCRUM" at the Donkey Nuts Investment Bank GMbH, "BUT" we do it our way.

We are Agile, our daily sit-down last 30-45 minutes and we have 20 people in the office on average meeting time at 8:30am.
Of course we do two week iterations, we don't bother with sprint planning nor do we like retrospective.


Sheesh. Get out of that so-called Agile environment fast!

Yes, it's like anything that just gets paid lip service. That's the main reason agile doesn't work and never will work. I can see the advantages of agile done properly but the Agile fanboys cannot get their head round not doing it properly, which is their main weakness. A senior manager made his way up the corporate ladder without agile, therefore doesn't see the need for it but it keeps the staff happy and makes one of his subordinates the scapegoat for project delivery failure.

It's all a political game as to what's used. I'll just keep workin', smilin' and billin'

[rocktronAMP]

In waterfall they know how much "it" will cost and when "it" will be delivered, but they don't know what quality or how useful for what reality will be then, thus the ROI is questionable.

In agile they know how much "it" will cost and when "it" will be delivered, and they can be quite certain that "it" will be of good quality and be far better aligned with what reality will look like by the delivery date. The one thing they can't be certain about is what "it" will be, but whatever it is, it will provide far better ROI.



ROI is one good metric. EVM is another one. Both works very well with agile and especially EVM can be embedded in burn-up charts.

At one time I dared ask the PMO what the RAG status colours actually meant. Nobody knew. The status was pretty much assigned by gut feel rather than by any empirical or scientific method.

At the end of the day stakeholders tend to care about risk, and agile is an excellent way of managing risk.

Moniker

Interesting observations: what is your opinion on LEAN and SCRUMBAN?

In my contracting career today, I have not yet found a company that was working as proper LEAN: down the tools, stop the assembly line.

[rocktronAMP]

Spot on!

You should only go for it if everyone is committed to it!

And I agree with that.

The trouble is that technical leaders and project managers must also communicate up the organisation chain, especially as soon as they think that deadlines will slip.

You should be able to work out generally what the budget for a project is. The total cost depends on the quality of software. I have seen tons of legacy software with lip service paid to unit tests. How can a developer safely refactor without any tests? If the Unit test fixture are brittle and the code is band-aid upon band-aid over several years. If the software quality is so bad that to simple add a new property to web form means that you have to edit the HTML5, fix AJAX, adapt the server side controller, fix the back end and then finally run a script to fix SQL in the database, then you are dealing X*Y*Z complexity. Explaining this to the managing director is the hardest thing, and they simply sometimes don't want hear it. So it is not Agile fault or Water fault. The Tulip just happens!

And finally there are some people who are PASSIVE AGGRESSIVE, say fun things and stab you in your tulip tulip back when you are not looking or around.

[rocktronAMP]

To have credibility, a scientist should have a PhD, no question about it.

The problem with agile is that 90% of the projects that I've seen claim to be Agile aren't run as Agile. There's either a failure to convince senior management to arrange their budget differently (this guys have delivered successfully under waterfall/v/JFDI for many years so have a different mindset) or nobody with the stones to attempt to convince them that an agile methodology is totally different to waterfall and explain with simple pictures how it works, including roles.

Have you heard of "SCRUM-BUT"?

We do "SCRUM" at the Donkey Nuts Investment Bank GMbH, "BUT" we do it our way.

We are Agile, our daily sit-down last 30-45 minutes and we have 20 people in the office on average meeting time at 8:30am.
Of course we do two week iterations, we don't bother with sprint planning nor do we like retrospective.


Sheesh. Get out of that so-called Agile environment fast!

[rocktronAMP]

Client co is in West London.

Sky near Osterley?

[oracleslave]

I've never seen a large scale business transformation / ERP Programme successfully delivered utilising an Agile methodology. Seen many done via a waterfall approach though.

[LondonManc]

"Delivered successfully under waterfall" is such an oxymoron.

That says more about the teams you've worked with under waterfall than anything else.

I've managed and worked in projects that have delivered very successfully under waterfall.

[rocktronAMP]

I have worked with https://www.thoughtworks.com/profiles/martin-fowler before.

Best not to say where or when.

I could tell a few stories - but not publicly.

BrilloPad would love to hear them.

Thanks for revealing the stupidity of their uppity we-know-best culture. I once went over there to Holborn on a permanent job interview 8 years ago. I put me through a full morning of programming tests whilst I tried to impress and get the gist of the developer role. I couldn't stand it, and they never gave me any feedback on the test. I asked twice, but HR was so slow I gave up. I was glad I missed it.

They can stick their quarterly Tech Radar to the tulip too. It is just like a the Gartner Hype Cycle for IT directors. Get real, you ain't doing Microservices when you are trying to put lip stick on a Mainframe based banking architecture.

[m0n1k3r]

If you build a team who is capable of major delivery, it will be done regardless, or should I say in spite of, of the supposed methodology involved.

Indeed. Trouble is, most customers won't pay for such a good team. I've been in this business internationally since 1994 (before then I was a permie) and customers always have great cost pressures and want to build teams with one or two great, senior people, a few intermediary ones and a large number of juniors and recent graduates. While those may be technically good, they lack the experience of dealing with the inevitable politics & bullying and expectations on self-management, and consume most of the resources of the more senior people. It ends up costing more that way, and there are few customers who would just allow a supplier team to 'get on with it' and deliver great results in the end. Customers are often their own worst enemy because of their own perceived need to 'be in control', 'take charge' and 'manage and supervise' the skilled, educated, experienced knowledge workers they were looking for.

[oliverson]

If you build a team who is capable of major delivery, it will be done regardless, or should I say in spite of, of the supposed methodology involved.

Couldn't agree more.