Scrum in a Non-Scrum environment

Well for a change let me start by asking few questions

Are the words “Agile”, “embrace change”, “scrum”, “sprints” new to you or recently been added to your world ? Are you into software development ? 

If the answer to the above questions are “Yes”, then I believe you are at the right spot. 

“Agile” is a software development methodology. There are various ways to be agile, one of them is “Scrum”. I must say that its engaging and I feel its beautifully crafted by its creators.

Scrum is an iterative process and these iterations are called “sprints” which can be of maximum 4 weeks, the output of each sprint is a “done” product increment i.e. a potentially shippable product increment. At the end of each sprint a sprint review meeting is held, the aim of this meeting is to review the progress “done” during the last sprint and gather feedback on the work done.

Today we are going to discuss a scenario where the Product Owner(PO) wants your team to work on a particular user story even though the dependent components are not ready. It is possible that you land up in this situation if the story has a higher business/risk value. If you are stuck in such a scenario then here’s a way to get out this clean and in style.

For the component which is being built using waterfall methodology

• Adjust the Definition of Done(DoD) for the user story to exclude the live integration of component.
• Get an agreement on a data contract or API from the dependent component team before proceeding development on your side.
• Once agreed, create a stub for the component and plug the stub in your product.
• Create a new item for integration of the component in product backlog for the same story and with original acceptance test.
• Prioritize this new item once the dependent component is available for integration.

What do you achieve by this ?

• Progressed on your product by building stub.
• Built a plug and play architecture
• Demonstrated progress to the product owner and client.
• Your sprints are running relatively independent of the surrounding environment.

For the component which is being built using scrum

• Scrum of Scrums should be able to help you align the product deliverable.
• If you are unable to push the required components priority higher up in your dependent teams backlog list then you can follow the similar process of creating stub as that described earlier.

What do you achieve by this ?

• Using Scrum of Scrums you should be able to track the development of your dependent component.
• You can push the required components priority higher in the dependent teams product backlog item.
• You can synchronize your deliverable and may not even need to create stubs.

In both scenarios remember, integrate with the your dependent components as early as possible.

In organizations who are accustomed to waterfall model, words like “agile” ,”scrum”, “lean” etc act like buzz words and pretty soon you would see that everyone wants to be agile, everyone wants to only talk about agile and everyone’s already started claiming that they are agile. So be prepared for above scenarios and yes embrace the changes. It’s simple and it’s good.

References

What is Scrum?

Whats Next ?

Sprint Retrospectives – a real story.