Search

Agile Contracts or Agile Statement of Work - Must-Haves

In IT with the Agile boom, everyone wants to get into Agile Development. Be it the customers, organizations, and even developers, everyone wants to get into Agile Development. Customers want to follow Agile so that they can get to see the Product early and the changes can be incorporated without any cost. In other words, they want fixed price, variable scope. But, organizations need to be cautious in order to define how much variable scope is included in contract clauses. Organizations want to keep themselves up-to-date and follow Western culture blindly. Statements like these often come “Everyone is going Agile, why aren’t we yet?” They have to understand, every environment, every team, and every client is different. We just cannot keep on copying everyone else. Developers, of course, will have “Agile” word in their resumes which will help them grow and find jobs.   The number of agile contracts [by govt] amounts to a coat of agile paint on a giant waterfall HT @RachelProsser https://t.co/IEOPRRFFM5 — (((Dave Moskovitz))) (@davemosk) October 9, 2017 So, in desperation, companies (small or medium organizations) ONLY follow what customers say. What they end up is – with an agreement that has clauses of Waterfall model and they tell clients that we will follow Agile. These clauses might be like having fixed scope or fixed price which will be given by end of phase like requirement gathering or planning or UAT done etc. But we forget, that in Agile, every iteration has these phases and we should be targeting the contract in such a manner that it is win-win for both the parties at end of every iteration. Below figure distinguishes between the Traditional Pyramid and Agile Pyramid. Traditional pyramid has fixed scope while Agile one has the Estimated scope, to be considered while negotiating the contract.   Lawyers and Sales team need to be taught that if we are following Agile, we need to follow the terms and conditions for Agile contracting and not of Waterfall.   #agile contracts, however, are not the silver bullet: few of them delivered the right client benefits. @WC_REFSQ pic.twitter.com/8MSb0okXQ7 — Samuel Fricker (@samuelfricker) March 15, 2016 Apart from including changes like, Product Backlog (instead of BRD), Key roles in Project, the Agile methodology, below are few MUST HAVES that should be mentioned clearly in the contracts and need to be communicated to the customers, during the contract negotiation: 1. Pricing Model: It is unrealistic to expect any development project or product, to be delivered on a Fixed price basis. We all know that there will ALWAYS be changes in scope which will affect the original price. If the customer has a fixed budget, this can be managed within an Agile project by focusing on the development of high-priority items first, allowing the Customer to remove low-priority items from scope. All such issues must be taken into account when negotiating the Pricing Model for the project. Below are a few potential pricing models: a. Fixed Price per user story – Be cautious here, too long user stories need to be broken up.  b. Fixed Price per iteration – Make sure that all iterations range to similar story points. Remember, we have to create win-win for both parties. c. Fixed Price for the agreed number of features – Describe the feature well in advance. d. Time & Material (our favorite) - Customer continues to pay during an agreed-upon time period. The customer pays till a point he sees value being added. In case he sees that no value is being added, the customer stops paying and the contract ends. 2.Spikes for high-risk elements: In case the project has specific, high risk elements, e.g. technical challenges or business issues that are absolutely first timers or have never been solved before, these MUST be communicated up-front. Such Programming spikes where we attack only the riskiest coding in the project must be included in the contract. These spikes give customers a realistic view of the project ahead for the least amount of money and avoid conditions of "Fast failure". The main goal here is to uncover any weaknesses in the proposed development and hence be ready with the new plan and strategy in order to make the project successful. 3. Define Scope, but no need to mention delivery items: Product backlog defined at the high level MUST be attached to the contract as one of the appendices. Though the scope is variable and will change during the course of the project, high-level scope must be included in the contract. Delivery Items will change post discussion with PO on every iteration, but the high-level scope remains the same. Emphasize on process rather than on dates and items. This will keep the team’s mindset collaborative. 4. Settle on Definition of Done at high level: While negotiating the contract, the “Definition of Done” should ideally be defined and attached as an appendix. The clauses for “Definition of Done” that needs to be included are: a. During every Sprint Planning, PO and the development team will review the “Definition of Done” for the items that are included in that particular Sprint. b. In case of disputes, there should be appropriate resolution techniques in place between the parties.   Concluding the article by revisiting one of the values of Agile Manifesto: Customer collaboration over contract negotiation. Contracts matter to those who have signed it. Customers do face problems and you will be able to see them only when you talk to them. Once you see and understand their problems for which they have hired you to provide the solution, you need to COLLABORATE with them and get to it. Despite all the clauses in the contract, the motto should be “LET’S DO IT !!”.  
Agile Contracts or Agile Statement of Work - Must-Haves
Nalini
Rated 4.5/5 based on 1 customer reviews
Nalini

Nalini Jethwani

Blog Author

Nalini is PMP, PMI-ACP, CSM practitioner and has 14+ years of experience working in Information technology sector. She has worked with companies like US Airways, HCL Technologies and Fiserv in various capacities. She started her career as a software engineer and progressed along the management path. She has worked in various domains like Education, Travel, Finance providing business solutions to various clientele across the globe. She has worked in Amsterdam, Japan and North America. She has been following Agile - Scrum, Kanban for almost 10 years now.

Posts by Nalini Jethwani

Agile Contracts or Agile Statement of Work - Must-Haves

In IT with the Agile boom, everyone wants to get into Agile Development. Be it the customers, organizations, and even developers, everyone wants to get into Agile Development. Customers want to follow Agile so that they can get to see the Product early and the changes can be incorporated without any cost. In other words, they want fixed price, variable scope. But, organizations need to be cautious in order to define how much variable scope is included in contract clauses. Organizations want to keep themselves up-to-date and follow Western culture blindly. Statements like these often come “Everyone is going Agile, why aren’t we yet?” They have to understand, every environment, every team, and every client is different. We just cannot keep on copying everyone else. Developers, of course, will have “Agile” word in their resumes which will help them grow and find jobs.   The number of agile contracts [by govt] amounts to a coat of agile paint on a giant waterfall HT @RachelProsser https://t.co/IEOPRRFFM5 — (((Dave Moskovitz))) (@davemosk) October 9, 2017 So, in desperation, companies (small or medium organizations) ONLY follow what customers say. What they end up is – with an agreement that has clauses of Waterfall model and they tell clients that we will follow Agile. These clauses might be like having fixed scope or fixed price which will be given by end of phase like requirement gathering or planning or UAT done etc. But we forget, that in Agile, every iteration has these phases and we should be targeting the contract in such a manner that it is win-win for both the parties at end of every iteration. Below figure distinguishes between the Traditional Pyramid and Agile Pyramid. Traditional pyramid has fixed scope while Agile one has the Estimated scope, to be considered while negotiating the contract.   Lawyers and Sales team need to be taught that if we are following Agile, we need to follow the terms and conditions for Agile contracting and not of Waterfall.   #agile contracts, however, are not the silver bullet: few of them delivered the right client benefits. @WC_REFSQ pic.twitter.com/8MSb0okXQ7 — Samuel Fricker (@samuelfricker) March 15, 2016 Apart from including changes like, Product Backlog (instead of BRD), Key roles in Project, the Agile methodology, below are few MUST HAVES that should be mentioned clearly in the contracts and need to be communicated to the customers, during the contract negotiation: 1. Pricing Model: It is unrealistic to expect any development project or product, to be delivered on a Fixed price basis. We all know that there will ALWAYS be changes in scope which will affect the original price. If the customer has a fixed budget, this can be managed within an Agile project by focusing on the development of high-priority items first, allowing the Customer to remove low-priority items from scope. All such issues must be taken into account when negotiating the Pricing Model for the project. Below are a few potential pricing models: a. Fixed Price per user story – Be cautious here, too long user stories need to be broken up.  b. Fixed Price per iteration – Make sure that all iterations range to similar story points. Remember, we have to create win-win for both parties. c. Fixed Price for the agreed number of features – Describe the feature well in advance. d. Time & Material (our favorite) - Customer continues to pay during an agreed-upon time period. The customer pays till a point he sees value being added. In case he sees that no value is being added, the customer stops paying and the contract ends. 2.Spikes for high-risk elements: In case the project has specific, high risk elements, e.g. technical challenges or business issues that are absolutely first timers or have never been solved before, these MUST be communicated up-front. Such Programming spikes where we attack only the riskiest coding in the project must be included in the contract. These spikes give customers a realistic view of the project ahead for the least amount of money and avoid conditions of "Fast failure". The main goal here is to uncover any weaknesses in the proposed development and hence be ready with the new plan and strategy in order to make the project successful. 3. Define Scope, but no need to mention delivery items: Product backlog defined at the high level MUST be attached to the contract as one of the appendices. Though the scope is variable and will change during the course of the project, high-level scope must be included in the contract. Delivery Items will change post discussion with PO on every iteration, but the high-level scope remains the same. Emphasize on process rather than on dates and items. This will keep the team’s mindset collaborative. 4. Settle on Definition of Done at high level: While negotiating the contract, the “Definition of Done” should ideally be defined and attached as an appendix. The clauses for “Definition of Done” that needs to be included are: a. During every Sprint Planning, PO and the development team will review the “Definition of Done” for the items that are included in that particular Sprint. b. In case of disputes, there should be appropriate resolution techniques in place between the parties.   Concluding the article by revisiting one of the values of Agile Manifesto: Customer collaboration over contract negotiation. Contracts matter to those who have signed it. Customers do face problems and you will be able to see them only when you talk to them. Once you see and understand their problems for which they have hired you to provide the solution, you need to COLLABORATE with them and get to it. Despite all the clauses in the contract, the motto should be “LET’S DO IT !!”.  
Rated 4.5/5 based on 1 customer reviews
Agile Contracts or Agile Statement of Work - Must-...

In IT with the Agile boom, everyone wants to get i... Read More

What Gaps I Filled After CSM Certification For my Scrum Project?

Sales department has always handled winning projects for your Company saying that we follow “Agile Methodology”. The whole organization is full of ‘Follow Agile’ noise. But are we really Agile and do we follow it appropriately?  I started following Scrum methodology (as per my understanding!!) way back in 2004, in one of the Products maintenance projects. I am quite sure, no one was aware what Scrum was all about, apart from following daily standups religiously at that time. But, after I did my CSM training from Knowledgehut, I learned that I am missing a lot of stuff and I am also doing few tasks incorrectly, which might result in a project failure. So, to avoid this catastrophe, I needed to act on it. Below is the list of few activities that I did immediately after my CSM training.     1.Trained my Team, Management, Client & Vendor on Scrum:  Generally, when a new project arrives, management wants us to start with a kick-off meeting and commence coding immediately. As per team, the project is ALWAYS underestimated and we tend to start with activities like planning, coding, module/tasks division etc. as soon as possible.  When we have to follow Agile / Scrum, I realized how important it is to train the team, manage the clients and vendors. A team should be able to understand that they are now self-organizing and self-directing team and no one is going to assign tasks to them. The PM has to take up Servant leader role, rather than assigning work or controlling the team. The organization management MUST be aware that Being Agile does not ONLY mean deliveries in every 2 weeks. The client should be aware of the Product Owner’s responsibility and how important it is to be available for planning, reviewing and retrospective meetings. The vendors should be aware how Sprint and Scrum works, to track delivery from their end.    2. Scheduled Product Backlog Grooming Meeting and followed consistently: Agile expects us to do just enough and JIT documentation, but Product Backlog is a very crucial document for the project and it has to be updated regularly by the Product Owner (PO). PO has to update Product Backlog based on the market requirements or importance of releases. Unlike BRD, this is the ONLY document that is used by the team for forming user stories, estimating, planning sprints & finally coding, testing and then releasing. If PO is not aware of how to go about it, the Scrum master can help. So, make sure that the BASE document is updated regularly.  3. Scrum Master (SM) is a Servant Leader and not a Manager anymore:  Myself being the PM for almost 10 years, it was difficult to get into servant leader role, but we have to wear servant leader’s hat. Rather than controlling or just delegating the work, I realized, now I have to WORK with the team and for the team. SM is helping the team to get out from bottlenecks, SM is keeping the team together, keeping them motivated throughout the project.   4. Regularly update THE BOARD: There is a need to post daily standups, whereas we were too lazy to update the latest information on the whiteboard. The team has to update the board immediately after daily standup and the SM has to facilitate that. Post review or retrospectives, we started creating Burndown charts, latest review comments and some motivational notes. With this, I noticed an unbelievable change in the mindset of the team and management. It kept the environment light, motivated and the team started performing more.   5. Not conducting Retrospectives:  Before CSM training, I was just aware that there is a meeting that has to be done called as Retrospectives. With CSM training, I came to know how this meeting has to be conducted, when and who are the audience and what should be the agenda of the meeting. Now I understand, this meeting is MOST important for the team to improve the process, avoid mistakes that we did in past iterations. With Traditional Project management, we always have “Lessons Learned” during closure of the project. Have you ever read those lessons when starting the new project? Well, I never did. But with the Retrospective meeting, my team and I came into a habit of applying learning lessons immediately.      6. Elaborating as late as possible: Sprint Planning meeting results in Sprint backlog and we elaborate only those items that are there in the current sprint. Other items in Product Backlog are not detailed enough to start with coding. This actually helped us save time and reduce requirement gathering time in initial stages of the project even when requirements are not clear enough. So, as project proceeds, we gather more information and this helps us in elaborating other requirements too.   7. Making Product Owner aware of responsibilities: For me, the toughest job was to make my client aware of the POs responsibilities. We all know how important clients are for the companies. The customer is the KING of the world. Somehow, I convinced management that I need to make PO or BA from client site aware of the responsibilities. Client duty is just not to see how the product looks like and escalate things to management, but the client has to be aware of how you have to state your requirements correct, review the understanding and suggest rather than escalate things out. Clients escape saying they don’t have time for a review/demo, retrospectives etc., it is the duty of the Scrum Master to make them and management aware how important it is to be present for events. Else, in the end, it’s only the team who is blamed when the project is not a success. I hope, these few insights or my lessons learned will help you in some way or the other. Hoping to see the “Agile world” soon where practices are followed religiously.
Rated 4.0/5 based on 1 customer reviews
What Gaps I Filled After CSM Certification For my ...

Sales department has always handled winning projec... Read More