agile-nearshoring

AgileEE 2011 Lightening Talk – Definition of Ready available

Felix Ruessel — Mon, 26 Sep 2011 16:19:23 +0000

Last week we have been at the AgileEE 2011 conference in Kiev. There we met a lot of interesting people and had a great time learning new concepts, having a lot of interesting discussions.

On Saturday I gave a short lightening talk about "Definition of READY". I didn't like my performance on the stage but I got some positive feedback from Oleksiy Rezchykov in his blog post where he recommends my lightening talk. Another article with positive feedback to the Lightening Talk can be found at ConfRadar:

Felix Russel did a good job reminding about the "definition of ready" and the time each product owner should spend on preparing stories before the team can actually swarm around them. It was one of the lighting talks during the second day, that I attended.

The slides are available via Slideshare:

AgileEE 2011: My Lightening Talk about "Definiton of READY"

View more presentations from Felix Ruessel

AgileEE 2011: Giving a Lightening Talk about READY

Felix Ruessel — Fri, 02 Sep 2011 13:54:12 +0000

My proposal for a lightening talk @ Agile Eastern Europe in Kiev has been accepted!

I will give a short version of my presentation about "Definition of READY". For more information see the list of lightening talks.

See you in Kiev @ Agile Easter Europe 2011!

Meet us at: Agile Eastern Europe 2011 in Kiev

Felix Ruessel — Thu, 18 Aug 2011 16:18:54 +0000

As written before we are attending several very interesting events in September. I already stated that September is for training and networking only. That is one reason why we are not engaged in huge projects during September. We are simply traveling around all the time.

One event I am looking forward since last year is clearly the conference "Agile Easter Europe 2011" in Kiev. We have been there last year and I enjoyed this conference like no other before. So my expectations are set high. Just have a look at the conference web site and check out for yourself if the AgileEE2011 is worth a journey to Kiev.

This year Alistair Cockburn will give one of the key notes and there is a long list of other very interesting sessions.

Meet us at: Agile By Example 2011 in Warsaw

Felix Ruessel — Thu, 18 Aug 2011 15:56:35 +0000

In September we will attend several very interesting conferences.

The first conference we will attend is "Agile by Example 2011” which is a completely new conference help September 15-16th in Warsaw / Poland.

The conference has a lot of interesting speakers and aims to become one of the large international Agile events in Eastern Europe.

I am happy to meet you there in Warsaw!

Presentation: “Definition of Ready–when are we able to start?”

Felix Ruessel — Sun, 12 Jun 2011 08:34:21 +0000

At the moment I am working as Scrum Coach / Interim Scrum Master in a company located at the Lake of Constance. Three weeks ago I attended the Agile Breakfast in Constance the first time.

At the next Agile Breakfast I will give a presentation on “Definition of Ready – wann kann’s endlich losgehen?” (“.. – when are we able to start?”). Most people using Scrum do know the “Definition of Done” (DoD) very well while they are unfamiliar with the “Definition of Ready” (DoR). This is due to a lot of reasons and in complex organizational environments the DoR has a huge potential for conflict.

In my presentation I will explain the motivation behind the DoR and discuss the positive effects and the potential problems you may encounter when you try to establish a DoR in your organization.

The next Agile Breakfast in Constance will be at 5th of July in the Water Tower Stromeyersdorf/Constance . The Agile Breakfast is organized by the Scrum User Group Lake Constance (SUGLC). The company Sybit is sponsoring this event.

Registration

You need to register (space is limited). The event is free of charge.

AgileDays Moscow, Agile Riga Day

Felix Ruessel — Sat, 29 Jan 2011 08:51:46 +0000

The Agile Eastern Europe 2010 conference was a huge success and we enjoyed the days in Kiev / Ukraine.

The agile community in eastern Europe is very active and there are two interesting events taking place in March: Agile Riga Day and Agile Days (Moscow).

Agile Riga Day

Riga, Latvia
http://www.agilerigaday.lv/home
Twitter: #agilerigaday
2011, March 5th

There are several interesting talks (see program for the details):

Joakim Sundén - Flow where you can, pull where you must - a practitioners guide to Kanban.
Vasco Duarte - Patterns of Agility. How to recognize an Agile project when you see one.
Ola Ellnestam - Fast feedback teams
Girt Ivans - The Core of Scrum - Creating healthy, thriving work environment.
Elina Jakubaneca & Armands Baranovskis - How to succeed with Agile.
Anton Keks - Being a professional agile developer.

Agile Days (Moscow)

Moscow, Russia
http://www.agiledays.ru/
Twitter: #agiledays
2011, March 4th-5th

Attention! It looks like that this conference is all Russian. So it might be difficult for you to attend without speaking Russian

AgileDays - a place of exchange of experiences for those who have long and successfully uses Agile. In addition, a series of reports will focus on the most recent and most interesting trends , such as Lean Development, DDD, BDD, TDD, FDD and other xDD. The conference will be attended by Western guru.

Guess they are referring to Henrik Kniberg as this “western guru”

Fixed-Price Projects and Scrum

Felix Ruessel — Sun, 28 Nov 2010 18:06:03 +0000

Time and time again people discuss whether or how Scrum fits into projects with fixed-price contracts. Within those discussions, fixed- price models are considered to be very difficult. However, in many areas fixed-price projects are standard and this will likely not change in the near future, despite the many disadvantages of this type of contract. Since my field is also dominated by fixed-price projects, here are some thoughts on the subject.

Fixed-Price Projects – Price is not the only thing that is fixed

In a fixed-price project, all essential parameters are set:

The offer specifies the price, there are no variables
The specification defines features and scope
Delivery dates are fixed in most cases and penalties for missed deadlines are intended to encourage on-time delivery
Concerning quality, the phrase “ according to current technical standards” is often referenced; a phrase that provides enough ammunition for lawyers

At first glance, a fixed-price contract gives the impression of providing a secure basis for a project. Problems, however, lie in the details.

Typical Challenges with Fixed-Price Projects

Examples of typical challenges with fixed-price projects are as follows:

Price is often driven by competition. Estimates of development departments are being revised downwards, risk is not appropriately factored in. Sales are often measured by turnover of transactions rather than if promised results can be delivered.
Requirements and specifications are generally neither sufficiently accurate nor error free. Even if it were so, specifications written before the first real phase of the project would never truly meet the needs of the customer. And these change constantly.
Generally one only has limited options to work closely with (potential) clients when bidding on fixed-price projects. There is also a considerable investment (of time) that only pays off if an offer is attractive enough to be awarded the contract for a project. “Attractive” here is often defined by cost.
Deadlines are often set by wishful thinking. Possible risks are being ignored here also.
Quality standards are not agreed upon and all parties involved have different perceptions on how quality is defined.

In his article, Roy Morien writes a crucial sentence (quote) that is probably said by fixed-price project clients at some point or another:

Oh, but surely you understood that {some feature or process} is part of what we asked for.

In many cases the client was not aware at the time of awarding the contract that function and process are part of the scope. Otherwise he would have had to have stated this after receiving specification. Generally the customer cannot be exempt from involvement.

Procedures for Proposals and Execution

Generally, there are two ways to deal with challenges regarding fixed-price projects:

For lesser challenges, “buffers” are used to avoid unnecessary friction through negotiation of change requests. A method that is not truly recommendable, since the buffer can generally be used in other positions and as a result, trust can be broken.
Commonly, change requests must already be discussed shortly after start of a project. Change requests tend to have an impact on project budget and deadlines. Sometimes functions can be successfully exchanged, this means to adjust the scope of the project.

Success Factors

Deciding factors for fixed-price projects are often things like

Openness and Trust: Are contractor and client communicating openly and is there a basic trust between both parties?
General Agreement and Purchasing: Is the general agreement fair or is one party at a disadvantage? When or how should the purchasing department/project management be involved? What policies and procedures exist?
Comprehension: Are change requests understood by both parties? Are costs understood?
Change Management: Were provisions for dealing with change request outlined during contract negotiations?
Flexibility: Is the client holding back part of the budget for the project in order to be able to promptly pay for change requests? Is he flexible enough to change requirements?
Capacity: Does the contractor have the capacity and ability to implement desired changes in a timely fashion?

There are a variety of opinions from the agile community

The topic of fixed-price projects has always triggered different reactions. Discussions are even more intense in the agile community. Scott Ambler, for example, considers fixed-price projects fundamentally unethical:

Fixed price work is unethical. As wannabe professionals we need to stand up to the bureaucratic treadmill.

Peter Stevens gave a key note speech on the subject of fixed-price projects and scrum at the Italian Agile Day. You can read a brief summary about different types of contracts –incl. fixed price- here. Simon Baker already wrote about fixed-price projects a long time ago:

To say how much something will cost, you need to know in great detail exactly what needs to be built so that your estimates for the work can be accurate. But you can't define everything you want, in detail and up front, and get it exactly right so there will be no changes in the future. And no estimate is ever accurate (it wouldn't be an estimate if it was). […] Don't base the contract with your vendor on conformance to a detailed requirements specification. If you do, you're saying all your good ideas happen at the start of a project and you're effectively betting all your money on a hole-in-one

In response, one of his readers discusses his experience with a fixed-price project:

[…] fixed price contract where the client and contractor fought endlessly over what was included in the price I endorse everything said above. Unless you are exceptionally lucky your fixed price contract will be toxic to the client supplier relationship.

Paul Klipp explains in his article why fixed-price projects are also bad for the client: Why Fixed Bids Are Bad for Clients (Scrum Alliance). An older article (German) on Armerkater.de gives an overview various forms of contracts in agile organizations.

Conclusion

My conclusion on fixed-price projects is that it is still a very popular type of contract in the industry and it is associated with many challenges. The reason for this is that it is looks like a safe deal for client at the first glimpse. You can react well and flexibly to changes, even with fixed-price projects – if client and contractor approach this subject openly and are interested in a win-win-situation. However, if there is no basic trust, it can quickly turn into a lose-lose-situation: At best, the client will get what he has specified – not what he really needs. A provider that, at first, seemed to be inexpensive can turn out to be comparatively expensive when it comes to change requests. For providers fixed-price projects are always a major challenge, especially if a large profit margin or a large safety buffer cannot be factored in. Normally a fixed-price projects must be always sold more expensively than projects with a times and material contract as for such contracts risk provisions, bargaining chips, buffers and additional transaction and analytical costs don’t play a role.