Cloud Foundry: Design and Architecture
Derek Collison discusses the goals, the design premises and patterns employed in creating the architecture of Cloud Foundry, VMware’s open source PaaS, unveiling internal architectural details.
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Vikas Hazrati on Mar 23, 2011
Commitment is defined as the act of binding yourself to a course of action. In Scrum, commitment has a strong meaning and Scrum practitioners suggest that authentic Scrum is not possible if people are not keeping commitments. In-spite of this, forums have a lot of questions about commitments not being met. Do we understand the real meaning of commitment?
Jens Coldewey suggested that commitment in an Agile team is the commitment done by a self-organizing team to do a good job. This is a team where the team members are enthusiastic and take pride in their work. Commitment on the number of stories which would be completed or the number of story points which would be delivered is an incorrect form of commitment.
Committing to certain stories or a number of story points is like a surgeon committing to a certain time period in which the patient recovers: you commit to something that is simply out of your control. If a team does not finish as many stories as it thought it would during the planning meeting, it just means that it has responded to change.
According to Jens, commitment to anything, apart from doing a good job with passion violates the Agile Manifesto too. If a team commits to deliver a certain number of story points 'no matter what' and they happen to encounter a change then, there are only two possible options to meet the commitment. Either by putting in extra hours or reducing the quality.
Likewise, John Sonmez quoted that though commitment is an unspoken central theme of Scrum however, in reality the biggest weakness of commitments is that they cannot be followed due to one reason or the other in the real world context.
So, what is wrong with commitments? They cannot be followed. The business doesn’t want to change priorities, but a critical issue comes up. The development team wants to commit to the sprint, but the development team can’t make more code get done faster simply by wanting to. They can add more hours to the sprint, but then they are skewing the velocity. The only way the development teamcan realistically commit to the sprint is to ‘pad’, and that is a very bad word.
Another problem with commitments is the one suggested by Chris Goldsbury. Different people might understand different flavors of commitment. For some it means to complete the stories and tasks in the iteration no matter what and for others it might mean 'trying' to complete the stories and task with the underlying assumption that some of them would move to the next sprint. This subtle difference in understanding results in a huge difference of outcome.
In a similar discussion, Glenn suggested the following definition of commitment
The commitment that a team makes is to work professionally and follow the rules of Scrum. The Sprint end date is fixed. There is no commitment to content. Of course meeting the commitment means many things including getting backlog items done-done. If backlog items remain undone at the end of a Sprint then they go back on the backlog.
Rawsthorne and Shimp described their technique for 'commitment based planning'. According to them, one of the reasons for it to work is that it is not based on sizing of stories. It is rather based on realities and facts at that very moment of time, taking the current situation into account rather than doing a commitment based on story sizing done in the past.
Hence, according to many people in the Agile community, defining a commitment based on stories and story points does put some checks and balances in places for the validation of the sprint, however the real commitment is still the dependent on the passion of the people and their willingness to win.
Agile Maturity Model Applied to Building and Releasing Software
Improving Software Delivery Cycles: Pre-requisites and Inhibitors
Agile Practices to Improve Project Management Organization (PMO) Effectiveness
In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!
FYI, here's another blog post by Lü Yi, about commitment.
blog.odd-e.com/yilv/2010/12/commitment-whats-yo...
There still is the need to define commitment based on "stories and story points" just because it is a more objective measure.
Passion is not measurable / explainable to others and I believe that if it is high the "stories and story points" will anyway come out fine. So it is a good measure till we reach the hallowed "commitment of passion points".
Why is it important to have an "objective measure" regarding the (sprint) commitment?
Derek Collison discusses the goals, the design premises and patterns employed in creating the architecture of Cloud Foundry, VMware’s open source PaaS, unveiling internal architectural details.
Andrew Watson talks about the work of the OMG, where CORBA is alive and well (hint: in your car), UML and UML Profiles vs. custom Modeling languages, DDS and other middleware, and much more.
Sohil Shah discusses creating iPhone and Android enterprise mobile applications based on cloud services using the open source platform OpenMobster.
Paul Sanford presents the transformations supported by data throughout its life cycle, and how that can be better done with Splunk, an engine for monitoring and analyzing machine-generated data.
A common “best practice” for unit tests is to only write a one assertion in each test. I intend to question this advice by showing that multiple assertions per test are both necessary and beneficial.
John Rauser presents the architectural and technological evolution of Amazon retail websites starting with 1994 and ending with adopting Amazon Web Services.
Michael Stal discusses system architecture quality, how to avoid architectural erosion, how to deal with refactoring, and design principles for architecture evolution.
Every developer has had to integrate with another system, API or component. Tis article provides strategies to handle the change and for he separating system boundaries.
3 comments
Watch Thread Reply