Agile meeting

Be physically Agile (part 3)

Being hired by a rather big company which develops many products at the same time, my team is regularly subject to changes in size. Another project in the same department all of a sudden faced a dangerous phase, and our number of team members shrank to 70%. And two months later, a new colleague joined us, facing a very new subject matter.
Although Scrum is all about being agile, it turned out that a lot of frustration could be removed from our team by requesting all team members to be more disciplined and to follow certain internal process guidelines, always.

We are working on two different code bases (we develop low-cost and high-cost versions in parallel with almost the same functionality) but use a shared test environment with the same test cases forJosephine Wittkowski both platforms. These automated tests need to run successfully, always, but they tend to start failing after performing modifications in only one of the two coding platforms.
What we learned over the course of a year is that we need to be very tedious about communicating even the smallest changes. And what is more efficient (and healthy): Getting up from your chair and talking to another team member or sending endless emails and writing notes in file versioning systems? It also leads to great social interaction, and thus allows newly added team members to become productive very quickly. By helping each other on an hourly base, we also achieve that everybody can do everything and we develop a real team spirit by finishing user stories together.
By the way, important decisions and outcomes of discussions of course still are formally written down.

Lessons Learned

Ask your team members to help you finish a user story, since their input is of great value and this way also you share your knowledge easily. You could even enforce this attitude in your team by restricting the amount of user stories which are allowed to be in progress at the same time.

Author: Josephine Wittkowski
Consultant ALTEN Technology (Technical Software)


Sneaky bugs need special administration (part 2)

I can honestly not imagine how this project could be handled in a waterfall, i.e. non-agile way. In the beginning [...]

A high velocity is not the key to happiness (part I)

As a team of embedded software engineers during a refinement session we once faced the review comment ‘This doesn’t make [...]