How to Raise a Lean Startup – III

Lean Startup

<< Part II

I practice Scrum / XP in the software projects I manage. As part of the same, the team iterates over sprints during the development of the project. The sprints are kept as short as possible (usually a week long) so that feedback loop is short. At the end of each sprint, the team gets feedback on whether they built the right product or not. Likewise, for a ship cruising on the ocean, frequent checks of the current route vis-a-vis the planned route are preferred so that course corrections (if any) are short.

Ries illustrates the same spirit of short feedback loops in the diagram below:

Feedback Loop

The aim is to quickly show something to the customer so as to seek his acceptance and then move onto the next iteration to add some more features or perhaps remove some existing feature based on the feedback received. Ries puts it eloquently, “…the goal of the MVP is to begin the process of learning, not end it. Unlike a prototype or concept test, an MVP is designed not just to answer product design or technical questions. Its goal is to test fundamental business hypotheses“.

While the entrepreneur is incorporating feedback and working to improve the product, how does he ensure that he is on the right track. This is where innovation accounting comes into play. It comprises of prioritising product features, selecting a target market, and critiquing the vision in the light of market feedback. Innovation accounting has the following steps:

  1. Using an MVP to have a firm grasp on the current position of the startup
  2. Trying to move this baseline to where the startup would like to be by tuning it up
  3. Finally, arriving at a decision on whether to pivot or persevere

The entrepreneur should be careful in measuring the data lest he finds himself obtaining vanity metrics (that wrongfully depict the startup to be in a healthy or improving condition) instead of real metrics.

The above help the entrepreneur in deciding whether to pivot or persevere. While persevering is relatively easy to understand – iterating through the build-measure-feedback loop continuously while tuning the product continuously – pivoting requires a little explanation. Pivoting doesn’t mean throwing away everything and starting from scratch. It is about reusing whatever has been built to the extent possible and then building on top of it to target customers afresh. Pivots can be of one of the following types:

Zoom-in Pivot: what was earlier only a feature of the product becomes the product now and other features are either abandoned or assume lesser significance.

Zoom-out Pivot: the product itself is insufficient and thus more features are added to it to create a new product.

Customer Segment Pivot: the product solves a real customer problem but it would better serve a different customer segment than the one it is currently targeting.

Customer Need Pivot: the need being solved currently is insignificant as compared to the one that can be solved without repositioning too much.

Platform Pivot: this is a pivot from selling a product that solves a particular need to let customers use it as a platform for provide similar services.

Business Architecture Pivot: this is a pivot between high margin, low volume business (usually B2B) and low margin, high volume business (usually consumer products).

Value Capture Pivot: a different feature can be monetised instead of the one currently being so.

Engine of Growth Pivot: the company can pivot among the engines of growth – viral, sticky, and paid. This usually requires a pivot in capturing value as well.

Channel Pivot: a pivot in the distribution channel of the product / service.

Technology Pivot: the company can pivot on the technology that provides a better cost advantage or better performance

Continue to Part IV >>

How to Raise a Lean Startup – II

Lean Startup

<< Part I

Learning is the centrepiece of Lean Startup. So much so that the the progress of a Lean Startup is defined in terms of learning milestones and people are held accountable to the same rather than organising them in traditional departments and holding them accountable to individual responsibilities.

The real motive of an MVP is to generate learning. This is because more important than building something efficiently is building the right thing. No point building a great product with a greater process that no one desires. Thus learning helps in validating the hypotheses the entrepreneur makes when building his product.

This product is refined based on the feedback generated from the market through the use of MVP. In the face of this feedback, which might not always be positive, the entrepreneur, might have to decide whether to continue to work on the same product or choose a different strategy. But such decisions are less frequent than the tuning done to the product. Even less frequent, if at all, are changes to the overarching vision with which they set out to become an entrepreneur.

Pyramid

As Ries says, “…a startup is a portfolio of activities. A lot is happening simultaneously: the engine is running, acquiring new customers and serving existing ones; we are tuning, trying to improve our product, marketing, and operations; and we are steering, deciding if and when to pivot. The challenge of entrepreneurship is to balance all these activities.

Not just startups but even existing organisations need to learn and innovate continuously in order to maintain their competitive edge or gain one. In this ever changing technological landscape, such edges get eroded very fast. Consider Blackberry that had long enjoyed the image of a premium, enterprise mobile handset company. It had two major advantages over its competitors: push mail service and Blackberry Messenger. With the rise of smartphones and their numerous apps, both these advantages were laid to waste. The result, Blackberry’s share in the market, which has already reduced to a minimum, is shrinking rapidly. The company is desperately looking for someone to buy it out but nobody wants to.

There is a trap in trying to learn what customers want. An entrepreneur should be able to distinguish between what the customer is asking for and what he really wants. This is because a lot of times customers don’t know for sure what they want. Identifying the real wants and working on the same causes the startup to grow and evolve. This is what Ries calls Validated Learning.

The question is not “Can this product be built?” In the modern economy, almost any product that can be imagined can be built. The more pertinent questions are “Should this product be built?” and “Can we build a sustainable business around this set of products and services?” – Ries

Mark Cook, Vice President of Kodak Gallery says the same thing in his own words:

  1. “Do consumers recognize that they have the problem you are trying to solve?”
  2. “If there was a solution, would they buy it?”
  3. “Would they buy it from us?”
  4. “Can we build a solution for that problem?”

All the above is based on the cornerstone of experiments. I had read somewhere (I think it was Stephen Hawking’s “A Brief History of Time”) that an experiment cannot be considered a failure if it disproves your hypothesis. It’s a failure when it is inconclusive. Therefore even if the product fails, the experiment is still a success because we know what the customer doesn’t want.

Now, how to structure the experiment, the hypothesis. Ries considers two hypotheses to be structured: value hypothesis and growth hypothesis.

Value Hypothesis tests whether the product / service being built would actually deliver value to the customer. This hypothesis helps in answering the question would there be customers (early adopters) who would buy the initial versions of the product (MVP) and find it useful.

Growth Hypothesis tests whether the product’s purchase and usage would spread from early adopters to the masses. This helps in answering the question would the business grow from the initial success with early adopters.

Continue to Part III >>

How to Raise a Lean Startup – I

Lean Startup

Most of you would be aware of the term “Lean”, thanks to its overuse by a lot of organisations these days (and some slimming centres too). Startup, again, is not an unfamiliar term as every new tech company calls itself a startup.

However, what you might be wondering is “what is a lean startup”. It isn’t a startup with very few employees (as almost all of them already are). It is a startup that has been founded on the principles of Lean and following an MVP (Minimum Viable Product) based approach to starting-up.

Wikipedia describes MVP as “a strategy used for fast and quantitative market testing of a product or product feature“. Also mentioned alongside is the name of Eric Ries. For those familiar with startup landscape, Ries is a celebrity. He is said to have popularised the term MVP. Some attribute the term entirely to him.

Ries has a very popular blog on Lean Startup and a site that serves as a selling platform for his bestselling book “The Lean Startup” (which doesn’t need selling though). His blog has a very interesting quote from his book:

Startup success can be engineered by following the process, which means it can be learned, which means it can be taught.

Now this is in stark contrast what some of us might think or have even experienced. Startup success has been considered enigmatic, even elusive like a mirage. But here is Ries claiming that there is a definite process to it. This gives the impression that it can be synthesised as if in a Chemistry lab or manufactured as if on an assembly line.

But what gives him that confidence to make such a bold statement. He attributes it to the concept of MVP or in his words, “the build-measure-learn” feedback loop. Through this loop, the entrepreneur builds a bare minimum product in order to test his assumptions / hypotheses, measures the reactions of customers thus validating / invalidating the hyotheses, and generates learnings in the process.

Ries outlines 5 principles of a lean startup:

1. Entrepreneurs are Everywhere
Ries considers anyone who fits the following definition as an entrepreneur: “a human institution designed to create new products and services under conditions of extreme uncertainty”. A person doesn’t necessarily have to work out of a garage to be one.

2. Entrepreneurship is Management
Even a startup requires management, in fact, more than traditional organisations because a startup might have bigger and frequent challenges. However, traditional management is not of much help here and one needs to think out of the box that various business schools have created.

3. Validated Learning
Ries defines this as the single most important measure of progress in a startup. The startup iterates through multiple failures to arrive at success and, in the process, gains invaluable lessons that help it in the next iteration. This learning is validated by its customers who either accept or reject its products / services.

4. Innovation Accounting
As boring as accounting may be, its importance for startups cannot be overstated. Measuring progress, defining and tracking result metrics, setting up milestones are all tasks that an entrepreneur needs to fulfil zealously.

5. Build-Measure-Learn
Startups must continuously churn out products, measure their acceptance with the customers, and incorporate their feedback so as to either turn their strategy on a sixpence (pivot) or continue to push harder (persevere).

Continue to Part II >>

Detailing Backlog Appropriately

 

Backlog

On one of the projects I am managing currently, I noticed that the product backlog was actually growing rather than shrinking as we were progressing through sprints. At one point, there were close to hundred and fifty stories in the backlog, all detailed and ready for planning. Some were even accompanied by ready UI-designs. The reason for the increasing backlog size was that everything under the sun was being thrown into it for future development. While this might sound fine (you would want to write down somewhere the features you might need in the future and what better place to write them down than the backlog), there was something definitely going wrong.

I realised that every time we would plan a new sprint, instead of picking previously written stories from the backlog, we were writing new stories as the client had come up with a new feature that had priority over rest of the backlog. This is completely understandable and even recommended. After all, you would like to use the feedback you are receiving from the market to add new features. If the window of opportunity for a new feature is now, no point putting it on a backlog for later. It requires attention now. But what about all the stories (and the effort invested in detailing them and designing the UI for them) in the backlog? Soon they would become obsolete. They would never see the light of the day. If at all their turn would come, they would require changes (in both the functionality and the UI expected) as the current functionality would have undergone a change by then. In terms of Lean thinking, this was clearly muda (“waste in Japanese). I could have done better things with the time I invested in detailing those stories and helping create their UI-design.

The other day, I was watching a show on some television channel (I think it was Comedy Central) and I noticed the way they presented their schedule:

  • Now (the show currently being telecast)
  • Later (the show after the current one)
  • Never (the show after the “later” one)

This was a fun way to provide a relative schedule, especially the “never” part. Considering that I am always in a “meta” state of mind looking at things above their current context and trying to correlate aspects from different contexts, the schedule format hit me as a solution to my backlog problem.

While the stories in the current and immediate next sprint (“Now” part of the backlog) would be detailed enough, the stories in the next two to three sprints (“Later” part of the backlog) would be relatively coarse grained. Stories even further down in the backlog (“Never” part of the backlog) would have no detail whatsoever. They could be as simple as a single line, five-word statement (similar to epics in Scrum parlance). This would help the backlog stay current and sharp, help me focus my time on more important tasks, and reduce waste. Of course, we would continue to add to the backlog any item we “might” need in the future but it would not be as detailed as before, it would simply be a reminder, like a to-do.

If Scrum was a Motorbike

Scrum Motorbike

Scrum and motorbikes, two things that I am very passionate about. Subconsciously, I could sense a parallel between them. When I actively thought about it, the picture became clearer.

Consider the Team (developers, UI designers, testers) in Scrum. Its mandate is to deliver a working increment each iteration. It is what powers the product / project. It is similar to the engine of a motorbike. It converts stored up energy (in the form of fuel) into motion that drives the whole. Akin to a Scrum team, it delivers usable power each cycle of the n-stroke engine. Similar to a Scrum team that iterates over the backlog, the engine iterates over the strokes in each cycle. The way an engine gobbles up fuel to deliver power, the team completes stories from the backlog to deliver a working software.

Now you don’t need to be a gear-head to know the importance of keeping the engine well oiled. That is where the ScrumMaster fits in. He is the engine oil. The oil keeps the engine running smoothly, lubricating it, ensuring that there is no grinding against the metal. Similarly, the ScumMaster keeps the team protected of outside interference, ensures that there are no impediments in the progress, that the team is not overloaded, that there is no grinding between the team members. He keeps the team running smoothly. A good engine oil keeps the parts well lubricated even when the engine is running at a high RPM, the temperature is high, the stress is high. Similarly, a good ScrumMaster ensure that the practices are followed even when the team is under stress (the scenario of the team being under stress is infrequent but possible when the team commits to deliver more than they can complete so as to meet the aggressive goal).

Where does the Product Owner fit in? I believe he is like the handlebar of the motorcycle. The product owner provides direction to the team. It leads the team to the intended goal. If the team deviates, it provides correction (during Sprint Reviews) so that the overall destination can be reached. The way a handlebar can be used to avoid obstacles along the path, the product owner can clarify the doubts of the team to keep them focussed on the right goal.

Of course, there are a lot of other parts in a motorcycle, and many more and varied parallels can be drawn, but this is what struck me. If you keep the above in prime condition, you can assure yourself of a smooth journey. Ride hard, ride well.

Becoming a Certified Scrum Professional

Follow the Road

Considering the increasing number of companies practicing Agile, getting a ScrumMaster on the rolls has almost become mandatory. Consequently, lot of people (including PMPs) are getting themselves certified as ScrumMaster (or Certified Scrum Developers / Certified Scrum Product Owners) . After two days training and passing the exam, they consider the job done. If you are one of them, then your journey has only started, my friend.

While becoming a Certified ScrumMaster is relatively simple and straightforward, becoming a Certified Scrum Professional is a different ballgame altogether. If you pay attention during the two day training, you can pass the CSM exam with flying colours. CSP, however requires constant practice. If the input for the CSM exam was theory, then its practice is the input for CSP exam. Consider an analogy – most of us would have studied trigonometry in school or college; how many of us can find the distance to an object close by using triangulation. The inability stems from lack of practice.

CSM training throws a lot of jargons at you – product backlog, burndown chart, sprint planning, etc. It all sounds great during the training. You understand it and take the exam. Get certified and then sit back and relax. Not so fast, mate.

The two-day training should act as only an appetiser. You are yet to enjoy your full course as part of the on-job-training when you practice what you have learnt. You may have a product backlog but you don’t’ spend enough time grooming it. You practice sprints but every once in a while you let it extend for a day or two as the team wasn’t able to finish everything they had committed. You estimate stories but the estimates are not provided by the team. I remember talking to a friend who, on knowing that my company practiced Agile, was boasting about the Agile practices at his company. I simply asked, “who estimates the stories”. Prompt came the reply, “the client”! I wish we were talking face to face rather than on phone and he could see my jaw drop.

Even though the title of the certification has only “Scrum” in it, it also requires a fair brush with methodologies that go well with Scrum, for example eXtreme Programming (XP). I don’t really think that Scrum talks about automation or test driven development but you can’t be fully Agile without it. Lean thinking again works well with Scrum. “Lean inventories” is mirrored in Scrum by having stories detailed just enough to drive conversations, to have stories only higher up in the backlog as detailed and the lower ones as coarse grained. Yes, you learnt about it during your CSM training, but are you practicing it?

ScrumAlliance provides a list of books / articles, one should be well versed with before taking the CSP exam. But that is only a guideline (just like the Agile Manifesto). You need to have a good exposure to Agile practices if you want to earn your certification. The questions are not from a theory book. They are based on scenarios. And most of the times, all the options provided are right. Your experience would tell you which option is the best.
When I got certified as a CSM about 3 years back, I thought I knew it all. But today, after receiving my CSP certification, I can say with full confidence that the CSM was only a spark, the noodles were cooked by a steady practice, observing and stirring (or in terms of Agile – inspecting and adapting).

If you have noticed the number of times I have used the word practice in various forms in this article, you would realise what I am trying to tell you. So my humble suggestion to you is to earn your CSP certification by going through the motions of Agile practices. Follow the road amigo, not the steps.

Faster is Slower

Hourglass

We have all read that story during our childhood where a fast rabbit (or was it a hare) was beaten by a slow, yet steady, tortoise. The importance of sustainable progress was taught to us well in advance but we forgot the lesson while growing up.

We are so rushed about everything that we have forgotten the pleasure of enjoying the moment. Hang on, this blog post is turning into a lecture on “living in the moment”. Well, that’s not what it is going to be. It’s going to be about the challenges I have been facing with some projects while trying to match an aggressive timeline set by the client.

At present, I am managing two projects for a client based out of Nigeria. One of the two projects is a daily-deal web application and the other is an e-commerce site. Both these applications are doing fairly well and generating a sizeable revenue to the client. And the company I work for is happy too, well, at least financially.

But these projects are becoming a death march despite my desperate efforts to the contrary. (I didn’t know Wikipedia had a page on death march in project management).

I can see the development team working till late everyday. The code quality is going down. Time is being spent more on fixing bugs than writing features.

My initial thoughts on this state were that perhaps the team is doing a shoddy job, delivering poor quality work that too late. Which is why they are having to work late to meet the deadline. But I was wrong. Mea culpa.

The whole problem is with the deadline. The word has actually begun to signify a point in the future beyond which lies death.

The whole situation starts like this: the client has a brilliant idea (every month or so) that needs to be taken to the market immediately. The team is expected to start coding even before they have a firm grasp of what they are working on. All this can still make sense as Agile is meant to allow, in fact welcome, frequent change. But not when all the 3 sides of the iron triangle (scope, resources, and time) are set by the client thus strangulating quality that lies within the triangle.

The developers (considering themselves a part of the same team as the client and equally responsible for its success) agree to the deadline often factoring in extra hours in a day and a few Saturdays. Even at this juncture everything looks possible; a stretch goal but possible.

While they are in the middle of the release, suddenly a mail comes announcing some hotfixes (a fix or a quick feature that needs to be deployed to the production site ASAP and has priority over current release / features). The team, again feeling responsible for the application, does those fixes. But the tragedy of this whole story is that the darned deadline doesn’t move a minute!

Mike Cohn, a highly respected writer, speaker, and practitioner of Agile, wrote the following in his book Agile Estimation and Planning:
Leave some slack. Especially when planning an iteration, do not plan on using 100% of every team member’s time. Just as a highway experiences grid- lock when filled to 100% capacity, so will a development team slow down when every person’s time is planned to be used.

This is where we are going wrong. Not only we factor the full eight hours per day of each team member, we also include a couple more so as to meet the deadline. Which is why we never have enough time to write good code in the first place, do a thorough code review, or test the app well. In some cases, unit tests are skipped altogether so as to deliver on time.

This is why I have begun to realise that in trying to become faster, we have become much slower. While we somehow manage to deliver on schedule, a lot of issues that should have been taken care of before releasing to production are looked at after the release. Thus the point of stability moves to well beyond what could have been a justified release date or the deadline with a reduced scope. And it causes heartburn to everyone: to the users who face issues due to buggy code, the client who faces user’s complaints, and the dev team who work day-in day-out.

I have actually experienced an automobile analogy of the above. I had to meet someone at a destined place and time. In order to avoid being late, I rode my motorbike much faster than I normally would only to get into an accident. The meeting got cancelled, my motorbike got damaged, and I got hurt. Faster became slower and expensive.

Considering the software context again, the client frequently gives the example of Apple as a benchmark of quality. However, in trying to attain that benchmark, I would not let my organisation become Foxconn. The team has had enough and I have had enough. It’s time to take a stand even if it means like the one below:

Hold Strong

Image Source: http://www.wsm.ie

Product Owner 2.0 – Ownership and Beyond

Product Owner 2.0

I had the opportunity to present on this topic recently at a ScrumIndia Conference organised in NCR, India.

As part of my current role of a Project Manager, I have been playing the role of Product Owner for all the projects I have been managing. I started as the vanilla Product Owner that Scrum outlines; continuing to improvise when hit by an obstacle or looking for opportunities to improve. It has been a tremendous learning experience while working with all kinds of clients and teams of different maturity levels on projects of various complexities. My presentation at the conference talked about such practices / beliefs / views.

My experience has primarily been on client projects rather than on internal projects / products. So, to that extent, my perspective might be skewed. But, in my humble opinion, the points I illustrate are independent of the sponsor of the project (external or internal).

So lets start…

Summarising the literature that is available on Agile, one can define the typical role of PO as follows:

  • Responsible for maximizing the value of the work that the Team does
  • Owns the vision and overall goals
  • Owns the prioritized list of what needs to be produced to achieve maximum value and ROI (the Product Backlog)
  • Decides when product is ready to ship

Now, lets see what would separate a PO 2.0 from a PO:

1. PO stands for Proud Owner

Proud Owner

PO doesn’t stand for just Product Owner. It also stands for Proud Owner.

PO 2.0 doesn’t consider a project as just one of the many. He is proud to be a part of it. Like Harley owners who consider themselves privileged to own one (I am a Bulleteer myself so I know the feeling), the PO wears the project name on his sleeve and at times even flaunts it (I have done that a couple of times 😉 )

2. Says NO to Feature Requests

Usage of Features
How frequently features built into a software are used

A PO is meant to define the product by prioritising the features that would go into a product. While a traditional PO would blindly go forward with a feature request from the sponsor, PO 2.0 would actively say no to features that he feels would not add significant value to the project. So, he wouldn’t go by the sponsor’s whims and fancies but base his decisions on logic and past experience. The above graphic illustrates why its best to say no to some feature requests.

Many a times I have had feature requests that I have found to be frivolous or for one-time use only. I have always preferred simplicity in such scenarios. For example, instead of providing an email editing functionality to the admin for an email that would be sent only once, I preferred taking the content and design from the client and having the devs trigger it themselves.

3. Takes Input from the TEAM

Team

A PO is expected to take his inputs from the client and prioritise that for devs to work on. However, PO 2.0 also takes input from the team. They are where the rubber meets the road. Sometimes, they can provide critical insight into what feature to add and what to remove in order to make the whole product sharper.

On a recent e-commerce project, the team pointed out that we should include the product categories and brands into meta tags for products as that would be helpful on the SEO front. Quite a sensible advise, I would say.

4. Creates for Himself

Basecamp-Blinksale

PO 2.0 doesn’t work for someone else. He works for himself, even when he is the surrogate client. He takes the term “Product Owner” to its literal meaning. It is this belief in his heart that motivates his decisions. When the guys at 37Signals went about creating a project management tool for themselves, they ended up creating one that has now earned the love of millions of people around the globe. Ditto with Blinksale.

When I am envisioning the Information Architecture of a project or ruminating about a feature, I alway keep in mind, “how would I like it; how would I prefer to use it”.

5. Defends the Product

Defend

This ties in closely with my points 1 and 4 above. PO 2.0 is as passionate about the product as the sponsor / client. Which is why he considers it his responsibility to defend the product. Its his baby too and he would not let any harm come to it.

Sometime back, we had launched a project that drew a lot of attention, some good and some bad. I came across this blogger who was ranting about the application while knowing zilch about it. I wrote back to him clarifying all his points with links to the relevant sections on the app. Never got a response back from him but further comments from readers were heartening.

6. Is the SCRUM MASTER

PO-SM

I would wait while you get some air ‘cos I know you would have gasped on reading this!

Scrum framework details the roles and responsibilities for a Product Owner and a ScrumMaster. However, I am yet to find a scenario where they contradict each other. It is widely held that the PO and SM should be different persons but I have been performing these 2 roles for so many years now and on so many projects and have been successful all along.

I don’t subscribe to the view that the PO is supposed to be pushy about features and at loggerheads with the SM. I have tried to balance these two roles and successfully so.

I would take your leave now so that you can ponder over that last thought…

You can download the slide deck I had presented here. (size: 3.2MB)

Image Sources:

Does Agile Manifesto Need Changes? The 10 Years Experience!

AgileManifesto10

I delivered a presentation on the above topic earlier this year at an Agile Conference in NCR, India.

I have summed up my thoughts below.

On a cold winter morning of 13 Feb 2001, at a ski resort in Utah, the Agile Manifesto was born.

The newborn had 17 fathers (ahem ahem), all stalwarts of the software industry, trying to be Agile in their own way, ahead of their times.

Though some leading software practitioners were following some form of Agile (without calling it that), the real precipitation of thoughts happened in February 2001.

And thus emerged the Agile methodology of software development as we have come to know it.

In 2011, while the whole Agile community was united in celebration of 10 years of Agile, there were a lot of Agile practitioners who felt the need for a change – maybe a change from Agile to another methodology (like Agile was to Waterfall), or changes in the basic foundation of Agile (the Agile Manifesto and its 12 core principles).

This whole dissonance stemmed from not achieving the kind of success we had hoped for.

Their concerns did resonate with me but when I dug a little deeper, I realised that difference between our results and expectations arose from the way Agile was implemented, the way it was morphed into something else, a commonly known phenomena as “Agile-but”. (You might have hears people saying, “we do Agile but….instead of X we do Y”).

It is completely okay to let Agile fit your organisation as it is not a set of commandments one ought to follow. But there is a “spirit” that is embodied in the Manifesto and the principles which should never be compromised.

I agree that it is really tough to explain that spirit in words but you would get a sense of it once you start “living” Agile, not just following it, or doing it, or practicing it.

(God, I am sounding like Yoda instructing Luke Skywalker: You must feel the Force around you. Here, between you, me, the tree, the rock… everywhere!”)

While I was preparing for this presentation, I came across a wonderful tongue-in-cheek take on Agile.

We have heard about new ways of developing software bypaying consultants and reading Gartner reports. Through
this we have been told to value:

Individuals and interactions over processes and tools
and we have mandatory processes and tools to control how those
individuals (we prefer the term ‘resources’) interact

Working software over comprehensive documentation
as long as that software is comprehensively documented

Customer collaboration over contract negotiation
within the boundaries of strict contracts, of course, and subject to rigorous change control

Responding to change over following a plan
provided a detailed plan is in place to respond to the change, and it is followed precisely

That is, while the items on the left sound nice
in theory, we’re an enterprise company, and there’s
no way we’re letting go of the items on the right.

The above conveys my sentiments on the current state of “Agile” well.

And let me not stop there.

I have come across enough real-life examples to illustrate this.

These examples are from companies / projects based on Agile methodology.

I have mentioned them under the statement that they seem to violate

Individuals And Interactions Over Processes And Tools

  1. “This part was not implemented because it was not written in the user story. So what if it was discussed.”
  2. “Please create a ticket/story for whatever you want to be done”
  3. QA/Tester: “Wait. Don’t fix the issue now. Let me first create a ticket on it”

Working Software Over Comprehensive Documentation

1. “We are Agile. We don’t document”
  2. “User stories need to include even the last bit of detail”
  3. After a sequence of changes over time with a functionality, “Make sure you reflect the changes in the stories”

Customer Collaboration Over Contract Negotiation

  1. “Lets write detailed user stories about the features that would go into the project so that the customer/developer is bound by them”…(later)…“Hey, that was not in the scope”

Responding To Change Over Following A Plan

1. “We are Agile. We don’t plan”…(LOL)
  2. “We never discussed this feature”
  3. “I don’t care if your system crashed, I want this functionality delivered by weekend”

I would like to share a quote that, I believe, truly represents that spirit of being Agile

Float like a butterfly,
sting like a bee
– Boxing Legend Muhammad Ali.

Wrapping this up, saying that Agile needs change when we were not able to implement it properly is akin to saying that one has wrong feet when he is wearing shoes wrongly.