Traditionally the velocity (V) of agile teams is calculated as number of story points (SP) delivered per sprint. If our team is static, that means, it consists of the same or at least the same amount of people in each sprint we can get a velocity that really reflects the team performance.
Although highly desireable, from my . . . → Read More: Capacity Based Velocity Calculation for Dynamic Agile Teams
Most people would agree to say that an IT project is complex if it has to cope with difficult technology and a challenging business context.
But it is not just technical complexity that threatens the success of a project. Team complexity is an important and often underestimated factor that highly affects the likelyness of success and failure . . . → Read More: Team Complexity – The Underestimated Factor
If you ever tried to create an execution environment to automate business- or integration processes based on Open Source products, you know that this is not an easy task. Although Open Source products like Activiti or Apache Camel are of high quality, they do not run with production grade quality out-of-the-box. For serious usage scenarios typically . . . → Read More: Integrated Process Management with Open Source
What does collocation mean? The concept is very simple. It means bringing together the people who work on a software product in a physical environment. This seems to be natural. But in highly distributed work environments that we have today it is not anymore.
I’ve been working on agile projects for many years and I always hear . . . → Read More: Collocation Is Vital!
The German IT magazine Computerwoche published my article about agility and management. The article describes ths difficulties when scaling out Scrum in larger organisations.
You can read it online. Wann Scrum funktioniert: Das Management muss . . . → Read More: Management Attitude and Agility
Today I would like to share a success story of a project I accompanied as Scrum Coach and Solution Architect from analysis to production.
Main success factors were:
Scrum (Agile Development)
Cross functional Team
Service-oriented Design (SOA)
You can read more in the case study Modernization of business . . . → Read More: Scrum and Silverlight in Reinsurance
According to the second rule of the agile manifesto working software is more important than comprehensive documentation. This is definitely true!
To be clear, this does not mean that software developed by agile teams is not documented. If comprehensive documentation brings value to the organisation, agile teams produce this as well. Specifications are written as well in . . . → Read More: Bug or Change – Cause of Conflict in Agile Projects
Although there is a greater likeliness of success in Scrum projects than in non-Scum projects, Scrum projects sometimes fail as well. If you ask the people involved in failed Scrum projects, they quickly accuse Scrum of being the cause for the failure. They claim to have done everything that Scrum requires, but failed, so the method . . . → Read More: How to Staff an Agile Team
Although keeping a Scrum team together 100% on-site is the ideal situation, sometimes it is not possible and the team works distributed. In such situations it might be handy to have a tool that can be used instead the whiteboard. A kind of virtual whiteboard that is accessible from everwhere. A popular modeling tool in IT . . . → Read More: Scrum Planning with Enterprise Architect
Over the last decade I have seen many software solutions. Some excellent and some really bad ones. But most solutions were somewhere in the middle. They just did what they were supposed to do.
But is this really good enough? I don’t think so. Especially today where time to market is critical and the budgets are limited, . . . → Read More: Core Values of Great Software