Helpful Lessons to Successfully Transition to Scrum
The agile adoption trend continues to gain momentum. Additionally, among all the agile methodologies, Scrum remains the most popular way for implementing agile.
Although companies use a plethora of tools and training methods to ease the transition to Scrum, they can potentially end up with something called ScrumBut, which is a hybrid of Scrum intertwined with the waterfall process. In the following video, Ken Schwaber talks about what it means to adopt ScrumBut:
To avoid adopting ScrumBut, organizations will be better served by kicking off the transition on the right note. This calls for some lessons before you jump on to the Scrum bandwagon.
First and foremost, remember that Scrum is a framework that allows you to implement your own concrete process. Scrum is very specific about its own protocols including, the three roles, three ceremonies, and four artifacts. Beyond the basics, it is up to you to adopt the tools and mechanics to give life to the process. As an example, you may choose automated tests or manual testing methods and still practice Scrum.
Many professionals consider Scrum lightweight because you don't have to create or maintain any documentation. Remember that the Agile Manifesto values “Working software over comprehensive documentation.” What this means is that you should avoid waste and create only the minimal documentation needed to achieve agility. Comprehensive handoffs with signatures are discouraged, unless required by law or other contractual obligations.
Also, remember that Scrum is not a mini waterfall. Design, development, and testing activities are to be performed constantly during an agile iteration, different from the waterfall method where they are performed sequentially. Agile demands a higher level of collaboration to produce smaller bits of working software. Replacing sequential activities with constant delivery is hard to achieve and will require patience and practice.
Additionally, Scrum does not get rid of the role of the architect. Scrum, like all agile methodologies, feeds on emergent design. This makes the role of the architect central to preserving the integrity of the architecture with respect to reusability, maintainability, performance, and security. The team is the collective owner of design, but the architect keeps all the ends tied together.
Lastly, Scrum scales perfectly for larger and distributed projects. For projects of all sizes, use feature teams to develop end-to-end functionality. Relying on component teams gives way to excessive written communication instead of face-to-face conversations, dependence on handouts, and uneven work in a sprint for downstream teams. You should only introduce component teams to the mix for building reusable new components or when the risk of multiple solutions being developed for the same problem is high.
If you think I left out something, please let me know in the comments below.
