Atlassian Positioned as a Leader in Gartner's Magic Quadrant for Application Life Cycle Management

Earlier today Atlassian announced that the IT industry analysts at Gartner have placed Atlassian in the coveted "Leaders Quadrant" of its 2012 Magic Quadrant for Application Life Cycle Management. Gartner's Magic Quadrant positions vendors in IT markets based on their ability to execute, in addition to their completeness of vision.

How did Atlassian ascend into the Leaders Quadrant alongside IBM & Microsoft?

It's only been a few hours since Atlassian's press release went live, and we've already been asked this question more than half a dozen times. With that in mind, I'd like to quickly share what we've told everyone who's already asked:

"If you want to make it into the Leaders Quadrant, it's pretty simple. There's only one thing you need to do better than everyone else. Execute."

In Gartner's reports, the Leaders Quadrant is reserved for elite companies who not only dream big and constantly expand their products, but also, and more importantly, prove that they can execute their product visions by demonstrating substantial customer success stories. Yes, innovation is important; it helps shape and guide markets. However, inclusion in the Leaders Quadrant also requires substantial proof that a company can repeatably deliver quality product to its customers.

The Enterprise relies on Atlassian and Appfire

As North America's largest Atlassian service provider, Appfire has been dedicated to driving Atlassian and their products into the Enterprise for seven years. We are incredibly proud to have been part of so many of those enterprise success stories. We've known for years that Atlassian's tools would eventually be recognized by Gartner, and today is that day.

Today Atlassian sits alongside industry giants, IBM and Microsoft, in Gartner's Magic Quadrant.

Cheers to our friends at Atlassian, and onward into the Enterprise!

Download a free copy of the full Magic Quadrant report here

Book Review and Wine/Chocolate Pairing Guide: "Confluence, Tech Comm, Chocolate"

Atlassian Summit 2012 is upon us, drawing well over 1,000 thirsty travelers from all around the globe, and I couldn't think of a better time to publish my first book review for Sarah Maddox's recent release:  "Confluence, Tech Comm, and Chocolate".

For those of you not familiar with Sarah, allow me to offer a quick introduction. Sara Maddox is a technical writer at Atlassian, makers of market leading software tools for technical teams. She’s also the author of a popular blog on that topic (and more) at: http://ffeathers.wordpress.com.  She began her career working as a software developer in South Africa and Europe, and after another short stint as a book indexer, Sarah's career evolved into her current passion. Sarah loves writing docs that rock!

She has a style of writing that is welcoming to a variety of audiences, making it easy for business teams to quickly grok the technical publications that she authors.  I've been a close friend of Sara’s for almost four years and even though we’re usually separated by over 16,000km between her home in Australia and mine in the US, we've always found ways over the years to collaborate on a variety of projects.  

I would highly recommend Sarah’s new book to anyone currently using, planning to use, or simply interested in learning more about what a Wiki is, and how to use it as a platform to facilitate the type of writing you’re involved with.  

Outside of writing, Sarah has another passion. It's Chocolate! In fact, after years of traveling the globe for various endeavors I’ve only met one other person as crazy as Sarah is about Chocolate. She describes it in poetic terms and she's successfully introduced, and even at times bribed her colleagues with it, to promote writing (see "Kay's chocolate cake" pg. 87, 313 and "Doc Sprints" beginning on pg. 415).

So when Sarah asked me to review her book, an idea immediately came to mind: Why not blend our collective enjoyment of all things Wiki with Sarah's passion of chocolate and my love of a good glass of wine while reading! Makes sense right? So, I decided to make it a project. I experimented and found what I believe are the best possible combinations of chocolate, wine and chapters from Sarah's book.

Chapter 1: Introduction

This isn't your typical "introduction" chapter. Sarah has read plenty of those. Instead, she begins the book and immediately immerses the reader. Chapter one also finishes quite strongly, so prepare yourself, because you’ll need an equally strong pairing of chocolate and vino to compliment this "rich" chapter of her book.

Recommended Chocolate Pairing: White Chocolate

Made without chocolate liquor, white chocolate is a rich product made with cocoa butter, sugar and milk solids. It has sweet flavor notes including cream, milk, honey, vanilla, caramel, and/or fruit. It makes a perfect beginning to any book. While I'm not typically a huge fan of White Chocolate, I found one that complimented Chapter 1 quite well, as well as our recommended wine pairing. Randall's pick:

• Ghirardelli Chocolate Sublime White Vanilla Dream Chocolate Bar - $4
  

Recommended Wine Pairing: Champagne

While to some, the concept of Champagne or other sparkling wine with chocolate is romantic; the acid in sparkling wine produces tart flavors when paired with the cacao in milk or dark chocolate. However, since there is no cacao in white chocolate, it can be a great choice. With that said, you should still be careful. Even though white chocolate doesn't contain cacao, I wouldn’t recommend cracking open a good bottle that has been “vinified” specifically for food-pairing. Instead, consider going for a sweeter Champagne like a sec or a demi-sec. Randall's picks:

• Gruet NV Demi-Sec Methode Champenoise - France 2010 - $13
• Veuve Clicquot (white label) - France 2010 - $49

Chapter 2: Developing Documentation on a Wiki

This chapter is filled with expert tips for the planning and execution of your wiki implementation. It’s 201 pages of pure "how to" excellence! Sarah details out, step-by-step, the aspects of planning, content design, structure, templating, workflow, and so much more. This is intense chapter requires a chocolate and a wine that will hold you over during your multi-hundred page eyeball feast.

Recommended Chocolate Pairing: Semisweet Chocolate

Dark chocolate, with 50%-69% cacao, has strong and complex flavors with nuances that are nutty, spicy, floral, earthy, fruity, and/or caramel. The aftertaste is balanced and not too sweet. I believe I found the perfect bar of chocolate to pair with Chapter 2 as well as our recommended wine: Randall's pick: 

• Scharffen Berger Chocolate Bar - Markham Valley Semi-Sweet (68% Cacao) - $2.50 per bar

Recommended Wine Pairing: Red Wine

As part of my (eh, hem) "scientific" research, I explored three options:

Cabernet Sauvignon, including Bordeaux, will bring out the fruity-peppery-grapey notes in the chocolate. Randall's pick: 

• Chateau la Vieille Cure - France 2009 - $29

Fortified fruity wines like Banyuls (AOC) and Ruby Port have cocoa or chocolate in the nose as well as cherry, raspberry or other berry fruit, and are classic companions to chocolate. Banyuls is made from the Grenache grape while Port is a blend of several grapes. Banyuls and non-vintage Ports have softer, rounder tannins than vintage Port, which tend to pair better with chocolate. Randall's pick:

• Frog's Leap - Napa Valley 2009 - $39

Spicy Zinfandel brings out chocolate’s spicy nuances. Randall's pick: 

• Belasco de Baquedano AR Guentota - Argentina 2008 - $17

Chapter 3: Life on a Wiki

Just beyond the midway point of the book, Sarah walks you through the average day spent on a wiki from a variety of perspectives. She begins to unfold use cases, best practices and begins to share some incredibly powerful tips to help with your deployment. At this point along your wiki journey, you’ll need another trip to the kitchen to refuel. While exploring options for this chapter, I stumbled on two particular pairings that I thought worked magically.

Recommended Chocolate Pairing - Milk Chocolate

Milk chocolate has a higher percentage of sugar and a smaller percentage of chocolate liquor. This, along with its milk content, yields a milder, sweeter product with fewer flavors and aromas. While pairing, I threw a number of bars overboard. They were either too subtle or too strong. In the end, I settled with these two. Randall's picks:

• Valrhona Jivara Chocolate Bar (40% Cacao) - $4 per bar
• Green & Blacks Organic Chocolate Bar (34% Cacao) - $3 per bar

Recommended Wine Pairing - Vintage Blanc or Tawny Port

Sweeter chocolate needs sweeter wine, or the wine can taste tart. Here are two unbelievable options that pair well with any milk chocolate you select. Randall's picks: 

• Sauvignon Blanc - Mulderbosch - South Africa 2010 - $17
• Tawny Port - Fonseca Year Old Tawny Port - Douro Valley, Portugal 2012 - $29

Chapter 4: Giving your Wiki Wings

Sarah closes her book with a solid chapter focused on approaching your reader, engagement, and collaboration. She shares her insight about strategies and games you can introduce within your organization that help drive content creation and awareness. She also covers the concept of a "Doc Sprint", a practice that Appfire often recommends to our customers’ Tech Comm Teams.

Recommended Chocolate Pairing: Bittersweet Chocolate

The most intense, richly flavored dark chocolate is 70% to 100% cacao.  Bittersweet chocolate can have bitter, roasted, fruity, earthy, woodsy, ashy and/or nutty notes. I think that I struck gold with this one. You can bake with it or eat it straight up. Of the dozens of bars I tasted this was by-far one of my favorites, and I think that it, along with it's liquid friend below, was the best way I could have turned the last page of Sarah's book. Randall's pick: 

• Schokinag German Chocolate Bar (72% Cacao) - $9 for 9oz. at Whole Foods. I splurged a bit here, but it's the last chapter, and it was definitely worth it!

Recommended Wine Pairing: Red Wine

Bittersweet Chocolate pairs well with an intense, in-your-face California Zinfandel or even a tannin-driven Cabernet Sauvignon. The darker the chocolate the more tannins it displays. However, when you pair darker chocolate with a wine that has stout tannins, the chocolate can overshadow or cancel out the wine's tannins on the palate and allow more of a fruit flavor to show through. Trying to stay on task and finish Sarah's book with a rival pairing, I kept my field of view narrow. Here is my take on the best choices to marry with your last chapter and chocolate. Randall's picks: 

• Zinfandel - 2004 Seghesio Family Vineyards - Sonoma - $20
• Zinfandel -  2003 The Terraces - Napa Valley - $25
• Cabernet Sauvignon - Chauteau Montelena - Napa Valley 2007 - $42
• Cabernet Sauvignon - Eponymous - Napa Valley 2000 - $50

About Randall

Randall Ward is co-founder and CEO of Appfire, Atlassian's largest service provider in North America. Randall has spent years researching the intersections of technology and human behavior, applying techniques observed through the deployment of collaborative tools within the Enterprise.  Within the Atlassian ecosystem, Randall is considered a leading authority of Atlassian tools deployed within the Enterprise and is continually sought-after for his consulting skills.  At Appfire, Randall leads the charge in enabling the world's most advanced product development teams to quickly innovate, develop and drive their products to market. Click here to learn more about Appfire.

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.