Scrum upside down
·Disclaimer: I’m not against SCRUM in any way and the following lines are only my concerns about the fact that some people think SCRUM is going to solve all the software development management issues. Like any other tool adopting SCRUM to a broken organization or IT department will only makes things worse!
This is just a short story about one of my experiences with SCRUM long time ago. This is just my thoughts about Scrum and how I think we should approach large projects.
Introduction:
I been using SCRUM and working in that kind of environment for 3-4 years, I liked it a lot, I’m currently working in such environment as well, but when I look back into those past few years I realize that success of Scrum, relies on the fact that the organization is finely tuned and successful by itself. I’m saying that because even without using SCRUM that organizations could potentially deliver good quality products. Scrum only helped to facilitate the delivery process and emphasizes some good practices. On the other hand every time I saw an organization trying to fit a broken environment and delivery process into scrum things just went even more problematic. It’s not only about Scrum, but I think it’s about any other tool and process.
First of all you need a qualified and good organization with mature and well established procedures and roles, then we can adopt any project management tool to facilitate the delivery process.
Story:
Once I was working in a company with good number of expert developers and out of the sudden management decided for some reason (guess what) to hire a Scrum master and establish a Scrum framework into IT department and maybe other departments as well. Finally we all introduced to Mr. Scrum.
As a usual routine whenever some one wants to sell his/her products tries to talk around whats good about it and why you’ll need to buy that, even if you don’t really need it at all (called Marketing I guess).
We held a meeting (informal though) and Mr. Scrum start to explain essentially why we need Scrum. He talked about some good aspects of scrum and to shine a light over a topic and illuminate the SCRUM concept he gave an example.
“Imagine we want to adjust a public place’s - like a museum’s - temperature. So what do we do?” he asked. People in the meeting tried to analyze the situation and consider all possible factors that might have effects to the temperature with some good outcomes [I call this step project planning]. “We need to consider outside temperature” someone replied, “What season is it” someone else continued [I call those external factors]. and another continued “We need to estimate how many people are going to be in that room”, “What are the operational hours” [I call those organizational/internal factors]. “We need to adjust air conditioning system with proper measures” someone replied [This is change management].
I was quiet all the time, why? because Mr. Scrum was not very lucky that I’m actually a mechanical engineer and I know the procedure and requirements for designing a proper HVAC system. Ask me why? Read on …
“We only need a Thermometer! then we can read temperature and turn air condition system knob accordingly to adjust the correct temperature!” Said Mr. Scrum while nodding his head (means you are all right but …) “This is what SCRUM is all about!” he continued. [!!]
Then What?
Is it really what scrum is all about? So short sighted? Then what happens to the whole design of HVAC system? Maybe he considered we just order one online from ebay? Maybe a stylish one!
It’s about software development, and it’s about the whole “System Development Life Cycle” known as SDLC. In the aforementioned story I highlighted some points in brackets. As we can see here people were all trying to do analysis and find out what parameters are effecting the project and then how we can plan those issues. These are all “Project Management” concepts. We need to consider all those parameters before we can start any project whether it’s an agile or water fall style. There are differences in types and levels of details of analysis in different types of project managements though, but we can not simply put them aside.
I heard many times that “In Scrum we do not need to plan ahead for our projects” - strangely!
I’m mechanical engineer (fluid mechanics) and I know very well, designing an acceptable HVAC system requires a lot of investigations. You’ll need average monthly temperature and humidity of that area, Walls and doors type and thickness, Which floor it is, What type of system you are going to use, how many people are there on average, Wall heights, even which direction windows and doors are face to (ie, NWES), and many many other factors. Then only you’re able to calculate the capacity required to address that environment.
What about thermometers you asked? Well, this problem has been resolved long time ago with thermostats, these tools can measure temperature and adjust HVAC capacity based on that, then we don’t need scrum at all ;)
Conclusion:
If you look at the projects with that concept I can say from my experiment you are in trouble. You’ll need a proper analysis before starting projects even with agile. The good thing with agile is the more you work on iterations the more details you’ll get and you can extend your project plan accordingly. this means you may not need a very in-depth project planing like classic model though but still you need to do a minimal plan ahead and have a overall picture of the project first. Have you ever heard of “A blind men and an elephant”? Try to avoid that pitfall.
You ask me what happened to that organization? did they succeed in their projects? Unfortunately I don’t know the answer, I hope they are.
I believe in best practices in project management. And I think using Scrum, Lean or any other methodology is a right management decision.