“Of course it should,” would be the your answer if you know little bit about Agile concepts.

But in practice, often they do not!

I was watching a YouTube Video from an “Agile expert” who is a Global Head of Delivery with a Leading Based Software Development Company.

My expectation was: I will get new insights about agile from his practical experiences. And guess what: I am writing a blog post titled “Should a talk on Agile engage its target audience?”

Funny, isn’t it?

Not only his speech was NOT engaging, but also there were clear misconceptions communicated –  he referred to the Agile as methodology which it is not.

Agile is a framework or mindset. Sure, you may create your own methodology based on Agile but it is not a methodology.

About engaging its audience, if you really have mastered Agile mindset, everything you do, within and outside of your professional work, will confirm to core agile principles, only the context would change.

If you deliver a talk and DO not ask questions that engage your audience, no matter what other expertise you have, you are not conveying the “right” message.

The post Should a talk on Agile engage its target audience? appeared first on ScrumZen.

Enter year 2000 to know that Ket was more than a competent programmer. Not just competent, super intelligent too.

He was also a kind of perfectionist.

It was initial two years of his career but because of his intelligence he was leading the team of five and working day and night on delivering a software product that had hundreds of order booked prior to its launch.

Ket simply wouldn’t allow the less than perfect code to check in into the code repository. The code had to be “perfect” and he has to be absolutely clear about it.

He would allow the code to check in only when there is no other way left. He had to handle a lot of pressure from the investors also.

Ket’s way was a surefire recipe of a slow disaster, isn’t it?

So, don’t code for perfection. Don’t be like Ket that way. Code for excellence instead.

No one will be impressed with the software app that you have not released. You even do not know if it is a minimal viable product or not.

Perfection doesn’t exist. Strive for excellence instead. Use iterative approach. Define a set of feature, prioritize them, pick a potentially releasable set and build them to the demonstrable piece of code.

People who invest in iterative learning already have what is called “The Agile Mindset.”

That’s exactly opposite to “Perfectionist Mindset” where you invest in your illusion more than anything else without even knowing whether there is a possibility of good ROI or not.

The analogy used is for a software app but same is true with a book or a blog post or a logo design.

Ship early, ship often and keep getting better. [Click to Tweet]

Scrum is possibly the most powerful tool to help you do that. Don’t wait, find out when scrum works and when it doesn’t.

The post Don’t Code for Perfection appeared first on ScrumZen.

Reading an excellent post on Product Backlog from Roman Pichler – The Good, The Bad and The Ugly Product Backlog.

The product backlog is the roof that covers a Scrum Project.  So what’s good, bad and ugly about it?

Good – Simple list. Flexible. Supports sprint and release planning.

Bad – Needs that are hard to describe in a list-form become difficult to maintain. Often requires another tool. Also, when it becomes challenging to use a list when release planning is not feasible.

Ugly – When requirements are stated with unnecessary details, and the list is of hundreds of items, product backlog becomes ugly and hard to deal with.

The way I see it, bad and ugly part of product backlog have more to do with how it is used and less to do with product backlog itself.

Nonetheless they are important and cannot be overlooked. Similar to how a Scrum Project evolves as it progresses, implementation of product backlogs will also evolve.

That’s why Roman talks about an alternative to Product Backlog – The Product Canvas, which is a really good tool to see and use.

Progressive elaboration is the key nature of things in Scrum, isn’t it?

The post Roman Pichler on Product Backlog appeared first on ScrumZen.

I have seen many Scrum novices arguing and saying that Estimates are not useful as we are anyways putting in our focus and energy on the most important tasks.

That’s seldom true. Estimates are important and provide a rough idea about how future should shape itself.

Read this insightful post on Estimation in a Scrum Project  from Mike Cohn. It shows a dialogue between client and the Scrum team.

It is important to note that Scrum projects are part of real world that requires some idea about what will be delivered. Any Scrum team cannot take the flexibility that the framework provides for granted.

The flexibility is to eliminate the unnatural, rule-powered ways from the project. It’s not to disregard the need of business.

Here’s my take on it:

“If it doesn’t make a business sense, it is not the right implementation of Scrum.”

The post On Scrum and Estimations appeared first on ScrumZen.

Scrum and Control…What?

Scrum is all about NOT being in conventional control and still getting things done, fast and more effectively.

Today, Blogger, Author and a friend, Tanmay Vora wrote an interesting post that conveys a similar point – How NOT to be in control.

Tanmay talks about three important points:

1. Positional Power.
2. Staying on top of the information and
3. Communication.

All the three points are nicely conveyed.  Read Tanmay’s full post here.

An effective implementation of Scrum also touches upon all three points that Tanmay mentioned.

In Scrum, there is no positional power. People who get things done are in control of their own work and the software is developed collaboratively with the loosely defined guidelines that are based on tightly subscribed principles.

Staying on top of the information is the key success driver for a Scrum team. In Daily Scrum Meetings, this becomes evident.

Take any successful Scrum project and you will find a common thing – excellent communication among the team members. No communication, no Scrum. It is covered in the basics. Individuals and interactions over processes and tools.

Many a times, people ask me: Why is Scrum your favorite weapon in the world of software development? My answer is simple – It is the most logical, getting it done kinda framework that doesn’t depend on mere rules and controllers of those rules.

Scrum relies on principles more than rules…and I have always chosen principles over rules and have never regretted.

Scrum rocks. People doing right kind of Scrum also.

9DUWXEZB9A7H

The post Scrum and Control appeared first on ScrumZen.

More often than not, I hear this quesiton – Which Scrum Software Will Assure Guaranteed Project Success?

My short answer is: “No Scrum Software can assure guaranteed project success.”

It is said time and again that no agile methodology or tools are silver bullets.

In order to succeed, teams have to work right (harder and smarter and whatever makes it right) by focusing on what’s important and eliminating everything else.

Agile manifesto also values Individuals and interactions more over processes and tools.

Don’t get me wrong. I’m not saying methodologies are not useful. Indeed, they are but the Project Success depends on people doing right kind of things. Foundational principles matter more than methodology as any given methodology is just an implementation of set of principle it has subscribed in.

And depending upon the context, there are multiple right ways to implement the set of principles, isn’t it?

To get deeper in this subject, read this fantastic article called methodology doesn’t matter by Jesse Fewell from whom I learned Scrum.

So, coming back to the question, no software will assure guaranteed project success but a right team with whichever Scrum software they select is most likely to make the project successful.

You know why?

The right team will ask the right questions including the unpleasant ones and introspect how they are doing. It will make required corrections, Change or remove any of the tools they have been using but are no longer effective and deliver the value.

Remember, Scrum never succeeds or fails, people implementing Scrum may.

The post Which Scrum Software Will Assure Guaranteed Project Success? appeared first on ScrumZen.

When you don’t know what features to have  in your software product, that’s when organizations judge how powerful you’re as a Product Owner.

When you don’t have the statistics to back your idea up, it’s when you exhibit your organization how valuable your idea is.

And when you don’t know whether your idea is going to add value, that’s how organizations find whether or not you’ll continue to work as a Product Owner.

Creating Backlogs is much harder than accomplishing a backlog item, although both the activities count.

And that’s where Great Product Owners distinguish themselves.

So the question is: what would you do so that you’re distinguished as a Product Owner?

The post Creating Backlog Vs. Accomplishing a Backlog Item appeared first on ScrumZen.

Last week I wrote a post called “When Not To Use Scrum?”

Objective of that post was to highlight some of the situations in which Scrum may not be that effective. Nothing is perfect in this world; Scrum is no exception.

It doesn’t have to be.

Most important thing is to know when Scrum works and when it doesn’t and make the best use of it when it works. As I always say, “Scrum is a vehicle, not a destination.”

So here come some situations that are favorable for making a Scrum implementation successful.

1. Scrum implementation in your organization has got conscious top-management buy-in.
2. Top management would like to take the cost of implementing “pull” systems over “push” systems. Such costs may be huge in the beginning.
3. Hiring process is updated to hire people who are strong team players. If a person is great individual contributor but not a team player, s/he is not the right fit for a Scrum team.
4. Performance Appraisal systems are updated to evaluate team performance rather than individual performance
5. Scrum teams are made of people who are level 3+ according to Maslow’s need theory who would inherently love to self-organize.
6. People have high respect for one another regardless of their different, individual opinions or point of views.
7. People work on one and only one project at a time.
8. People “pull” the work, no manager is required to “push” the work and get things done by constant follow up.
9. People understand the definition of “done” – and they commit to it. If they need external forces (aka “manager”) then it is unlikely to work.
10. Organization’s value system is based on doing right kind of “less” compared doing generally “more” in all that they do.
11. People are ready to rise beyond their individual title such as Technical Leader, Business Analyst or Senior Engineer and work as a team member who is driven internally, not by any external thing such as title.
12. People work at a sustainable pace – they have good work life balance and most important, they value it and consider organization as a valued partner in this.
13. The person playing the role of “The Product Owner” works on only one project and always owns the priority of the features to be developed.
14. Everyone involved understands that Scrum is a mind-set not a methodology.

Scrum works when people implementing it make it work. Remember, Scrum never succeeds or fails; people implementing Scrum do.

The post When Scrum Works? appeared first on ScrumZen.

Without a doubt, Scrum is my preferred vehicle in the world of software development journey. However, there are situations where Scrum may not produce the best possible results.

In order to get best out of Scrum, you must understand and continue expanding your understanding about the situations when something other than Scrum might produce better results.

The post When Not To Use Scrum? appeared first on ScrumZen.

One of the most common causes I’ve observed in failed Scrum implementations is: Scrum team does not have conscious top management buy-in.

I have seen department heads attending courses of Scrum and opting to implement Scrum in their projects without ensuring top management’s conscious buy-in.

They sometimes do it because they feel Scrum is a smart way to ensure project delivery and probably the silver bullet.

It is not.

It may sound easy though. Power of Scrum rests in its simplicity. But in order for that simplicity to work as a tool to get things done, the top management…key decision makers… have to buy into Scrum.

Conventional management is primarily about command and control or carrot and stick as we call it whereas Scrum is about giving away the command and control in the individuals’ hands who will act as a self-organizing team to achieve a common goal .

Top management has to make a conscious choice if they want to apply Scrum framework to execute their projects. They need to look at it from multiple perspectives including the nature of projects the organization will be undertaking.

If the nature of project is predictable and not uncertain, Scrum may not be a good choice. However, if the opposite is true, Scrum can be the most powerful tool a project can ever have given the right team.

As a Scrum team, you need to figure out whether your project has got top management buy-in or not. If not then first thing you can do is to bring that up in your daily stand-up meeting as most crucial impediment to be resolved.

Such impediment removal might result into a project which doesn’t use Scrum but that is the right thing to do.

Extreme Scrum-thinking: Don’t use Scrum if that’s the solution to removing the main impediment.

The post Beware of Scrum appeared first on ScrumZen.