If we don’t identify the champion of the endeavor to convert to agile processes, we can’t keep them informed of progress. Their expectations need to continually adapt to progress just like every element of agile.
Going Agile, 10 Mistakes: Ignore the Corporate Culture
Many companies operate with each department acting as a silo. Agile techniques rely upon cross-functional contributions. When there are barriers (“not my jobâ€, “not your jobâ€) within an organization, they have to be addressed before agile will work.
Going Agile, 10 Mistakes: Go Fast To Go Fast
In this mistake, Levent warns us that “just doing it†without training and explaining won’t work. Everyone needs to understand exactly what agile is and what it isn’t.
Going Agile, 10 Mistakes: Go All In
Levent points out that the biggest mistake is to not do a pilot project, but rather to convert a large and risky project – or even worse, all projects. He points out that it is a mistake because you won’t have time to learn from mistakes.
To Buy, or Not To Buy. To Build? is the Question
Should we buy this application, or build it in house? How should we make that decision today?
Overdoing Personas
Its easy for us to overdo almost anything. Kim Goodwin offers some good advice about how not to overdo it when using personas as part of our software development process.
Actor Hierarchies And Then Some
Actor Hierarchies give us an overview of the people who will interact with the system. We can extend this model to provide a visual indication of how use cases are distributed through the organization. Further, we can leverage a hierarchy to show how use cases are rolled out to the users – a targeted communication for our stakeholders.
Incremental Delivery and Evolving Use Cases
Amazon.com started by selling books. Their initial use case was “Sell books online.” The vision was always “Sell everything” – hence the name. But they started with a simple use case and evolved it.
Prototype Fidelity
Prototyping is invaluable for getting feedback on a design. It is also great for getting validation of requirements. It can even be used as a means to document the requirements. What level of fidelity should be used when getting feedback? Jan Miksovsky provides some guidance from the real world.