Tag Archives: agile

Test driven architecture – use your tests to inform architecture

Posted on by

As test-loving development teams, we are all painfully aware of the complexity of getting an application into the zen state of development – quick, test-driven red/green feedback for developers, software designs that are functionally on-the-money from a test-led, “outside-in” approach (from BDD), and a nigh on seamless continuous delivery process as a result. Very few teams achieve this, and those that do are frequently gifted a green-field project in which to engender them.

As test-savvy teams, when tests start to hamper the release process, we often assume our approach to testing needs an overhaul, but that might not be the case. Here we look at the role of architecture in test-driven applications, and examine whether we should listen to our tests to examine our macro design.
Continue reading →

Scope Creep v Flexible Scope – Undisciplined v Agile

Posted on by

Bart asked “What do I do when agile is abused as an excuse for scope creep?” with the sub-text “You’re agile so you’re flexible, no?”. I say point out the difference between scope creep and flexible scope. Agile makes changing scope a zero sum game – that gives flexibility without the creepiness.
Continue reading →

TPM – Project Manager who is technical or technical person who manages?

Posted on by

I squirm when I see a job description for a “Technical Project Manager (TPM)”. My experience is that an organisation advertising for a TPM is often confused about what they are looking for. Do they mean a project manager who is technical or a technical person who provides some coordination? Often you’ll find both types in the same “project management” team.
Continue reading →

Little’s Law – the basis of Lean and Kanban

Posted on by

Sometimes I think it helps to go back to basics. And when using Lean Software Development, including Kanban, that means a man called Little and his Law. “Little’s Law” is a fundamental of queue theory and defines the relationship between Work in Progress (WIP), Throughput and Lead Time. It is the reason why Kanban teams try to limit WIP.
Continue reading →