Category: Agile

The A in Agile is from automation. At least in the context of Agile development.

Automate everything that you can. Start with that. It may be a bit slower to do the first time, but as Agile development is iterative, it will likely gain the lost time in no time. It enables scaling of organization and products. It enables being fast and delivering with quality.

Automation reduces being dependent on individuals. In a good way.

To be able to react on changes, create the best product version for that moment, test it good enough, and deliver it is possible manually. However it may be slow, unpredictable, unreliable, and fail because of a flu.

Automatize it, if you can. Especially regression testing.

Let’s be honest. Agile transformations are painful. Changing the way an organization operates is hard. The transformations end up being unfruitful – everything works as before but now it’s called agile. Or worse, ending up to a chaos. Agile isn’t a silver bullet that would fix everything. And maybe it’s not always the way people want to work – we humans are very stubborn and reluctant to change.

Which brings us to the change of area of work. In these transformations the definition of product is tricky. It easily slips to follow the tracks of historical specializations and not to look the bigger picture. The (existing) pseudo-product definition will be done according to layers, technologies, functional areas, or work titles. The old teams continue as they used to, and they keep working on that pseudo-product that is cozy and familiar.

Did something change, except the titles of the meetings and someone’s title?

And the balance of the consultants bank account.

Was there a reason to transform at all?

Someone has a brilliant idea. A search for the right people that can make that idea real starts. The team is formed around the idea. At some point, the team has grown and it has to be split into two. But everyone is working around making the brilliant idea alive.

This is the easy way to define a product in agile frameworks. Starting from scratch, and focusing on the big picture. The team is fully responsible for the product. When multiple teams appear, they’re homogenous. Scaling the organization, until some point, is trivial.

The organization can focus on the most valuable things to do. Any of the teams is able to work on any of the work items in the backlog. Of course, one team can be faster in doing some thing or area than another team. But either team can make it.

Individuals have their strengths, but they’re willing to go outside of their comfort zone and see what sort of scary world is out there. They’re working as a team. Sometimes that even means asking someone else for help. Crazy, right?

But what happens when an existing organization is going thru an agile transformation?

To build a pyramid, you need resources like employees, tools, and huge rocks.

And then you need time. Even with unlimited resources it will take time to build the pyramid, although more resources might reduce the time.

Then there’s the target – what sort of pyramid is to be built. The effort to build a one-tomb-without-a-bathroom -pyramid is less than the effort to build a five-tombs-with-three-bathrooms-and-a-kitchen -pyramid.

Finally, how well is the pyramid to be built. It’s less effort to build a pyramid that isn’t quite well built. It takes effort to make the rocks fit nicely to each other, and to assemble them well so that there’s no gaps in between them.

Same restrictions apply to everything. Resources, time, scope, and quality are harsh constraints – if they’re not in a balance, the outcome is not what was wanted. Software development is not any different.

Question is, which one(s) to sacrifice? And whether this is a philosophical question or not?

As agile gained popularity, for example with the popularity of scrum framework, people started to realize that it is not that simple to apply agile frameworks in a corporate world. One of the biggest problem was, of course, what to do with all the project and program managers.

That’s why god created scaled agile frameworks and the managers had jobs again.

But are such frameworks really agile frameworks as they tend to fix the content, the resources, and the schedule for a quite a reasonable time. It does not sound that agile – but it isn’t quite the text-book waterfall either.

One of the most popular agile frameworks is scrum. The holy trinity of scrum is the team, the events, and the artefacts. Amen. The team works on the artefacts while following the events. A sprint is planned by crafting a sprint backlog, that is worked on by the team during the sprint, and after the sprint a review of what was done is held and a retro of how the team operated during the sprint is kept. And then repeat.

Meanwhile a visionary, the product owner, keeps a product backlog neat and tidy, making sure what is done next is the most valuable thing to do. The product backlog is then used as the input for the sprint planning.

Simple, right? In an ideal world, the outcome of scrum would be a working, evolving, product that is created by a small team, with intimate interaction with the customers. After all, scrum is an iterative and incremental framework.

What about in practice? We’ll get back to that in some later posts.

Agile is a synonym for nimble. Move along, nothing to see here.

In the tech world agile is a term that raises feelings – both in good and in bad. Many of the tech guys have personal experiences and opinions related to the term. It could be, that even the author isn’t completely objective.

It’s easy to use the term agile as a plain category for Kanban, Scrum, Water-Scrum-Fall, and all the rest. But agile is an ideology, whereas the latter are frameworks. And maybe the agile bible, The Agile manifesto, fills the minds of the readers with beliefs of agile being only about software development.

In a bit more vague definition agile is an ideology of how to operate in complex or fast changing environments, where either a plan just can’t be made or a plan would be outdated before it can be applied.

Agile is about accepting uncertainty, welcoming change, and efficiently maneuvering through the unknown.