It’s been a while since my last post. With Q1 almost over, it was long overdue to have a new post out the door by now. I originally started this post at the end of 2014, but finally I was able to make the space to complete it and finally publish it.

2014 was a really interesting and enlightening year for my product management career. It marked the year that I got fully exposed to the rollout of Scrum at the organization that I currently work on, we started from scratch and now, a year later I realize how much progress we’ve made and how much it has helped me and my team to define good practices and processes on how we built software.

##Why did we chose Scrum? After going through a tortuous project of re-architecting some of the major building blocks from our Platform, we touched bottom. Many things factored-in to make the perfect storm which had a big impact on the team’s morale and left us with many things that needed to be fixed at the end because the ask was too big.

One of my colleagues and good friend had prior experience with Scrum, he became the internal champion of Scrum and soon after our first scrum master. He made sure that not just the team and management were on board with the idea, but also, he made sure that we didn’t take the “easy” and short way of doing Scrum without the proper training.

Lesson No.1: Don’t take shortcuts, a lot of companies start with the wrong foot, yet by the time they realize, it’s already too late

By the time we had training, the team was familiar with some of the basics principles from Scrum and even have had some “Scrum but” sprints already. That in fact, helped us to make the most out of the training. But same as with the school, one thing is the theory and one thing is the practice…

Lesson No.2: Do the homework before defining processes, test the waters and take formal training. Come prepare and ask as many questions as possible

##What has happened a year later? In the same way that the whole process started organically, we as team started adapting Scrum to our organization, making all kinds of adjustments like: sprint duration, estimation, story points, how we run demos and retrospectives, definition of done, managing escalations…, and the list goes on and on.

Up until know we have what I consider a good practice that is the sum of all the different adjustments, some of which I mentioned above and that will always require to keep evolving.

The major aspects from our current Sprint process circle around the respect for the engineer’s time and the high cost associated with switching contexts. It puts a big responsibility on Product to make all the necessary due diligence required to define, scope and prioritize what goes into a Sprint. It’s build on transparency, knowledge sharing and keeping honest to ourselves acknowledging the areas of improvement and taking actions to correct what is going in the wrong direction and, excel those things that we are doing well so we can continue doing them.

Lesson No.3 There has to be a continuous improvement on processes and methods that lead to better results and higher team morale

##What are the major challenges

  • Releasing often and maintain momentum over features
  • On Product: Keep a healthy backlog and prioritize in the best possible way in an ocean of requirements (see this article:
  • Pruning the icebox
  • People over processes
  • Develop further the role of the scrum master
  • Releasing usable software
  • Identifying the ROI associated with features

##My list of Benefits from Scrum

  • Streamlined and organized product development cycle
  • Shared knowledge
  • Clear definition of roles,
  • Clear distinction of functions engineering vs product
  • Constant collaboration
  • Constant feedback recollection
  • The art of prioritization
  • Mastering JIRA
  • Easier communication with other parts from the organization
  • Getting things done
  • Move the needle forward.

Expect more shared opinions from the journey into the Product Management waters.