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.

When coaching scrum teams it is alway a good idea to combine theoretical teachings with some exercises that simulate what you’re teaching in a short time. When thinking of which exercises I could use to simulated the methodology, “The Ball Point Game” I’ve done in a training class by Boris Gloger many years ago came to my mind. The game had a prompt impact on me in regards of Scrum. The game simulates all the sprint ceremonies, such as planning, sprint, review and retrospective.

When implementing agile software development in teams, context seems one of the least noticed factors. That’s remarkable as it is one of the most important aspects to consider when adopting agile methods. With a series of posts I want to shed some light on that topic, looking at context in agile software developments from different angles. Contexts that are relevant and worth to consider when starting agile software development are organizational culture, team setup (distributed or collocated, skill levels, language and cultural differences) and experience in agile methods and principles (maturity).

User stories in Scrum are work items that the team implements and turns into working software. The product owner is mainly responsible for developing user stories. However the team will have to work with the product owner to refine the user stories to ready user stories. This means the stories must be clear, concise, and immediately actionable. I’ve personally seen many teams struggling through the sprint, holding endless debates and get nothing done by the end of the sprint. The reason was simple that the user stories were not actionable and the result was frustration amongst team member as well as product owners.

All of you who are familiar with the Agile Software Development Manifesto, this post seems familiar. Actually the inspiration for it comes from the Agile Manifesto, which says: Customer collaboration over contract negotiation My inspiration for this post actually comes from that. Only that I don’t want to limit collaboration to contracts. Collaboration is something that I find usefully in any part of software development, even outside of software development. But let’s focus on work space in this post. Whenever I worked in an collaborative environment, I enjoyed it. It wasn’t that important what the subject of the project was or which methodology or project management framework was used. What brought the joy was collaboration with colleagues, clients or other …

Collaboration vs Negotiation Read more »