Scrumban in a Nutshell (Part 1)

Scrumban is becoming  a buzzword, and if you ask me, for a reason. People like structure. We are cyclical creatures. We set goals, work on making them happen, and set up a new set of goals. We need a direction to go and a sense that we will get there. Who hasn't ever set up New Year resolutions? We are in the beginning of the February and my personal ones are fading already, but I still remember a nice feeling of setting them. How does this apply to Agile? - you will ask me. This is why I think it does.

Last week, my colleague Irina Miretskiy and I made a presentation at a New York Chapter of the Project Management Institute about our case study. The project we worked on started as a very traditional waterfall project. The goal of the project was to create a reporting system for a company which was in the process of changing its business model. Reporting functionality included application of multiple business rules to slice and dice and shape up the data to model how the business is structured. The complexity was that in the middle of transformation no one understood yet how the business would be functioning. Just one example: image student enrollment in a test prep class. As a Sales manager, you need to assign a sales credit to a sales rep who signed up a student (or as an alternative, you can roll up all sales for a physical test prep center and split the enrollment credits based on a set of specific rules). However, if you are switching to an online model and your classes are no longer associated with a physical center, how would you be able to track student enrollments back to the on-campus sales rep, an online ad, or a free test prep session that the student attended in college? In most cases, business rules are so complicated that they have to be re-engineered based on common sense.

This was exactly where the complexity of the project was. In slicing and dicing the data, in aggregating enrollment, sales, marketing data based by dozens of parameters and decision points, the team approached desired data accuracy one steps at a time on a thousand-step journey. Each step looked like "come up with the business rule" - "code, test, deploy" - "sweep back hundreds of thousand of records" - "check the data for selected records, apply common sense to figure out the ones that are wrong" - "come up with a new branch to the business logic" - "come up with the business rule" - and all the cycle all over again.

Guess now why waterfall did not work? After the initial cycle (this is when the project was supposed to get completed, according to the 7-page MS Project plan), the project was considered a failure and the team decided to work overtime to make it up. Guess what? After three cycles, the team was exhausted, business stakeholders frustrated, the project manager left the company, and more resources were thrown in to save it.  After three more iterations, accuracy of data increased but it was still not 100% and the resources started leaving the project - moving on to other projects. It was obvious that 100% was not possible with the complexity of data and the business model which supported flexibility of the new business model.

"Agile!" - you will say - and you will be right. As the team moved to Agile, flexibility no longer worked against us. With each iteration, we increased accuracy of data. Demos provided visibility to the business of the complexities and the incremental progress. The 100% dedicated team were able to show results and it no longer felt like a never ending journey. There were realistic goals set up to achieve the accuracy of data, agreed upon with the business, and the scope was split into measurable chunks that were delivered one by one within a matter of three months.

The step from waterfall to scrum was complete and the original scope was delivered, however, this was not the end of the journey. This was a living system in maintenance mode. New requests continued to come in, and our sprint planning was becoming hectic. Sometimes, we would not have enough tickets to estimate during our planning session, but with the high volume of incoming requests, the end of sprint became a struggle of business stakeholders: who will get in their ticket first? Kanhan "first come-first served" approach did not work as the priority of requests ranged from a business analyst researched options to company's senior management who needed this data to make decisions on running the business. The team was pulled in different directions, and sprint review sessions were surfacing misunderstanding and misalignment. Cadence was no longer there, but the spirit still stayed. And jointly we came up with a solution - scrumban!

More in Part II.