In May, my colleagues and I attended ServiceNow’s annual conference, Knowledge18. We joined over 18,000 attendees in Las Vegas to meet, learn, share, and collaborate on all things ServiceNow. They presented a wide range of valuable content spanning all aspects of the platform. This ranged from in-depth solution-focused sessions, to industry-based workshops, to a roadmap of functionality coming to the platform.
Two of my takeaways from the conference centered on the platform improvement and their increased focus on the customer.
Microservices is the latest architectural approach to scaling applications. Their smaller, more atomic size, allows for greater agility as the impact of each iteration is more contained. This makes continuous integration and development easier as the burden of testing is less and deployment iterations are more limited in scope.
As we look to utilize Mule, and other systems, in this environment, we need to make sure that their configurations can automatically reflect their environment. As we build applications at scale and move out of the development lab, this becomes a real need. Luckily, the Spring Cloud Configuration server lets us do exactly that.
A few weeks back, I spoke on an Information Coalition webinar with Nick Inglis about getting Beyond the Hype of Content Services. We discussed content services and tried to separate the reality from the hype. If you been following, there is a lot of hype out there and has been since Gartner stopped tracking ECM (enterprise content management) and switched to content services. This has fed people’s instinct to equate content services with ECM. Many vendors and consultants are now taking their marketing messaging and simply substituting one term for the other. Even more distracting are people that reflexively reject content services because they assume the person using the term is just doing a term swap.
The truth is that content services is not ECM. It is an approach to implementing solutions that support an ECM strategy and providing sound information governance. Content services doesn’t eliminate the need for an ECM strategy or information governance. In fact, if you don’t have a strategy or proper governance, you might end up addressing the wrong things.
You still need a plan. To determine how to implement it, you need to know what content services is and how it can make a difference.
Recently, I was at the local NCC-AIIM Chapter meeting. Russ Stalters was visiting from Texas and shared the story about how he created a new, 200+ person, data management team for the BP Gulf Coast Restoration Organization. A separate organizational entity from BP, the organization was stood up in 90 days from vision to operation. It was an impressive tale involving massive amounts of information being absorbed and managed in a highly visible environment.
As Russ spoke, it became clear that two of the key lessons were around agile processes and content analytics. It generated some great discussion that took us well past the scheduled time. I wanted to take some time to share some of the highlights.
As success with DevOps continues to make progress, it ventures into taking on other areas where traditional SDLC / IT practices have been less than optimal. Alongside this need, the IT Security technical landscape has been in rapid transition, making it near impossible for security teams to keep up with both increased DevOps velocity and the changing security landscape. Now, teaming up security in the continuous integration (CI) and continuous delivery (CD) model has a potential to be a game changer.
In the beginning, the movement started out being called DevOpsSec. ‘Sec’ was appended on to the end – almost like a caboose on a train – an afterthought. But in reality, security must be thought of, designed, and practiced throughout the process. In light of this, the more current term is DevSecOps – one where we weave security into our integration. Originally, marketing hype from each security software vendor clouded the concept. But, the movement is less about tools, and more about the way in which we work together, in parallel.
TeraThink had the privilege of attending and sponsoring AgileDC last week. AgileDC is a great event every year. It brings the DC area’s best and brightest thought leaders and practitioners to talk about agile trends, best practices, experiences, and how to grow our practices and community. This event has much more of a community feel than many of the larger conferences and events, which I really appreciate and value. You can focus on forming new relationships and broadening your knowledge of local partners and clients, which benefits everyone.
When all of the best and brightest thinkers in the agile arena get together in one place, there’s no doubt you are going to learn a lot from one another and have fun. This year’s Agile2017 conference in Orlando was no exception. Great breadth of topics that loaded me up with ideas to bring back to our TeraThink clients and our company itself. I want to share a few of the areas that top my list.
Making Time for Innovation is Good for Everyone
The innovation theme was prevalent in many conversations and areas, and there is a good reason – because it is important. Innovation is how people, products, industries, etc. get better. Allowing our developers, engineers and leaders the space to innovate will build higher performing teams and organizations. I spent Open Spaces time with some great agilists hearing about the innovative ideas they have implemented at their respective companies. This has fueled my fire to get this going even more at home.
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.