Agile software development refers to methodologies and principles of effective, iterative, and collaborative programming. It becomes more and more popular nowadays as suggests a more affordable and client-oriented process. Agile nearshoring means delegating programming tasks to dedicate teams in a nearby country to increase business success and get a project released faster.
Articles and videos on creating and managing cross-functional Scrum teams: scrum master, product owner and development team.
In their book “Help Work to Flow”, Samantha Laing and Karen Greaves have explored their Agile working and coaching experience to collect 40 tips, techniques and games that should allow you to work in the state of flow, this situation where you are more productive.
The values contained in the Manifesto for Agile Software Development might be good for the Agile teams, but most of the senior management in organizations prefer having a defined solution, a detailed planning and a budget that should be respected. This article discusses how to make these two different approaches work together.
What would be made possible if you could unleash the intelligence and creativity of everyone in the Scrum team? Liberating Structures are a collection of easy-to-learn facilitation patterns that make this possible. They are field tested, rooted in complexity science and freely shared under a creative commons license.
In an ideal Agile world, the Scrum Master takes care of only one Scrum team. This is however not always possible and then he has to split his time between many teams. In this article, Alexander Chaves shares some tips on how to lead multiple Agile teams without becoming insane.
Reetro is an online agile retrospective tool. It simplifies the process of planning, managing and executing retrospectives. Reetro offers a variety of features from very simple user experience, automation and analytics.
Its increasingly common that Agile software development teams are distributed across multiple offices, in different countries, all working remotely on the same product or project. But how do you make this work well? There seem to be a number of readily accepted tenants of conventional wisdom to help deal with leading distributed teams, from seeming good ideas “teams must be co-located” to ones that are purely economic “offshore teams can be run at a far lower cost”.