Organization & Culture

Not Agilefall or Watergile - just plain agile

Agile processes defies phases in the software development process. The 1st principle in the Agile Manifesto refers to continuously delivering software.

An agile approach is not a small waterfall or a interactive and incremental process speeded up to 14 days intervals. It literally has no phases - only continuous integration and continuous delivery with focus on minimizing work in progress and get the right thing done - at a constant pace.

Continuous Delivery is not a grass root approach

Initiatives, new tools and approaches are often of natural interest to developers and they might experiment and research without explicitly being told to do so.

But Continuous Delivery is a paradigm that strives to build quality into the product rather than gluing it on afterwards.

Transitioning is going to take time. It needs planning. It needs prioritization. It needs funding. You need a road map. Continuous Delivery is not a quilted patchwork. Be sure to make it a corporate thing, not just a neat idea.

Size matters - small is beautiful

Assignments should be prepared for working before they qualify as actual tasks. The goal of a task must be known to the person who is implementing it.

If a task is ambiguous it can not be estimated, and if it can not be estimated, it can not be prioritized.

If a task doesn’t have a clear definition of done, then it should be time-boxed.

A designated driver brings everybody home safe

Shared responsibility often leads to misunderstandings. When the people involved rely on the others to manage that responsibility.

Even if the responsibility is assigned to a role, and that role is given to one person only, it’s often the case that the person hasn’t allocated time to actually perform the duties.

Every process, that’s required, needs to be assigned to a role and that role needs to be assigned to a person, who is actually expected to responsibly spend time on performing these duties.

Aim for a high "bus factor"

The bus factor measures how many people in your corporation need to be run over by a bus before you go out of business. If you have a key player who’s indispensable, then your bus factor is 1.

To raise the bus factor, you must make sure that important knowledge is shared and accessible to whoever needs it.

Don’t document your processes to the brink of boredom or maintain an internal wiki the size of Wikipedia itself. Build a learning organization that encourages people to share with colleagues, allocates time for research, designs for change and accepts automation as documentation.