One of the ongoing insights I have discovered from my agile team leadership journey is continually realizing the awesome power of transparency. It’s something that cuts through all of the traditional Waterfall management speak, for example: “Let’s get this project back on schedule”.
User stories are not, and should not be, complete requirements for software development. People call user stories a placeholder for a conversation, meaning the stories capture the essence of what is wanted, but they don’t contain the detail. When the time comes to do the work, there will be a discussion about what the stories […]
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.