The Enterprise Relies on Atlassian and Appfire

We were recently in New York City visiting with one of our customers and I couldn't help but reflect on how far both Atlassian and Appfire have come with the delivery of Atlassian-based solutions within the Enterprise.  Hard to believe, but it's been over 5 years since our first enterprise deployment of Atlassian tools. I'll be the first to admit that in looking back, it was a gamble.

In a recent conversation with Alex Estevez (Atlassian's newly appointed CFO), I explained how over the years Appfire has helped drive Atlassian into the Enterprise. During our conversation, I used the phrase: "our leap of faith".

So, why did we do it? What motivated us to take on the Enterprise in Atlassian's largest market segment (North America)?

Experience - There Simply is no Substitution

We are fortunate to have assembled an amazing team here at Appfire - comprised of engineers and advisers who come from some of the world's largest enterprise organizations. It's that experience, which allows us to fully appreciate the challenges and complexities associated with building product within global, desperate organizations - who struggle to balance the sea of changing priorities, resource restrictions, communication breakdowns and re-orgs. We were there not too long ago.

As I mentioned to Alex... "we came from the Enterprise". Our team was there when all the rules changed and we realized something very real, and very special. We learned that collaboration tools, combined with the adoption of new methodologies would be required in order for the Enterprise to remain competitive, ... or as I like to say "sit above the fold".

To maintain a strong global position, shrinking enterprise organizations were required to:

• Make immediate adjustments in the way they operate day-to-day
• Learn how to work transparently
• Set proper expectations within their organization and make schedules more predictable
• Hold themselves and their teams accountable for the commitments they made
• Introduce a level of traceability throughout their process

There was little doubt in anyone's mind at the time that the rules had indeed changed. The only doubt was whether these organizations could adjust and rely on new tooling and new methodologies to support the required acceleration in product development.

Perspective - It Makes Tough Questions Really Simple to Answer

I'm frequently asked whether or not "Atlassian tools belong in the Enterprise", or "if they're ready"?

When I'm asked this, I like to refer back to a conversation I had with an architect at a large financial institution. At the time, we were working with them on a wide-scale deployment of Confluence. I was sitting in our customer's conference room, filled with project stakeholders, and the architect looked across at me and said:

"... Randall, can you please explain why we're having performance problems with Confluence. I would expect a product, especially an enterprise product to scale out of the box!"

He went on to say:

"... I don't know of a single enterprise product that doesn't scale once installed!".

This is where perspective comes in handy.

My response was this:

"... Really? I know of plenty. Take Oracle for instance. Oracle, (in their own words) make the world's most scalable, dependable, unbreakable database on the planet. Their products have been around for three decades. I personally don't know of a single global fortune company that doesn't rely on one or more Oracle products? I've also worked with several of these fortune organizations and they were just as surprised to find that their out-of-the-box Oracle product wouldn't scale without some sort of intervention."

In fact in a past life, I made a healthy living traveling the US, parachuting into some of Oracle's largest accounts to help with scalability concerns. Did this mean that Oracle at the time didn't belong, or wasn't ready for the Enterprise? Of course not!

Fast forward to today and I see similar things with respect to performance and scalability with Atlassian, as I did while working with Oracle. Customers who have incorrect expectations about Atlassian's products. Missing or missed configuration settings. Untrained users. Customers trying to use the products improperly, falling victim to one or more anti-patterns.

Perspective has taught me to understand that the answer to the question of whether or not a product "belongs" or is "ready" for the Enterprise depends on both the direct and indirect value it provides to the organization.

Atlassian's products help accelerate product development within any sized organization, and because of this, our enterprise customers have found a great deal of value their use. The fact is, each day, Atlassian and Appfire see more and more large organizations adopting Atlassian's tools.

Here are two awesome examples of Atlassian being used within the Enterprise.

Partnership - It's More Than a Word

Appfire wouldn't be Atlassian's largest and leading provider of enterprise solutions in North America if it wasn't for the 400+ amazing Atlassian's who support us each day! Their commitment to their products, their partners, their customers (and ours) - is what gives us the confidence to deliver awesome solutions to the Enterprise day in and day out.

Read more or contact Appfire to learn about how the Enterprise relies on Atlassian and Appfire!

Your Backlog and the Commitments You Make

In recent weeks, I've been focused on your backlog. Specifically, encouraging you to grow it and offering up effective ways to work with it.

Why? Well, to me a backlog represents your product's future and it's not something that should not be taken lightly. The contents and quality of your backlog are a clear indication of how invested your organization is in the future of your products. When teams embrace their backlogs and invest in them, what they are really doing is securing a place for their products future.

Put simply, products without backlogs will eventually disappear.

Grow it!

In my first post, I wrote about the importance of "building it bigger". A bigger product backlog allows your team to plan ahead of your active Sprint. Looking ahead allows you to make important adjustments to your product, marketing and sales plans, which in turn helps to protect the interest of your product and everyone involved.

Organize and Work With It

My second post described how you can take control of your backlog, organize it, and begin to
"work with it". Within that post I walked you through a process that I use, and have found success with, while managing large backlogs. It also stressed the importance of "seeing" your backlog.

Commitments Made Against It

Although building bigger and working with your backlog are vital to the success and future of your products, so too are the commitments that are made against your backlog.

At Appfire, we help the Enterprise ease into, stabilize, and reach their "Agile Nirvana" by leveraging Altassian tools. While working with our customers, we often witness commitments against the backlog which should never have been made. Commitments, with promises to deliver specific features within your product.

Commitment [kuh-mit-muh nt] noun - a pledge or promise; obligation

It's a common mistake, and even though it's unintentional, unfulfilled commitments can jeopardize the credibility of your product organization.

Don't get me wrong, I'm not saying teams shouldn't commit to delivering features within a release or across a set of releases. No, what I'm saying is don't commit to delivering specific solutions before you are certain they can be achieved. Instead, only commit to delivering headline goals.

For example, as a product owner, let's say you sit down with your sales and marketing team to highlight future releases. Instead of describing in great detail how a new feature will work, how it will function, what it will look like, how the user will interact with it, how many clicks, how many buttons, the exact dimensions, etc. - you should instead simply provide them with a high-level description of the feature, it's purpose, and it's value within the context of your product. By doing so, you are much more likely to set proper upfront expectations and avoid disappointment.

As you get further into your release cycle, and as feature development is underway, you can then begin to unveil and discuss how a feature will function.

Your backlog is a critical component to the success of your organization. Grow it, see it and be mindful of the commitments you make against it!

Confluence 4 is Enterprise Ready

Atlassian's latest 4.0 release of Confluence is Powerful, Stable and Scalable for the Enterprise.Each year Appfire works with hundreds of enterprise organizations to support their collaboration goals. Over the years, we've watched the Enterprise learn to embrace collaboration and begin to move tooling towards the center of their strategies.

When it comes to the adoption of new product versions, or change in general for that matter, our customers are not what you'd consider "early adopters", nor would you consider them the "early majority". They typically fit within either the "late majority" or "laggard" segments of the market. They're typically risk adverse. Given their size, distribution, and what's at stake, I can't say I blame them.

Confluence as a Critical Building Block

Most of our customers leverage Atlassian's Confluence as a primary collaboration platform. For some, Confluence acts as a communication conduit between product, engineering, quality, and operations teams. Others rely on Confluence to host information derived during inception or elaboration phases. In all cases, we see Confluence helping to accelerate product development.

Because of the role it plays within these organizations, Confluence is a platform that most consider "critical" to their business, and therefore, they must be vigilant about how and when they apply upgrades to the product. Our customers' current Confluence versions typically range from 12 to 36 months behind the latest release point.

So, you can imagine how shocked I was to learn that we had already received 3 phone calls from enterprise customers the day that Confluence 4 was announced this week, asking if they could be added to the top of our upgrade list!

A Shift in the Enterprise

So why the sudden change?

What motivated these large organizations to call and push for this release so quickly? What could possibly be tempting them to look past their rigid standards and adopt something brand new to the market?

Those of you familiar with Confluence 4's new features might be reading this post and saying to yourself: "Well of course! It's because of the new "@mentions", or "...the new editor", or "...add-ons", or "...no more wiki markup".

Sure, all of these exciting new features are certainly a compelling reason to upgrade, but Atlassian has released hundreds of awesome features in the past. If features were truly the reason, surely we would have witnessed a similar response with previous Confluence releases.

However, that's not what's happening here. What's happening here is a shift!

It's the realization that Confluence as a product, as a platform, as a primary mechanism for enabling collaboration within the Enterprise has matured.

Companies have witnessed a steady track-record of successful, stable releases of the product and they've learned to trust new GA versions of Confluence. IT organizations within the Enterprise don't delay their upgrades for critical platforms so they can starve users of new features. They do it so they can wait for the product to gain market adoption and harden. So that critical defects can be shaken out. So that incompatibilities can be discovered. They do it to mitigate risk.

To me, this shift is a clear signal that the Enterprise has finally found a collaboration solution which provides as much benefit to the teams who manage the tools, as it does to the end users who leverage them.

Atlassian promotes that Confluence 4 is Faster. Richer. Simpler.

At Appfire, we say Confluence 4 is Powerful. Stable. Scalable.

Working with Large Unscheduled Backlogs - Start by Seeing It

A few weeks back I blogged my advice to make "building a bigger backlog" your summer project for this year. Well, summer's officially over and hopefully you're now staring at an impressive list of new goals for your products.

Right now, some of you may be overwhelmed with the amount of items contributed. For many, this may be the largest volume of epics and stories you've ever worked with. Staring at your list, eyes glazed, you might be thinking: What next? How do I organize? How to prioritize? What do I commit to? or even Where the f*** did that story come from? Working with large backlogs can invoke feelings that are similar to staring at a huge sink full of dirty dishes. Am I right?

First of all, don't worry, because you're not alone. It's perfectly natural to feel a bit overwhelmed at first. For many, this is largely due to how the mind copes with large lists of electronic information presented all at once. What we first need to do is pair the list down into smaller, more easily digestible and manageable chunks of information. We need to give our eyes less information to look at, so we can process it more efficiently and swiftly.

Over the years, I've devised a very quick and simple method for working with large backlogs which I'd like to share. When working with our customers, I often mention that the best way to work with a large backlog is to start by seeing it!

It's hard to process or efficiently take action against a list that can contain hundreds (or thousands, as is the case with some of our customers) of stories. To do so, you need to be able to apply various filters against this list in order to manage and quickly take action on the stories contained within. I typically filter stories within backlogs in three ways:

• By Epic
• By Segment
• By Value

Of course, in order for these filters to work properly, you have some work to do.

Associate like Stories with Epics

Your first task is to scan the list and associate each story with an epic. If you can't find a fit between a certain story and an existing epic, you should either create a new epic, or just flag the story so you can review it again after you finish processing the remaining list. Here at Appfire we use Atlassian's GreenHopper, which allows us to flag stories by applying "labels" to them.

When I come across stories that I can't match to an existing epic, I usually label them as "orphans", so I can quickly search and build a list to manage them at a future point in time. During this first pass, you shouldn't add new or modify existing stories. Instead, just focus on this upper-level grouping of stories to epics.

Segment your Stories

Now that you have your stories associated with epics, your next step is to quickly segment them into various "logical groupings" or buckets. By doing so, not only will you be able to quickly isolate one segment from another, but you'll also find that it helps you focus and take action on stories, moving them closer to scheduling. Note that this is not a physical segmentation of data, but rather a logical one, using flags or labels (or whatever feature your tool supports). Personally, I like to segment stories into the following five major buckets:

1. Completed Stories

Stories should be segmented into the "completed" bucket once you're happy with the detail and definition of the story. Although marked "completed", they of course still require action. They require prioritization, estimates, points, and further downstream you'll need to associate tasks.

2. Incomplete Stories

A segment of stories which require additional refinement, or expansion to the actual story, before they can be reviewed by a larger team and have effort or story points assigned.

3. Large Stories

Lengthy stories may be difficult for teams to digest and work with. When you come across stories like this, I often suggest breaking them up into smaller ones. All too often, I see teams struggling to comprehend, assess complexity, define tasks, and assign resources simply because their stories are defined at too high a level. As a Product Owner, it can be difficult to break stories into small pieces. By segmenting them, you can task others within your organization to help you with this work.

4. Sounds like Another Story, Stories

While segmenting your backlog, it's not uncommon to find duplicate or near duplicate stories. When found, you should try to merge these records into a single one. However, if you have a legitimate reason not to consolidate, then at a minimum, you should consider segmenting these stories from others so you can isolate and work with them in the future.

5. WTF Stories

If you stumble upon one of those WTF stories, where you aren't sure how or why it ended up in your backlog, your natural reaction may be to remove the story from your list. Don't delete it. Instead flag or label this record for a future review. It may feel better to reduce your lengthy list, but after some time, you may recall why this story was added.

Helpful Hint: When segmenting your backlog, you may be tempted to author new stories, that your team overlooked while growing it. I would encourage you to simply add a placeholder with a label, so you can return to complete the story at a future date. This will allow you better focus on the exercise of segmenting your stories.

Assign Value to your Completed Stories

As a Product Owner, you need to assign a value to each story within your "completed" segment. I say against the "completed" segment because all other segments will require additional action before it makes sense to assign this value. Of these filters, this in my book is the most important because it allows you to quickly isolate and work with stories in your backlog that have the largest potential impact on the shape (and value) of your product. You should be spending the most amount of time on this set of stories. Your focus and attention should be on them, ensuring that you're doing everything possible to move them from "unscheduled" to "scheduled".

By assigning filters to a large backlog, you can go from being overwhelmed by it, to finally "seeing it"!

Save a Sprint by Piling On!

Here at Appfire we work with hundreds of customers that select Atlassian's tools to help drive product development within their organization - many of whom are trying to improve their specific implementation of Agile.

While working with these customers, we often focus on better understanding the results of past Sprints. Looking backwards is one of the fastest methods to identify patterns of poor execution or performance, especially with teams who have not yet discovered the benefits of conducting retrospectives.

If I were to sit down and build a blame pie to highlight the top items we've identified while working with customers, at the very top of the list would be this:

The inability to properly triage and resolve issues discovered while working on complex tasks.

When we take a deep dive with our customers to better understand why some stories have been "blown" within Sprints, we typically hear about how "an unforeseen issue crept into a particular task, which forced some individual within the team to invest many more hours than originally estimated to try and resolve it and complete the task."

Sound familiar?

In reality, this isn't really the problem. Identification is rarely a problem amongst teams. We also very rarely find notification to be a problem. What IS a problem however, is how teams move forward when issues like this are identified and raised to the larger group. In practice, we see teams who do a great job of alerting their peers and scrum master of an issue. What we DON'T see are teams reacting to the issue in order to try and resolve it quickly and collectively.

I often refer to this as the "pile on approach". When an issue is identified, the team (or scrum master) should triage the issue in order to determine if other members, or even the entire team, need to try and "pile on" in order to resolve it collectively.

I've been using this "pile on approach" for about a decade with great results. It's not a difficult concept to understand or implement, yet we rarely see it being used by our customers. This may be due to culture or bad habits, or maybe because teams tend to over-commit in Sprints and forget that things happen.

In agile, we succeed or fail in the delivery of a Sprint as a team ... so pile on!