Agile, are we truly?

Everyone is talking about going agile but how exactly are we supposed to adopt it? Often, I see teams touting the word, expressing its manifold benefits in product delivery and efficiency while in fact, the reality is quite the opposite. Not only do teams fail to reap the benefits of the framework, they end up being burnout from having to adhere to ceremonies like daily stand ups and weekly retros religiously while still having to catch up with an endless list of tasks.

Agile is simple. After all, it's only a framework and not a methodology. In the article The Agile Mindset, I highlighted the mindset it prescribes and how to adopt it using Scrum as an example. On the surface, it's easy to follow the ceremonies to the letter but you will never achieve its intended outcomes and benefits. If you truly embrace the mindset, you will find that the same mindset can be applied differently from one team or project to another depending on the approach that suits best.

Given the versatilty of the framework, it's easy to lose track of how you are doing as a team; if you are in doubt, here is how you can do a pulse check.

Are there hard deadlines?

Agile and deadlines do not go well together. In fact, the main reason you would be agile in the first place is to deal with the uncertainties you have, which often means you don't know exactly how long your project will span given there is no end in sight.

If you have a pre-determined hard deadline to launch your app, you’re better off executing the workload in a waterfall manner as it allows you to anticipate every step along the way and exactly what could go wrong in the project, thus giving you the opportunity to plan everything ahead. If you know there is a specific, inter-dependable set of tasks to accomplish by a certain date, which without all else would fail, it's likely you're better off adopting the waterfall approach.

Agile is all about iterations. You cannot have a hard deadline and at the same time conduct weekly sprints or retros in the guise of being agile. Realistically, you’re only wasting your time on ceremonies that are deemed mandatory. This adds no value to the team as no matter how many retros you conduct in an effort to eradicate unfavourable behaviours and improve your workflow, the team is bound to fall back to the most familiar approach they know if they have to work against time to deliver new features or bug fixes. There is simply no room for any form of elastic thinking or time to adopt new approaches regardless of how well-meaning they are.

But wait.

There is no doubt that deadlines exist in any business. If not in engineering or product, the business development and marketing team have to make certain time-bound commitments to external stakeholders and the press to arrange for a product launch, for instance. However, understanding these deadlines for what they are makes all the difference in applying Agile effectively.

Let's start by separating a single, common product timeline into two - one for product development and the other for the business and marketing team. Let’s be clear. The concept of hard deadlines can and should remain within the business and marketing realm as they most definitely need to anticipate what products or features they will be promoting for and when. Such campaigns are time-sensitive, hence strict timelines need to be adhered to.

As for the company’s internal engine i.e. the engineering department or where products are developed, the only deadline that matters is the sprint deadline which is typically a week or two away (remember it's up to the product manager to carve these sprints up in any way she or he sees fit). In each sprint, the engineering team is geared towards delivering an iteration of the product. The quicker you adopt this mindset, the quicker you can start testing your product iterations and adapt to customers' feedbacks.

Do you have a self-organising team?

The centre of it all is the product team. They are the orchestrators between the business and technical team. The product team is predominantly responsible for communicating new features that will be developed with the marketing and engineering team, based on their product strategy and roadmap. At this stage, the exact features that will be developed and product readiness are not as important as knowing what to anticipate in the coming sprints and understanding the overall product strategy as an organisation.

For as long as all teams are on board and are made aware of the ten or so features that the product team intends to release in their exact order, each team should have the necessary tools and means to start paving the way for these releases. For example, if the technical team is building a feature to support 3 languages, the marketing team may decide to release them sequentially according to the business expansion plan. Also, not all features and functionalities developed by the product and engineering team gets released to the public. Some features are built to support internal operations that would go largely unnoticed to the public. Given this information, the marketing team will focus their efforts only on upselling value-added features on top of existing product features.

In an agile team, there should be a continuous pipeline of tasks and activities to accomplish, and this is not limited to product and engineering sprints. If you find yourself constantly needing to have features readily built before the marketing team can start mobilising, that’s a red flag that indicates something isn’t quite right in the way the different teams are collaborating. After all, pre-orders are not a foreign concept. If you are unable to get customers to pre-order your product before it is market-ready, you have failed to create an anticipation, and you’ll most likely find yourself force-feeding your product into the market after it is built - a reactive approach that does not sit well with Agile frameworks where proactiveness is always preferred.

Similarly, say after completing 3 releases, if you run out of tasks to perform and instead can only wait for bug fixes as and when they are being reported, you are simply not agile as a team.

How do you obtain customer feedback?

Obtaining feedback at every step of the production cycle is also part of being proactive and agile. It is what product managers do to get a sense of whether the team is building the right thing for the intended customers or whether it is something they would reject.

Coming up with features you think would sell - on its own - does not guarantee customer acceptance. You may have already done your market research and validated your idea with a few number of interviewees, be it externally or internally, and they have probably seen your prototype on InVision and provided you their feedbacks. However, nothing beats having something tangible in the hands of actual customers where they can have a glimpse your product even before it is ready. This is where minimum viable products (MVPs) are useful to test the waters.

MVPs are the smallest ‘amount’ of the proposed product that you put out in the market to obtain user feedback and test assumptions in the fastest way possible. They can take many forms including a fake website landing page, a coming soon page and an explainer video. It builds on the premise that the sooner you can test the market, the sooner you can collect data, fail, and iterate.

Since MVPs are meant to be lean, they should be reserved only to showcase the most important feature(s) of your product, as opposed to every single one of them. That goes without saying that the highlighted feature(s) should coincide with the minimum criteria for success you have set for your product. Both qualitative and quantitative data that you collect at this stage should feed into your product decision-making process.

A word of caution: Though there is a strong focus on speed when it comes to testing the market with MVPs, having a functional MVP that mimics the actual feature is more important than having a half-baked MVP for the sake of testing it. For instance, if you are building a feature for password reset but your user interface is not optimal, it’s better to wait than to give a lasting negative first impression of your product.

How do you navigate between dependencies?

Needless to say, Agile frameworks do not take the pain of dependencies away but it only provides a mindset to workaround those dependencies. There’s no denying that testers will never be able to test a feature that is yet to be developed. Similarly, frontend engineers cannot codify a design that hasn’t been completed yet.

Dependencies will exist indefinitely and the sooner you accept this as a fact, the happier your team will become. Agile iterations are not intended to remove these dependencies but rather to create room for other members to work on something else while a certain dependency is being resolved. Ideally, the output of one member or team becomes the input of another, this way, all team members or teams are either working on items to be passed along to the next team in the process flow, or they are working on items that had been passed on to them by others. Either way, everyone is working in iterations either individually or as a team.

Putting it all together: how Apple does it

The best example of an agile mindset can probably be taken from Apple, more specifically in the way they introduce their latest software products in their annual conference, and how they release these products throughout the year.

Every year around June, Apple will host their Word Wide Developer Conference (WWDC) where they would showcase upcoming products such as iPhoneOS (iOS) and MacOS. Notice that there are no actual releases during the event, instead, Apple would only showcase a teaser of what the improved product (new code) can do. The actual release of the software usually happens between September to October every year for different categories of their products - 3 to 4 months after the teaser showcase.

Let’s dissect Apple’s strategy and uncover the benefits they stand to gain by releasing their products in this manner.

Communicating the whole product vision within an organisation, and to the customers

First, it’s likely that when Apple announces a new software product during WWDC, the product is not even market-ready yet. Surely, they may have working versions of it as their engineers work on iterations after iterations, adding incremental features every week or two. However, the whole product may not even be ready for production during this time which explains why the actual release only happens later on.

Even before the whole product takes shape, the product team is already able to create awareness among the engineering and marketing team on what to expect in the upcoming release. From the public perspective, this is evident in how successfully Apple’s marketing team brings these features to life through their creative and extravagant showcase of their new technology and practical use cases. Note how their marketing approach only emphasises the final and complete product, not work in progress.

You must be wondering how Apple manages to pull off the demo of these features as though they already exist. While I can’t say for sure but it’s likely that the demo is 'staged'. Rapid prototyping is not a foreign idea to techies and we can create the perfect demo using prototyping tools like InVision where we can preconfigure the flow of multiple screens, creating the perfect illusion of a working solution.

Using this ‘teaser’ approach, Apple is able to create anticipation among its ardent followers before the product launch, captivating them with the brand's product vision. Imagine if Apple were to release their software upgrades on the same day as the product introduction. It's unlikely that the brand would have had created any product awareness prior to the launch e.g. the pros and cons of the upgrade, requirements and limitations, and how the upgrade affects the current system and the way customers interact with the product. It's a risky gamble considering customers may be left confused and hesitant to adopt the feature, fearing the upgrade might just wipe out their important work files!

Seeking customer feedback from a small sample of users and continuously iterate prior to the launch

This is where we can also clearly see the agility in how Apple delivers their software updates, beyond the teasers during WWDC. After WWDC, Apple will start publishing incremental software updates or beta versions, and make them available to their developer community to test them out in the run up to the product launch. This allows Apple to receive feedbacks from actual customers and action upon them in an iterative manner over the next 3 to 4 months.

Testing in a smaller group also has another obvious advantage which is to contain undesired system behaviour within a smaller sample of customers before it gets published to the masses. You have probably seen blog threads where users advise others not to upgrade their software due to bugs or incompatibilities to their devices. Having such negative publicity before the product launch can be damaging to product marketing efforts, therefore, the process needs to be tactfully managed. Remember, first impression always counts.

In fact, Apple iterates up to 8 times or possibly more in the span of 3 months between WWDC and the product launch. It is common for new products or features to have defects and unintended behaviours which explains why iterations of software updates are required. It is also not unheard of for Apple to retract certain features they initially thought would be game-changing, but turn out to get in the way of their customers' already familiar workflows (product managers should take comfort knowing that it's okay to let go of a beloved feature even after it has passed the initial validation test).

Beyond the launch, iterate, iterate, iterate

So what happens beyond the launch? As mentioned earlier, being in an agile team, you never should run out of tasks to perform even after the product launch. The product and engineering team will continuously iterate to deliver the remaining product features as committed.

In the case of Apple, it's not unusual that some product features, despite being showcased during WWDC, do not get published until much later. For instance, in the last WWDC, I was awed by the inter-operability functionality between different Apple devices. However, after the supposed product launch in September 2021, we are yet to see this in action, and can only crave for it.

Final thoughts

Agile perceives deadlines differently than project managers. While having a fixed go-live date is important, working towards the deadline from a delivery standpoint can cause a lot of pain.

Agile invites you to break that mindset into smaller chunks with shorter deadlines, each working towards an incremental change or improvement. Having said that, Agile frameworks which is the preferred approach for product delivery, can still work hand in hand with waterfall-ish time-bound commitments that business and marketing executives cannot escape from. As seen from the Apple example, adopting an agile-driven marketing approach can facilitate the adoption of the mindset throughout your organisation while still being able to deliver on the promise.

The key to coordinating between these different teams and work requirements is the product team; tasked with the art of balancing between business deliverables on a deadline, and what engineers are supposed to be concerned about. All of this is possible if both the business and technical teams understand the whole product vision before they execute it in their own way.

Marketing requires the full picture in order to strategise their positioning and get creative in the way they communicate with customers through compelling use cases across different channels. On the other hand, engineers require this vision to plan and build the product in a way that allows the product team to validate certain assumptions, test their hypotheses and collect data as fast as possible to feed into the product decision-making process.

By acknowledging the different nature in how these teams operate with the help of the product team, it becomes easier to create an incremental and iterative product release cycle that can create anticipation months before a product launch, and at the same time deliver the features as promised when the time comes.

Having such level of clarity and respect for each others’ roles and working requirements will only lead to a happier, more fulfilling work culture.