Agile SOW
Software projects are becoming increasingly complex. This complexity demands Agility. Agility translates to faster product increments, shorter review cycles, end-to-end picture of the product which essentially means incremental and iterative delivery. Quality needs to be built in. End user and customer engagement (via the PO) is indispensable for both building the “right product” and the “product right”. While the IT operations are going through a paradigm shift towards Agile, has the documentations such as SOW changed to cater the needs of Agile world? What is an SOW? Statement of Work (SOW) is a legal binding contract between an Organization and a contingent worker or a vendor that dictates the directions of how the work will be done. So, for Agile projects, the less you write, the better off you are. Remember, the mantra is: “Less is more”. Having said that, an SOW for an incrementally-delivered project should consider the following facts when drafting one. Including a Release plan in SOW The SOW can include a statement that as the teams start working, they will put together a release plan to provide an insight on how the timelines look at this time. A note in bold must indicate that this is how it looks at the very beginning and that this release plan will be updated after every sprint and the updates will be made available to all stakeholders. The release plan should try to cover the below facts: Initially the big blocks of work lower in the backlog will be Tshirt sized and the teams may want to have a rough mapping of Tshirt sizes to get an arbitrary value of story point. Alternatively, affinity sizing can be used to quickly and roughly estimate a large initial backlog so the teams have some numbers to refer to as they take strides into sprints. With time, as the product emerges and evolves, the PO and stakeholders get better sense of the timelines with updated release plan which has estimates with higher accuracy The team velocity is an important factor for creating the release plan. Prediction of team velocity is possible after first few sprints. A team’s velocity is not same as any other team’s due to various factors like experience, number of members in team, complexity of product, the technology they are working on, their style of estimation, etc. Velocity plays an important role in Agile release planning. Proper coaching by a servant leader Scrum Master is highly essential for a Scrum team to estimate consistently, plan and commit to correct capacity and then deliver to its commitment. This brings up a stable velocity and predictability which in turn provides confidence to the PO and stakeholders and they look forward to the updated Agile release plan at the end of every sprint. Servant leader Project managers and Scrum Masters must include only the details in SOW that are of Agile nature. There should be no pressure from the leadership to include details that SMs/PMs do not feel confident about. This way the Servant leader SMs won’t be held hostage by not accomplishing timelines and scope they did not think could realistically be included in an Agile SOW. The behavior of the leadership in such companies that want to really adopt a more Agile way of working should be transparent and oriented towards creating a culture where their actions are in sync with their desire to be Agile Let your SOW be versioned and wait for the signatures till an agreed upon Agile SOW is in place. The first version of the SOW should be light. A small handful of sentences should suffice. If you do get push back, review your options, some of which could be: Amitabh (Amit) Sinha is a servant leader entrepreneur, visionary, mentor, trainer and coach. Amit is highly passionate about Agile, its principles, values, and the human side. Amit is a people champion and strives to bring out the best in his teams. Amit leverages his expertise in Agile, Scrum, Kanban and people skills to increase team effectiveness and happiness. See more