Are you throwing out the “Kabob Content” with the skewer?
This is what’s happening in our product development industry many times today when it comes to the agile philosophy.
So what do I mean by that?
We have had this traditional way of developing our products. We have called 
it the waterfall process. At this point, it is interesting to note that the gentleman who founded the whole waterfall philosophy was Winston Royce way back in 1974. Four years later in 1978 Winston Royce wrote a follow-up paper in which he stated, “this linear methodology does NOT work. And he emphasized this point here, “It does not work, especially for large projects.”
Now that is interesting since we continue to use it, and have used it ever since 1974. And we have used it even when the founder/developer says it does not work. And, yes, we have experienced failure after failure because of it. Currently what I find very interesting is that since we are now experiencing success with what we call, “Agile”, we are throwing out everything and anything that we did that was attached to the waterfall philosophy. We are throwing out the “Kabob”, the “meat and vegetables”, with the skewer.
Yes, the skewer does hold it all together as does the waterfall methodology. However, the end result of the “meat and vegetables” are the items that are important. In my agile experience, I find organizations are throwing out everything they did when they used the waterfall process. Let me give you one example.
In organizations that have used and are still currently using the waterfall process, we find that many of them strictly enforce the project management life cycle as it is defined by the Project Management Institute. One of the things that this life cycle enforces is that when you start your project, you always put together a Project Charter or Statement of Work, the S.O.W.
Let me major on that project Charter here. In a recent discussion with a large corporation who has been attempting to have their Information Technology division move towards the agile philosophy, they find that they are having limited success. At a recent agile open conference, as we sat in a group discussion, the CIO indicated that the few teams that have started with the framework of Scrum are not achieving the objectives of the systems that they are developing. He asked for input from the discussion group as to where they might improve what they were doing.
My question during the discussion was “does the team know its direction?” From my experience, if the team knows their endpoint, they should have no problem in adapting to and achieving the direction that the stakeholders have determined for the product. I, therefore, asked this gentleman the question, “Was the Project Charter put together or developed in a collaborative way with the entire team and the project sponsor?” He looked a little shocked at that and said, “wait a minute we are agile not waterfall. We always did the project Charter in the waterfall process but since we are now at agile we no longer do it. We don’t do anything that we did when we were using a waterfall methodology.” I then followed with this question to him, “How the heck does your team know it’s North Star”? In other words, do they really know the direction they’re going? What is the project vision? What is the mission of the team to achieve the vision? What are the goals and objectives to achieve the mission? Does the team know what is in scope and out of scope? What are they going to do to achieve this vision? And so forth. All he could do is look at me with a blank expression. And then finally say, “I see what you mean”.
Something that I have put in place for every project that I have advised, trained, and coached, and as well led as a Scrum Master, is that we never begin without going through, and producing an Agile Project Charter. This is done collaboratively with the team and the project sponsor, and any key individuals that are needed for product direction. You might say “This will take a long time.” No, it never takes us more than two days. And we have at that point a document of no more than 2 – 4 pages that is the road-map for the team. It is priceless and we keep it in front of the team every Sprint.
However, with that said, it is agile. By that I mean we can inspect and adapt our project Charter as well. However, I’ve never had a situation where the project Vision has changed but we find in many cases the scope will obviously change. That is for all intents and purposes what Agile is all about. Within this document, we have a section labeled the “Team Social Contract.” This is where all the “rules and guidelines” are set by the team and for the team. It is then agreed to and committed to by the team. This is amazing from the perspective that right from the get-go, the team is committed to the framework. They as a collaborative team have committed to it and will keep each other accountable for following it.
I can speak a lot more about this document and I will do so in another more in-depth blog shortly. But, always keep in mind that your project must have a “Northstar”, a navigation focus, and that “Northstar” must be aligned with the organization’s “North Star”. Then you will have success.
We are agile.
Author: Ed Rubuliak
Web Site: https://agile.mymasteryacademy.com
email: ed.the.scrum,professor@gmail.com
Facebook Group: https://www.facebook.com/Agile-Software-Development-482874298764658/
