I've always wondered -- not just as a developer but as a human being -- why I needed to follow the orthodox methods of typical hierarchical reporting. There was always some "middle man" confusing the conversation. You can define many roles in a typical hierarchical organization, and they're there for good reason. However, are we seeing a wave of change? Are we moving toward a method in which we don't need documentation, we don't need managers, we don't need analysts?
The answer is a resounding "No!" However, in the past few decades we have seen major changes in the way we work within organizations. It all started with the traditional phased approaches to a project, followed by interactive and then incremental phases. And then, eventually, a wave of Scrum-based Agile. Is this really the best way to go forward? Have we encountered the most intriguing yet effective way of managing projects?
Yes, we have -- and I'm glad it finally has a name.
What is it about Scrum? I became thoughtful along the road of management. I kept wondering whether the approach we follow in our daily lives is Scrum, Waterfall, philosophical, or something that combines all three. After thorough analysis, I've come up with my current viewpoint. I hope to explain it here, to help novice users to understand what Scrum is and how to go one level further and visualize Scrum in their daily lives, both at home and at work.
The story begins -- or does it?
We all go through cycles, and that includes project management. Human beings have long realized the importance of collaboration, and we learn to respond to change -- be it climate change or financial crash. So is Scrum-based Agile something new? It's actually terminology that has evolved from basic human principles, which can be categorized as follows:
1. Individuals and interactions
2. Working product
3. Customer collaboration
4. Response to change
It doesn't matter whether you're a software professional, an architect, a manufacturer, or someone living on government funds. You can apply Scrum in your daily life and see the difference. Let's see how:
What? What you want done = Product
Define: Define and schedule what you want = User stories
How? How you will achieve this = Sprints and release
Check: How you will track it = Burn-down chart
When? When you will get it = Timelines, release planning
Perspective: How it's going = Daily stand-up
Who? Who will get the job done = Teams
How many? Team needs = Developers, testers, designers, subject matter experts
Scrum in daily life
Let's look at Scrum in our daily lives by starting with a small story. Say you want to go shopping for brand-name shirts. You're familiar with your size and your favorite brands, but you want to look around to see if you can find something even better.
You go to Store 1, with its renowned brands. You're wondering which shirt would be best when you remember that a friend has recommended a particular brand. You look for one -- but before freezing (buying), you decide to be fashion-conscious, looking at recent trends, and you run an analysis of costs. You find that there's a trade-off. What you like most is a bit expensive, so you settle for something you prefer rather than something you love. Of course, if money is no object, you immediately buy what you like most. Later, you may look back and change your decision, based on the input, or reactions, you get.
Let's map these factors in the Scrum world:
- Cost = Cost of the product
- Person's individual choice = Individual preference
- Recommendations = Voice of the customer fed back to the product owner
- Trends = Industry best practices
Looking further at our own lives: We all have a wish list, right? Let's call this wish list a product. You can guess who the product owner is.
In real life, when we create a wish list, we then brainstorm and identify the actual "user stories" that can feasibly fit into the next "release." This process is nurtured by our environment, experiences, and so forth -- and these are never constant. It's said that the road to success is always under progress because we always keep moving our target (and that's how the product backlog comes into the picture). In short, we:
- Categorize and prioritize it.
Behind that is loads of thinking and planning; Scrum guys call it "release planning." So once the product owner understands what can be accommodated in a release, the wish list is further broken down into sprint backlogs -- chunks of user stories explaining some piece of functionality that must be completed.
And yes, you need someone who ensures that every team member has the tools to get the job done. This guy is called a Scrum Master. Those who do all the work are the Scrum team (developers, testers). How long can a release last? There can be four to a dozen sprints within one release. At the end of every sprint, you have a part of a shippable product.
How do you monitor Sprints? You use:
1. A burn-down chart (velocity - slope).
2. A look at the total work remaining. This changes on day-by-day basis; we look forward rather than backward.
3. Daily stand-up meeting, so that nobody will waste time. (What are you working on today? What are the obstacles? What did you do yesterday?)
Scrum can fit into sales, marketing in the CEO's office, software development, or even the management team itself. Imagine these conversations:
CEO: "I've got all these departments telling me what they're doing, but they're not helping one another out and they're not telling me what their common purpose is. How do they interact among themselves? I need to have quarterly objectives on a dashboard."
Scrum expert: "You are the chief product owner, the CEO. Let's create a Scrum dashboard that streamlines all the objectives. The next time you have your quarterly meeting, everybody will come up with something that's common across the board. It will facilitate a fresh air of communication within and outside the department. Then let's observe who has the fastest velocity."
I believe people like Steve Jobs are perfect examples of a chief product owner. He had a product concept and vision; he heard the voice of the end users. And yes, he kept evolving.
Are we experiencing deja vu? Has Scrum always been here? From the Stone Age through the age of building empires, the Industrial Revolution, the software age, and the social networking age, Scrum has in fact been part and parcel of every era. Our recognition of Scrum principles is changing the world. Come and be part of it! The 21st century could be the official century of Scrum. Self-steering, continuous improvement, and survival of the fittest are the demand of the hour. All these are addressed by Scrum-based Agile.