Is Change Free in Agile?

The underlying purpose or motivating factor behind the whole Agile development methodology was to allow teams the flexibility to inspect and adapt to changes. This was something the practitioners of traditional waterfall methodology were longing for after scope creep ruined almost every project they worked on so, they jumped headfirst into the Agile pool so that they can “Embrace Change”. So far, so good – right?

Unfortunately, one of the biggest misconceptions about Agile is the fact people think that change can be introduced at any point during an Agile project and it will be free & easy because isn’t Embracing Change the underlying philosophy of Agile?

Yes, an Agile project is supposed to Embrace & Adapt to changes. But, are these changes free? Read on, to find out more…

Does Change Have a Cost?

In one of my recent projects, I was talking to my product owner to get the product backlog in shape for the upcoming product release. He did have a couple of features/backlog items for the team but the features were still under review and could potentially change. Myself and the Scrum Team were a bit reluctant to start work on a user story that was eventually going to change whereas the Product Owner just smiled and said – But I thought you’re agile, and isn’t the whole point of being agile that you welcome changing requirements? Why are you guys so reluctant?

Yes, he was right, the Agile methodology does allow us flexibility to embrace changes, but I had to explain to him that this change is going to have a cost impact and is not free.

Let’s say we start work on User Story (US) 1 and finish it in Sprint 1. In the middle of Sprint 2, while we are working on US 2, we receive changes in US 1 which need us to take up a few days’ worth of rework which results in neither stories being finished in Sprint 2. In Sprint 3 when we are about to finish both US 1 and US 2, we receive further more changes on both stories which results in more rework and once again neither story is completed at the end of Sprint 3.

Though the team was occupied for 3 Sprints, the eventual outcome is 2 stories that are partially complete with potentially more changes on the horizon. Haven’t we quite literally wasted 3 Sprints by the team in our aim to adapt to Change? Not to mention the opportunity cost the company has lost because, this effort could’ve been used to build useful features that could increase the value of our product. Get the picture?

This is the “Cost” I am talking about when we say, Change isn’t Free. The bottom line is – “Every change has a cost”.

This is the point that gets overlooked by new followers of Agile or Scrum because the trainers who imparted scrum wisdom to them probably missed mentioning this point.

What is your experience in handling change in Agile/Scrum projects? Do share them in the comments…

Is Iterative Software Development Really Agile?

A few years back, I was asked to take over as the Scrum Master for a team that was already familiar with Agile/Scrum concepts. I was quite excited because, for a change, I was joining a team that already knew what Scrum was and I did not need to train the team in Scrum Methodology. After a few days with the team, one thing became very clear – they were doing Iterative Waterfall and not Scrum.

Confused? Read on, to find out more…

Before we Begin: The Waterfall Methodology of Software Development

Software Development for many years used to follow the Waterfall Methodology where teams first gather requirements, designed the system, built it, tested it and then finally packaged it for delivery. The term Waterfall was used because each stage had a clear-cut start and finish and happened one after the other just like water flowing/falling over a bunch of steps. Look at the picture below:

Is there really an Iterative Waterfall Methodology?

I used the term Iterative Waterfall at the beginning of this article. What exactly is Iterative Waterfall? Is there such a thing as Iterative Waterfall?

Actually, Iterative Waterfall is not a formal software development methodology but is one of the most widely popular/used methods. In fact, most people who claim to be doing Scrum are actually doing Iterative Waterfall.

A typical Iterative Waterfall project would do any or all of the following:

• -        They have a Functional Specifications Document (FSD) instead of a Product Backlog of Features
• -        Scope is Fixed and all features have to be built by the Delivery date
• -        The first few iterations are spent in planning (and sometimes design too) for the overall delivery
• -        The Product Owner just translates sections of the FSD into a User Story which results in huge user stories that typically take 2 or 3 or more iterations to finish
• -        Development and testing for a user story happen in different iterations; i.e., Development finishes in Iteration N, while Testing completes in Iteration N+1 or later
• -        Team have a clearly defined Tech Lead who does Task assignments and tracks progress
• -        Each Sprint/Iteration does not result in a potentially shippable product.
• -        One big-bang round of Testing is done toward the end of the project to ensure good quality software product
• -        Team does Analysis à Design à Develop à Test à finish for each story assigned to them.
• -        Daily Stand-ups are more like Status Update Meetings.

Are you part of a scrum team that does any or all of these?

Is Iterative Waterfall or Iterative Software Development Really Agile?

Of course Not.

Iterative software development is extremely popular because, people who are very used to the waterfall model of development, find it very hard to give-up on their practices and just include the Sprint/Iteration thing into their project and claim to be doing Scrum. They also, split user stories into smaller pieces just so they can calculate a Velocity and show progress. Team does development in Sprints, requirements are captured in stories, estimates are done in story points, velocity is calculated etc. Isn’t this almost like Scrum?

Like I said at the beginning of this section, No Iterative Software Development is not Scrum. In Scrum each user story is an incremental feature of a product and in each sprint delivers a product that could potentially be packaged & shipped to the market. The past many articles have covered various different concepts about Scrum and we have pretty ignored all of them as part of this Iterative Waterfall. Haven’t we?

What is your experience on Software projects? Have you come across any Iterative Waterfall projects? Do Share your experience with other readers…

The Golden Triangle in Scrum – Scope vs Time vs Cost Trade-off

Anyone who has had any formal project management training would be familiar with the golden triangle concept. In one of my articles on the PMP Exam prep series we had reviewed the topic of controlling the project Scope, Cost and Schedule. Click here

A project usually has competing demands from these 3 aspects - Scope, Time and Cost. When there is change in one aspect the other two sides of the triangle need to adjust in order to keep the project under control. But, that’s for a traditional waterfall type project. Do we have a Golden Triangle for Scrum? That is the question we are trying to answer in this article.

Does Scrum Also have the Golden Triangle?

All projects Agile or Waterfall or whatever be the methodology they follow, will have competing demands from these 3 aspects – Scope, Time and Cost.

Let me ask you a question: If you have 5 members in your team and have a 3 month schedule, do you think I can keep adding more and more scope items to the backlog and you will still finish on time?

You may think of an answer like, I can if I add 2 extra developers or if I get 1 month extra time but you already answered my question – No, you cannot. If you fix the team size and the schedule, the amount of software features the team can produce is limited (assuming you don’t make your team work 16 hour days)

Get the picture? But, I haven’t explicitly answered the question, have I?

Does Scrum also have the Golden Triangle – Explicitly No.

Surprised?

In Scrum the Product Backlog is not a fixed entity like waterfall. The scrum team makes a best effort attempt at building as many features of the product (in priority order of course) but there is no commitment that the team will build all of the features in the backlog. We have a dedicated Product Owner who takes the responsibility of adjusting the product scope based on priority and the teams velocity. Hence we don’t have a Golden Triangle in Scrum. We only have a Time vs Cost Trade-off in Scrum because scope is always variable.

The Time vs Cost Trade Off (With Scope Being the Evolving Constant)

The easiest way to reduce a project duration is by adding more people – this has been the motto of managers since project management became a profession (this is also the reason why software developers hate project managers)

Anyways, in most organizations, every product has  a roadmap of features and also has timelines to hit the market with those set of features. So, Time aspect of development is almost always fixed and does not change unless something drastic happens. When time cannot change (and scope is evolving), cost has to change to adapt to the situation – there is no other choice. We add more people to the project in order to meet the projects’ needs.

For example, suppose a project would take 1 year for 1 person to finish, adding an extra person could probably result in an overall schedule of around 7 months. Adding another person may bring the schedule to around 4-5 months and adding more people may further shorten the schedule but not exactly by a mathematical factor because we also have to take into account overheads on communication and coordination between the different parties involved. Anyways, adding more people means the project becomes more costlier and this where the trade-off between schedule and cost comes into picture.

In real life, Senior Managements across all businesses & organizations push for lowering of cost or expenses. So, it may not be practically feasible to have an endless budget. But, having said that, a company that wants to bring a product to market cannot be solely focused on the cost of building it because, releasing the product with maximum features and within committed timelines is much more important that saving cost. If you are wondering why, think of this – Todays market is highly competitive and a few weeks delay could be the difference between a product being a success or a failure. If our competitor releases a similar product a few weeks ahead of us wouldn’t clients choose their product over ours?

This is why, experienced scrum masters will try to get the various different stakeholders in the scrum project like Architects, UI Designers and so on to work seamlessly together to keep the delays due to overhead as minimal as possible and keep the schedule as short as possible. Even in organizations where cost is not really an issue, scrum masters still try to optimize the team size and not depend on endless hiring just to meet the competing schedule or scope demands.

What is your experience with regards to handling competing scope or schedule needs in your agile projects? Sound off in the comments section…