Recently, I was involved in a very exciting new project you might have heard about. I’m sure you will be interested… It all started when I was asked to manage the development of a new set of soft and hardware that was expected to be a useful complement to our current package.
This request was followed by a very funny brainstorming session about our company’s IT solutions, between me and my boss. Huh sorry, my partner (ok, do not tell her but she’s both.) Of course she’s the one who was destined to become the Product Owner of this wonderful adventure.
Anyways, I was asked to manage this wonderful adventure we tenderly named our “Baby 2.0” (yes, yes, I know it’s cute.) So I was the Project Manager and as such, I received strict instructions from my wonderful boss. That was some common constraints I remember as something like this: “Blah, blah, blah… Fixed date and fixed price development… Blah, blah, blah… Everything must be ready in about 40 weeks… Blah, blah, blah… The solution must fit our line of products, you must follow our graphical charter!”, etc.
Everything seemed to be known and controlled before we started any action. It was like the functional analysis was already produced, checked, validated and available for the development phase. But I am Scrum oriented you know (with several certifications, I cannot hide my interest for it) and it’s quite difficult to know the best way to do things and throw it in the garbage when the context is not ”open minded.”
So I told my boss that we couldn’t know everything in advance and that the work would emerge throughout the development because it was almost impossible to know everything about the solution we needed as our business was evolving every day. So I gave her some basics of Scrum and I was happy to convince her to adopt this wonderful framework to manage all the processes we needed. She was not aware of Agility or Scrum before that, but the methodology seemed to be as funny as the brainstorming was (I think it was, maybe I should ask her…)
So we decided to ”Scrum” this project! What a great idea, isn’t it ? But before thinking about applying Scrum to the development of our solution, we had to think more about the project itself, because our ideas were a bit blurry and all aspects were to be taken into account.
All we knew at this time was what we needed and when… So we defined some basic backlog items as the first big features of the solution and we talked about other aspects like usefulness, legal aspects, etc. After that, we were able to plan the complete first (and last) release. We were sure about the solution to implement, we had a time limitation and we knew exactly what we had to do. We finally had nine months to complete the project, so we planned a nine months release with nine sprints of one calendar month.
With these bases, we had a better idea of the adventure and could finally think about the Scrum Team (I must admit that in fact the team was ”built” a long time before the brainstorming and this project was just a great reason for me to apply Scrum outside an IT project.)
Thus, we needed a Product Owner, a Dev Team and finally, a Scrum Master. The Product Owner’s role had already been appointed to my partner as she knew all we had to know about the solution and her ideas were very clear about what she wanted to see in it (and you know, she is the leader, so…)
As the Product Owner knew a lot about the solution to be built, the best thing to do was to let her drive the boat (this is the PO’s role: driving the boat and giving the team the best opportunities to deliver high value increments.) So I let her drive the boat. After all, this adventure was a reality because of her. She had to find great developers, aware of the technologies we had to use and of the project’s subject. I just had to accompany her to make the best choices. Quite Interesting: she already had an amazing team (that she called “Her Crew”), ready to take the project in hand. We just had to find a Scrum Master.
The Scrum Master’s role was now to be given and a lot of things were on my side. First I was the Project Manager. Be careful, lots of people misunderstand the Scrum Master’s role and mistake it for a Project Manager’s role. Sometimes they do this also with the PO’s role. It’s totally wrong, but you can encounter that situation so often that you could think it’s right. Second, I was present at the brainstorming (in fact some kind of a kickoff party). Third, I also have several Scrum certifications! Damn, I deserve this Scrum Master position, don’t you think ? Well, that is what I thought but, you know, sometimes things do no go as you would like. I really thought I was destined to be the Scrum Master and I chose to embrace this role but then, I met the obstetrician!
Yes, may be it was not yet completely clear for you but our goal was to build a real Baby 2.0, an addition to our hard and software package Family, designed to be upgraded more than once. And the customer was eager to get a new update, and sometimes, even when you have a great company with great employees, sometimes you have to turn to experts and hire consultants. It’s what we did… (also because in that case, it is mandatory to take one on, unless you are an obstetrician yourself).
She was great! She ensured that the Daily Meetings were held. Each month, she was there to assist us with the Sprint review (you know, this event where you can see the progress and the work carried out), holding our hands while the team was presenting the solution with the last increment, helping us in facitilating the event (in our case, the echography revealed the increments and the state of the whole project. That’s pretty cool, you can see almost everything.)
She helped us with the Sprint Retrospective and she was there to help the Product Owner and the Dev Team to walk through impediments (”Dear expectant mother, you took too much weight this month, let’s try some of these ideas to prevent this problem from happening again”), helping us understand the processes running through the complete release.
I was just left aside with only one thing to do: wait for the last delivery (because each sprint was quite good in quality and we never added back any item to the backlog.) As you can see, my role in the project was extremely important! I thought I was there to give all my knowledge about processes, project management and of course, Scrum, but actually, I was just… a stakeholder!
Despite that, it was a great project, a great adventure with great moments, lived with a lot of pleasure and fun and… truly exceptional. We even completed the project in advance!!! Can you say the same with your waterfall projects?
The most important thing to remember in this story is that while one feels that one possesses all the knowledge required, it is important to know what place one should occupy. You can naturally use your knowledge and share it with those who want it, but everything has its place and it is extremely important to let the teams work to get the best of themselves.