Author: Maik Seyfert

Technical debts are part and parcel of the software development process and no matter how careful we approach the development process, there will always be possibility that we may encounter them along the way. Technical debts imply that a developer, at some point applied the easiest route to a solution instead of using a better approach to a problem that would take time. The most vulnerable time for making these haste decision is when the deadline for release of a software product is nearing and there is still work to be done.  These debts can also be incurred during bug fixing. A lot can go wrong during debugging, and removing a minor bug on a large projects sometimes can cause …

How to avoid and deal with technical debt Read more »

Self-organizing teams are an integral part of agile software development and one of the 12 principles of agile manifesto. Even outside agile software development, self.organizing teams can bring a lot of benefits to the organization. The sole purpose of these teams is to ensure that the process of decision making is decentralized, faster, and agreeable to all members. The self-organizing teams are autonomous, hence it becomes possible for them to determine how they want to approach a given problem. They also decide independently of any other teams, group or managers on what decision to take, implement and how to complete any tasks.

It is not a secret that companies are always looking for better ways to handle their software development needs to avoid projects dragging for long periods. Agile software development is one of the most preferred ways of software development due to its dynamic development nature, whereby, requirements and solutions evolve during the entire development process. The emphasis on collaboration between different self-organizing and cross-functional teams is at the core foundation of this method. Characteristics of a good agile development team When selecting a team for agile software development, a company should ensure that at a minimum, they meet the following factors.

Throughout my agile journey I’ve experienced and facilitated many retrospective meetings for agile teams but also for long running projects. Often I’ve experienced that teams and sometimes even facilitators are not familiar with common basic structure of activities that an agile retrospective meeting should follow in order to make the meeting go smoothly and to generate qualitative action items for improvement. From my experience it helps teams a lot to when retrospectives are created along this structure of activities. The structure is published in the book Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen, which I strongly recommend for anyone who is new to the subject.

As my last post was about how to write good User Stories, this post is about good structures for them. When developing products that require several team and stakeholders to collaborate, it is beneficial to have a common User Story structure so that everyone can focus on the product instead of struggling with information and requirements about it. With all the points below please remember that a User Story should be a place holder for conversations. So avoid adding all details and take away room for negotiation and conversation.