Tackling Scrum Agile for the First Time: A BrightWork Approach
If you know Scrum Agile, you may be thinking about introducing this methodology to your projects. To help you get started, I’ll share some experiences and tips following our application of the methodology in 2016.
The Need for Change
Our team is responsible for developing custom business solutions internally for BrightWork. We have delivered many successful projects over the years without the help of Scrum Agile, so let me start by saying only change your formula if you feel it is going to bring about a real positive change. Giving Scrum Agile a run made sense for us and we felt it was the right fit for some of our development programs.
Only change your formula if you feel it is going to bring about a real positive change
We wanted a change because we felt more traditional methods of project management were missing a certain versatility. We would begin with a requirement, kick off our development, and come back to the table sometime later with a release candidate. We felt we were failing to get adequate feedback from the product owners along the journey but more significantly, the solution we were building never had a chance to adapt to change until after the development cycle was complete.
Depending on how long the cycle was, it nearly always felt too much time was spent on the original requirements, without an opportunity to adjust to an ever-evolving business.
The beginning is the most difficult part but such is any change
Our first impressions were a mixed bag. “Gee that’s a lot of meetings,” I’d say to myself referring to the Agile ceremonies. I was also worried about adding layers of unnecessary process and losing our ability to “just get things done”. I think, in a way, the largest part of approaching Scrum Agile was communicating the change.
Sometimes I felt like I was pushing a bill through congress. I had to meet the business sponsors and managers, get product owners assigned, train everyone on the methodology and then at the end, work in a completely different way to deliver our solutions. The beginning is the most difficult part but such is any change.
When we began, we did lots of research on the methodology. We still ended up implementing parts of it wrong or interpreting certain pieces differently than their intended purpose. You are probably never going to take on a new approach exactly the same way that best practice book you bought says.
After all, your business is unique and how you have been working (successfully) until now is unique. I always say, “common sense should prevail”. Do not be afraid to get it a little wrong but mostly right when you first implement.
I think the most iconic flaw in our early adoption was that we really did not understand the differences between the scrum master and the product owner. We thought we did and that was the most important thing. Our scrum master was acting more like a project manager who was trying to, in part, define what was going into the sprint alongside the product owner. This made for interesting meetings.
I now think of the Scrum Master as a coach. Someone never on the field of play, but instead gives advice at halftime and throughout the game so that all the players understand their plays.
Success and Benefits
One of best benefits I feel is the confidence the approach brings to solving the unknowns in software development
I think we looked back positively on our first successful project using Scrum Agile. One of the key benefits of our implementation is that we now have multiple backlogs of work, all ranked and estimated. We can see the wood from the trees. One of the best benefits I feel is the confidence the approach brings to solving the unknowns in software development. As you have such short cycles, the technical unknowns in the project do not have the same potential to reshape the project or allow it to balloon out of control.
For instance, developers share their decisions and approaches to problems at the delivery meeting. Everyone knows what it means and we discuss any technical limitations that might affect us in the future. This is where I think the Agile ceremonies act as a safety line. In models that are more traditional, the technical decisions made do not get to the customer until months later. Suddenly there is a big problem that requires open-heart surgery to resolve.
Scrum Agile puts the customer and the development team in the trenches together and this is key.
Tips for Implementing Scrum Agile
One thing that has stuck with me, which I think is important for anyone to understand that wants to introduce Agile within his or her organization. Agile methodologies cannot be just something that a small team introduces and that becomes that.
For Agile methodologies to work, a cultural shift is needed within your business or organization. It will require change and understanding at the top, in the middle, and at the bottom. Work with your product sponsors and owners firsts. Convince them, and it will be a much smoother way of working this change in. Otherwise, I think you will end up deploying some type of Hybrid and this is not a nice way to begin.
For Agile methodologies to work, a cultural shift is needed within your business or organization
If you are beginning your journey into Scrum Agile, here are a couple of resources that may help you. We started with “Scrum and XP from the Trenches” book by Henrik Kniberg. This is a super book to get you kicked off with all the right approaches. This short video is a “must watch” for all product owners and scrum teams. Again delivered by Henrik Kniberg.
I hope some of this helps support your decision process as to whether or not Scrum Agile is the right approach for you. We may do a number of blogs around this topic but comment below and let me know what you might like me to go into more.