Here at TeraThink, we are currently building an internal application that will allow us to better track new business opportunities. Simultaneously, we are exposing more of our staff to agile and continuous integration/continuous deployment (CI/CD) principles. Among the many concepts we are trying to inculcate in our team is the “layer cake” user story.
The layer cake idea has been around for over a decade. However, I’ve found on nearly all agile engagements that I’ve been on, teams either discard this idea early in the project or completely ignore it from the outset. It is up to the triumvirate of the Product Owner, Scrum Master, and Business Analyst to ensure that the scrum team writes user stories in such a manner that the outcome of each story is working software that delivers tangible value to the end user.
You’re an experienced Scrum Master beginning a new project. You meet with your Product Owner (PO) for the first time and hear him or her say any or all of the following:
- “I’ve never worked in this role before.”
- “I’ll do my best to be on-site as much as possible.”
- “I’ve completed Certified Scrum Master training, but I’ve never applied it in practice.”
- “I’m the Product Owner for your team, and nine others.”
Your spidey sense is now tingling. You are going to be working with an inexperienced and/or overextended PO. Fear not, however. Here are some methods and remedies you can apply to get your PO up to speed.
A few years ago, I started introducing Definition of Ready to help alleviate a common challenge I was seeing. User stories were coming into the sprint with little information and weren’t making it to Done. The team spent more time talking to the Product Owner about what they wanted than developing it.
As an agile enthusiast, I was aware of the latest updates to Scrum guidelines and introduced Definition of Ready thinking this will solve our problem! I met with the team, setup a few guidelines as reminders of what should be in a story, we were set! Over time, through retrospectives, these guidelines morphed into something I started to realize no longer made us an agile team.
Last month, I attended the 2016 Amazon Web Services re:Invent conference with Jed Carr, TeraThink’s Director of IT. I went primarily with a DevOps focus, trying to expand our continuous integration and continuous delivery (CI/CD) capabilities by picking up some best practices by a leader in the market.
While I did attend some excellent break-out sessions, the specifics of each could bear it’s own blog post, there was a singular idea that came up during every session, keynote, or chat around the coffee pot.
Software moves faster than ever.
Successful software delivery is no longer measured in years, quarters, or months. We measure it in weeks, days, and hours. According to Puppet and their 2016 State of DevOps Report, high-performing IT organizations deployed 200 times more frequently than their low performing counterparts. So if you’re an organization pushing out quarterly releases, you’re trying to keep pace with the front-runners pushing out twice daily.
It is hard to believe that TeraThink is approaching its 14th year as an organization. It all started for some of us in 2003, when two Enterprise Resource Planning experts decided to build a company based on SAP, and its rapid growth in the Federal Government. Fast forward to 2013, a core capability was our SAP expertise and rapid growth into the Momentum Financials arena. Now, as 2017 begins, our Enterprise Applications solution area is at a crossroads. We are excited about the new direction it is taking us.
As far as conferences go, I have to say, Amazon puts on a pretty good show. Most sessions were interesting and on point. Attendees were smart and social. And the exhibitors provided more than enough products and solutions to fulfill my weekly geekdom quota. The icing on the cake was the free Echo Dot awaiting everyone on Day 1. I wasn’t sure what to expect from my first re:Invent, but by the end of the week, I was leaving the desert with plenty of ideas to bring into the office on Monday. Here are a handful of my takeaways.
This year marked the 15-year anniversary of the writing of the Manifesto for Agile Software Development. Today, I can’t help but marvel at the impact this collection of simple, yet elegantly stated principles continue to have, especially here in Washington, D.C.. Agile has not only changed how we build working software, it has fundamentally changed how we understand our organizations and how we define the business value we produce. With agile, many of us have learned new approaches to prioritizing our work at an enterprise scale, how we can organize our businesses, and even how we can build deeper relationships in the process. Agile development has sparked a new wave of innovation, especially in the Federal market and it’s incredible to think what 2017 will bring.
For those who are doing it successfully, being agile requires the adoption of both an agile-mindset and the incorporation of new software architectures and delivery practices. At TeraThink, we recognize that our clients have very specific needs and objectives for their implementation of agile solutions. We work closely with each client to provide their desired results. Agile is, of course, not without its challenges. Whether it is initial adoption, sustaining agility at scale, or breaking into a more effective CI/CD model, these challenges are significant. I’d like to share a few key observations and strategies that have helped our clients hit their stride with agile.
One of our core solutions at TeraThink is Information Management. It is a term that we, and the industry, use to encompass a large collection of skills and expertise centered around content and information. Information Management is also a critical part of everything organizations do every day.
How do we define that collection of skills? Stated from a high level:
Information Management (IM) is a strategy for the coordinated management of all information throughout an organization, allowing for people and systems to find and use information from within any business context.
The goal is to provide people the right information at the right time and be confident that nothing is being overlooked. We make sure that information flows as needed between every system and process. Whether we are talking about governance, content, or digital transformation, IM is at the heart of every project and sets up long-term success for our clients.
Earlier this month, we held our first company hackathon in our new office. It proved to be a great day and a tremendous learning experience for our company and particularly all of the employees who got the chance to participate. I had the opportunity to help facilitate the day’s activities. I thought take a moment to reflect on what I thought was a very successful event.
We’ve been talking about how to leverage open APIs to connect content-centric solutions together. The goal is to leverage the success from deploying point solutions without creating the numerous silos that typically accompany that approach.
The question that arises is what kind of platform providers are incented to create and maintain open APIs? Any vendor can claim to have an open API. Unless supporting those APIs long-term is core to their business model, those APIs may vanish or become closed in the future. While any enterprise content management (ECM) vendor may have open APIs, open source and software-as-a-service (SaaS) vendors are the ones whose business depends on open APIs.