In this short article I'll try to share some tips and tricks how in particular Scrum Framework can help you to manage your projects more effectively.
To start with, Scrum by definition is a framework to address complex problems and is widely used in product context. There is a role called Product Owner, things you will do about the product is kept as a Product Backlog and so on. So, can Scrum be used in project context and would that be fine ? Please note, I am neither here suggesting to take a project approach instead of a product approach, nor I will be discussing the differences between the two.
Right or wrong, some organisations build their business model on top of delivering projects to their customers. They are paid when the deliver the agreed upfront scope to the customer within a defined budget and/or timeline. Likewise some organisations manage all their internal initiatives as projects . Organisations might take different approaches when managing projects. I've been an Agile consultant for quite a long time now and when I see an opportunity for an organisation replace their project approach with product approach, I always share my perspective. However moving to a product mindset is not always easy and might require organisational change along with other changes (contract management is a good candidate for instance) too. The organisations I've been helping so far think Scrum is a framework(in fact a method) that can help them to manage their projects more effectively. Although I explain them Scrum is much more than this, it is also true that Scrum can help you to increase your Agility in project context. How ?
Product Backlog Management
Projects tend to have a fixed scope, so think about whether the scope can be agreed on at goal level. Rather than focusing on the features, focusing on the needs, users and define a goal based list could be a good start to be able to flex the scope. Besides, can the scope be negotiated during the project execution ? How can this be incorporated to the contract ? Some organisations craft their contracts which allow them to replace features with the same size features as long as the work hasn't started on the "to be replaced" features yet.
Accountabilities
Scrum defines 3 distinct accountabilities.
In a nutshell , Product Owner(PO) who is accountable for the "Why" and What" we are building. She does this by keeping a transparent live Product Backlog(PBL). PBL replaces project scope document. (I am not going to go through how to effectively keep/manage a PBL in this blog). PO also primarily focuses on stakeholder management to identify and verify the customers needs.
Scrum Master who is accountable for the effectiveness of the Scrum team(your project team in this instance). How does she do that ? By removing obstacles, facilitating the decisions, creating transparency, helping the team to adopt Agile principles, values and so on.
Developers who works on delivering certain aspect of the product. They deliver stuff complying with certain standarts in Scrum such as Definition of Done.
So in short, can these roles be adopted in project organisations? The short answer is yes. These three accountabilities are what you would need to deliver a successful project (however you define the success). Do you really need any other roles in projects ?
Feedback Loops/Events in Scrum
Scrum has predefines feedback loops all of which are contained in a time-box called Sprint which is a maximum duration of 1 month. All Scrum events can easily be adapted in projects. Sprints will increase the transparency of the progress and will accommodate all inspect/adapts. While Sprint planning allows shorter planning cycles, Sprint reviews will provide transparency to stakeholders and allow them to give feedback earlier. While Daily Scrums will allow the developers to synch and plan their days towards Sprint goal, Sprint retrospectives will enable the whole Scrum team to run a more frequent lessons learnt hence allow the team to inspect their processes for the ongoing project rather than the future projects.
Empiricism
Scrum is built on empirical process control model which is based on frequent inspection and adaptation. What needs to be inspected and adapted in projects ? Just some questions you may wonder:
Are we really on track with our plan (scope, time, budget). If not what can be done ? Can we have an empirical/adaptive planning instead ?How would our customers benefit from that ? What would we lose ?
Do our customers/users still need these features ? How can I make sure whether they need them or not ?
How can I accommodate the new customer needs and requests with a win-win situation without spending too much time on the change management?
How can I change my ineffective processes fast without being stuck with them long time ?
Empiricims requires a behavioural/mindset change too and in Scrum that is supported mainly by adopting Scrum Values (openness, courage, respect, commitment, focus). These values creates trust which is a fundamental component to have for empirical mindset/approach. Can this be adopoted by project teams ? Absolutely yes, might be harder to achieve but is well worth the effort.
Summary
In this short article I tried to explain how Scrum can be exploited in projects. Using Scrum will not only help you to manage your projects more effectively but will also change your perspective how to approach projects. By using Scrum effectively you will eliminate most of your waste comparing traditional project management methods.
Hope this inspires people dealing with projects. Maybe this could also be a good step towards migrating to a product mindset where the main focus would be the customer/user value rather than scope/time/budget :)
Adopting Scrum at project level could also be an option for organisations willing to experiment Scrum before scaling it.