We can’t measure everything, and because we have to limit our measurements, some things invariably fall between the cracks. For example, we tend to measure project performance based on cost, schedule, and scope targets. But these measurements don’t take quality and customer satisfaction into account.
To reiterate, an aspirant architect should have in-depth knowledge in either one of the application, data or infrastructure domains. Just has having at least one pillar to support the roof of a house is essential, an IT architect needs depth in at least one of the domains to support a solution architecture “roof”.
Often our clients ask us “Which projects are not compatible with an Agile approach?” They are probably expecting us to reply that package implementations, mainframe technology, highly regulated industries or break/fix teams should not use Agile.
Best practice hates contexts, better practice loves contexts. — Hermanni Hyytiälä (@hemppah) August 25, 2017
Customers are at the heart of everything we do. This seems obvious, right? Yet all too often we assume shared understanding of who our customer or users are. What their needs are, why we’re building a feature for them – and that they even care about it. We have to remember we are not our […]