Mainframe-powered firms are all at unique points in their mainframe DevOps journeys. We know this through the DevOps Transition Workshops we conduct with customers; the DevOps data we collect from customers leveraging Compuware zAdviser; and the insight we glean from industry thought leaders, analysts and partners.
Whether that means your journey hasn’t begun or you’re using CI/CD pipelines, we want to help you learn and continue to leverage the power of mainframe DevOps. We’ve made it easy to discover where you are and where you’re going on your mainframe DevOps journey, with five stages that offer supporting resources to help you move forward.
At Abstracta, we work with many companies, several of whom already have a DevOps culture and others whom we’ve helped to define and promote it. Over the years, we’ve seen DevOps gaining popularity, and most teams are on their way there. In this post, I’ll share some lessons from our experiences in helping companies with their agile transformations.
From what we’ve seen, we’re convinced that teams with a DevOps culture work better, obtain better results and are, just… happier.
The best use case I heard while at TIBCO NOW 2018 was presented by Emilio Sorrenti, CTO of Aeroporti di Roma (ADR) which operates the Leonardo da Vinci-Fiumicino Airport and the Rome Ciampino Airport.
In 2015, the ADR ranked 17th out of 20 large airports in Europe with regards to the level of customer experience (CX) provided, based on research and surveys conducted by Airports Council International (ACI). ACI looks at all aspects of an airport’s operations including security, check-in, Wi-Fi, comfort, atmosphere, luggage, security, cleanliness, as well as infrastructure.
As a consultant, I get to see a lot of different organizations and work with a variety of teams. By now, virtually everyone has at least heard of Agile and read the Manifesto. We also seem to have, in technology adoption terms, crossed the chasm, and so adoption by more traditional, sometimes slower moving, global scale organizations is well underway. Agile has finally been vetted by the early adopters and is now becoming mainstream.
I, like others, talk about the difference between “doing Agile” and “being agile” — differing the big “A” Agile and the little “a” agile is intentional [BC1]. From an intellectual perspective, the notion of Agile being a mindset and a different way of seeing and acting in the world rather than a methodology or a process usually resonates. Still, though, I see a tendency to want an “Agile checklist”; a tendency toward Agile for the sake of being able to say “we’re Agile” rather than genuinely zeroing in on value and excellence. I cannot tell you how many times I’ve heard, “It’s not ‘Agile’ if you aren’t doing <insert practice here>.”
Back when I used to fly, I religiously used checklists even when I had the checklist memorized. Making sure you have covered every detail is particularly important when life and limb are on the line. Maybe it was superstition, but knowing that I had done the checklist freed up my mind to concentrate on the flying without any lingering doubts. I used the checklist to get the helicopter started and running smoothly before taking off. Once flying though, I would focus my attention on my destination, as far ahead out the windshield as I could see. The checklist had its place, but checking off that list is a starting rather than end point. I’m telling you this story just to emphasize that I am a big fan of checklists…for specific situations.
When I get invited into a new organization, I have some things I look for in a team that is on an Agile journey. I look for how they collaborate, both as a team and with their customers. I look for how they design for optionality. How do they articulate their stories? How do they address dependencies and impediments? How do they validate everything they build is working and hasn’t broken anything else? I look at how they design in adaptability, both socially and technologically. And especially, how do they hone their craft and have fun? It’s not really a checklist as much as a set of markers that I’ve seen with high-performing teams and a vibe I get when I get to know them. As critical as I think they are, I don’t see mood, orientation, and mindset as checklist items.
The Agile Manifesto is a set of values and principles. I wasn’t there when they wrote it, but I’ve talked to several of the folks who were there, and I believe practices were left out of the Manifesto intentionally. I don’t think they wanted to create yet another static methodology. Nothing against Scrum and SAFe and other methodologies because they serve a purpose, but they came later as a subset rather than as a re-definition of Agile.
Scrum ≠ Agile.
The tendency to have a checklist of practices limits our ability to see the bigger picture. It limits our ability to become adaptable and create adaptable solutions for the business. Still, we have to crawl before we walk, walk before we run, and so, having a predictable sequence as we get started makes sense. I think that is how scrum found a niche in the Agile world. For those starting an Agile journey, it provides a sequence and framework for getting things done in a predictable way. That, in and of itself, is valuable for many organizations. Still, it is a starting point to a long journey, not the ultimate goal.
Metrics give us a baseline to start from and a way to focus on our ability to execute and deliver value to the business. As we progress, the data should show trajectory and help us design in-course corrections that will help us collaborate on what we want to target as things to do and learn next. Assessments also give us a baseline, but with a different purpose. Metrics look at what we deliver and how we execute relative to what we committed to. Assessments look at what we are learning and how likely we will be able to continue to progress on our Agile journey. Both assessments and metrics should be used as thinking tools rather than as a bludgeon to force behaviors. If they are used to force behaviors, I have repeatedly seen unintended consequences and gaming of the system rather than the intended behavior change.
Both metrics and assessments are a form of feedback loop and an integral part of the course corrections we want to be able to make. Continuously having an up-to-date list of skills we are learning as a team makes sense, but just being focused on checking off the boxes does not because the checkboxes are just the start of the journey. Teams need to persistently be looking at the goals and outcomes they are striving for; clarity around what is valued, how we are producing that value, how we validate it and what are we learning.
The learning journey is never done. Whenever I get the opportunity to appreciate art, I discover something new. Whether it is a different perspective on a statue, a painting, or a creative approach to a technical conundrum, I learn something new. I can listen to a song or piece of music I love and enjoy it repeatedly, not because it is different, but rather, because I am different with each listening. Agile is really all about learning, and like everything we learn, there is always more nuance, more depth to uncover.
I believe one of the most important aspects for the success of any product is the product-market fit. I’ve seen many great products fail miserably in achieving commercial success because they don’t solve some of the important customer pain-points. Paul Graham aptly said, “The most common mistake companies make is to solve problems no one has.” And, of course, there could be several other reasons for such failures, despite it being a great product, but that’s not what I‘d like to focus on here. While I don’t have a silver bullet and neither do I claim that these have always worked for me, here are some excellent practices I’ve seen product teams following and they might just work for you.
For one of the new products we’d launched in the enterprise security space, our team followed this unique approach of signing up potential end-users, understanding their complete job in terms of their day-to-day activities, mapping each of them in the product capabilities and then coming up with the overall functionality for the product. This was a great learning experience. We often tend to focus on one great feature and get overly excited about it. Understanding what the users need to perform their job, and not just one great feature, was a big revelation into the overall value we were bringing to the table.
It’s one thing to have “domain experts” advising you on your product strategy and completely another thing to have real users and their decision makers sweating it out with you in trying to achieve a common goal of creating value. Nothing beats the beta users who are highly motivated in installing the product in their environment and giving you the much-needed critical feedback. You should feel lucky if you have some, especially if it’s an enterprise product.
Despite all the ways mentioned here, especially for enterprise software products, we end up getting brand new requirements for that one big deal, for which we need to respond quickly. This is where the last point matters.
A lot has been said on this topic. But how often do we effectively implement it? We all want to get our product out in the field doing wonders for our customers as early as possible and get back to us to communicate improvement areas. But then the strong urge to release that perfect product dotting all the I’s and crossing all the T’s keeps us from releasing that so-called imperfect version. Very few teams can overcome the dilemma and have the courage to leap and very often, I have seen them win.
Despite all the precautions and planning, there are always bigger, unexpected opportunities that keep knocking at the door. If the engineering is not willing or ill-equipped to respond quickly, the opportunities are lost in no time. Change is the only constant and being agile is the only way to survive. Your response time is always an indicator of how mature and innovative your development processes are. Do focus on them. They will come in handy someday!
This article originally appeared on QualitiaSoft’s blog.
It is often said that Agile practice is based upon empirical process control. This, in turn, depends upon the ability to effect changes based upon evidence, and thereby allow progress to be managed. In Scrum, for example, there are several events, each of which is designed to inspect and adapt something. Scrum is a framework by means of which a complex and uncertain environment can be mastered. The unknowns in the environment gradually and incrementally become known.
The core thesis is that any planning horizon represents a leap-of-faith, and ought, therefore, to be kept as short as possible. It is well known to battlefield commanders that the “frictions of war” can rapidly cause the best plan to erode. The same is true of software development. There are a great many variables that come into play when trying to form a long-term plan, and certainly too many of them to take into account. The evidence we gather over time can make outcomes more predictable, although we must carefully avoid trying to be predictive. In a complex and uncertain world, a theoretical model is likely to be overtaken by events. It is better to inspect-and-adapt in a timely manner.
Scrum provides for the following inspect-and-adapt opportunities:
|Sprint Planning||Product Backlog
Definition of Done
|Daily Scrum||Sprint Goal
|Sprint Retrospective||Scrum implementation
Definition of Done
Definition of Done
Note that the Sprint Backlog is the Development Team’s forecast of work and plan for meeting the Sprint Goal. The goal should not be adapted during the Sprint, as it is the anchor point around which work can be replanned and the surety of a testable outcome provided.
Inspect and Adapt is Pattern of the Month at agilepatterns.org
Intent: Teams delivering value should be able to critique and improve their own working practices
“Those who cannot remember the past are condemned to repeat it.” –George Santayana
“Work smarter, not harder.”
“Practice makes perfect.”
“An ounce of prevention is worth a pound of cure.”
Also Known As:
Motivation: Continual improvement and response to change lies at the heart of Agile ways of working. There must be numerous opportunities for this to happen, and they must occur on a predictable and regular basis.
Structure: A transparent project will support inspection and adaptation. A team must be able to inspect and adapt the process. At the conclusion of each iteration, a potentially releasable increment must be delivered by the team to the Product Owner (PO). This increment will then be reviewed, the development process considered in retrospect and improved, and future work planned. The team will publish metrics that allow improvements to be quantified as well as qualified.
Applicability: Inspection and adaptation must occur as closely as possible to where the work is done. A team will inspect and adapt its products and processes at regular points so that the quality of delivery can be improved.
Consequences: Inspection and adaptation facilitate continuous process improvement. Teams that regularly inspect and adapt their processes demonstrate greater responsibility for their deliverables. The delegation of responsibility is thus encouraged, and improvements can be leveraged.
Implementation: Scrum provides four discrete events at which inspection and adaptation may occur. These are the Sprint Review, which looks at what work has been done and remains to be done; the Sprint Retrospective, which considers how work is being done; Sprint Planning, which determines the Sprint Goal; and the Daily Scrum or Standup, which supports the inspection and adaptation of the team’s daily plan for meeting the Sprint Goal. Extreme Programming does not adopt a comparable discrete approach but rather encourages inspection and adaptation to occur at any point on a development continuum. Feedback and the courage to adapt are core values within XP.
Asking for peer feedback is fraught with peril. It’s everyone’s second most-dreaded part of the annual review process (only the self-review induces more anxiety). So it’s no wonder we don’t make a habit of seeking it the other 364 days of the year.
But seek it we should. Admittedly, it feels like a tax at first. Then, you realize it’s an investment.
There’s not been a single instance when getting a peer’s input on my work didn’t improve it. The trick is getting the right people to weigh in on the right piece of work at the right time. My favorite way to solve for that is with a technique that comes out of design thinking.
It’s called “sparring“, and it’s a structured way to evaluate work that is still in progress. At it’s best, a sparring session will also help you reach specific conclusions and make the decisions that move your project forward.
Let peers challenge your ideas and inspire new ones.
While sparring was originally conceived as a way for artists and graphic designers to critique and help improve each other’s work, it applies to all sorts of projects – even projects that don’t have a strong visual component. I’ve seen developers spar on technical design. Or product managers sparring with designers and tech support on a new on-boarding experience. Even C-level executives have been known to spar on customer retention strategies or budget prioritization.
Let’s start with the vital stats. For a sparring session, you’ll need:
Before sending out any invites, make sure the work you want feedback on is ready for it. Is it far enough along that the feedback will be meaningful (but not so far along that you can’t change course)? Are you at a crossroads and need input on which direction to go from here (or a gut-check on the path you’ve already started down)?
Consider the scope of what you’ll show your peers. An entire enterprise network architecture plan might be a wee bit too much to cover in one session.
Last, take a few minutes to build the case for the approach you’ve taken. Compile any competitive research or customer interviews you’ve done. Gather up the data that has led you to the decisions you’ve made so far.
Be ready to defend your work, but don’t get defensive. Critiques will be aimed at the work – not at you personally. So argue like you’re right, and listen like you’re wrong.
Give a walk-through
At the start of the sparring session, take 5 minutes to present the work in its current state. Provide just enough information to give people context, but don’t over-do it. They walked in the room with open minds, and you’ll get better feedback if you keep it that way.
Bring on the feedback
Step back from the diagrams you’ve drawn or print-outs you’ve hung up, and let your peers go over your work in silence. Give them sticky notes so they can tack up comments. It’s fine to answer clarifying questions at this stage but resist the temptation to dive into problem-solving mode.
Challenge and discuss
Start going through the comments your peers have left and discuss questions or new ideas that come out of them. You’ll probably find yourself answering some tough questions about what you’ve done and why. That’s ok.
In fact, that’s where the magic happens. In an ideal world, you chose peers who you trust and who don’t think exactly like you do. People who might see your idea and evolve it into something you’d never envisioned.
It’s scary opening your work up to people with diverse skills, backgrounds, and perspectives. Embrace that. Being outside your comfort zone will help you grow and improve your work.
Remember: sparring means practicing – not battling. Sure, it feels like you’ve taken a few intellectual punches, but they make you stronger. Just as boxers, fencers, and martial arts masters can’t train on their own, we office workers can’t improve without testing ourselves against others’ knowledge and experience.
Knowing that I have been working with project management for almost two decades and that as a consultant I have the opportunity of getting in touch with companies using all kinds of approaches to develop their products, people often ask me what is, in my opinion, the best software development method. Here’s a quick version of my usual answer.
The very first thing you need to be aware is that there’s no such thing as a silver bullet approach that fits all possible projects. Think: each project is a complex problem to be solved, and any different variable in that problem might require a different approach in order to achieve the expected result—even when you comparing very similar problems. For example, we could have two rival companies independently trying to build the exact same product, but since these companies have different characteristics (e.g. different values, different budgets, different metrics, different IT infrastructures, different team sizes, different seniority levels and allocation models in these teams etc), each company might need a different approach to better fit its own reality, even if both are aiming to achieve the same output.
That said, bear in mind that often a single company, and sometimes even a single team, should be using more than a single approach if they are dealing with multiple projects containing different variables. I know that requires extra orchestration efforts, but, well, great orchestration is one of the crucial things you must have anyway if you want to work with the best software development method (more on that soon).
Recently, I got in touch with a company developing a big blockchain related product. The company has 3 dev teams: 1 in Asia, 1 in Europe, and 1 in the USA. Each team is working on a different part of the same product, but each one of them has devs with way different backgrounds. Besides, each team has different priorities: one needs to release often, the second one needs way longer testing and validation phases for each change and the third one is at the moment focusing on R&D. For a while, they struggled trying to find a single process that would support the three teams, until they realised that each team would be way more productive and happy having its own approach—even if they are working on the same product, with the same IT infrastructure, and even the same Project Manager orchestrating all the activities.
The second thing you must realize is that ‘shelf solutions’ (Scrum, XP, DevOps etc) rarely are, by themselves, optimal solutions. In other words, it’s not only that you have to examine the variables of each problem (each project) and then pick an answer from a set of predefined options (the shelf solutions). In order to get to the best software development method, you must, instead, examine the characteristics of your project and then design your very own approach.
Not to say, of course, that you should ignore any existent models and references. On the contrary, to design the best approach for a specific project, you should have a solid understanding of as many existent processes, frameworks, and practices as possible. Ideally, you should also know and understand well the history and the principles behind all those approaches, rather than only understanding how they are supposed to work, as their principles are way more important than their practices, especially now that you’re designing a new approach. Then you can use these existent models as a baseline for the creation of your method, mixing elements as needed, picking those that make sense in your reality, and rejecting those that don’t.
As you would do when designing a new product, don’t lose too much time on trying to design a perfect development method, either. Design a simple one, as simple as possible. Then start using it to gather actual feedback. Have someone in charge of orchestrating anything related to your brand new method, as in most cases no method will work by itself. You must have someone continuously coordinating the processes and activities, doesn’t matter how you will call this person: project manager, process manager, or Dorothy.
Among all other regular project management activities, this person must take care of continuous improvement as well, which is the most critical factor in order to keep your method healthy and valuable in the long run – although it is as well, sadly too often, the first one teams will leave behind as soon as they reach a good-enough state. Businesses, priorities, technologies, scope etc are constantly changing, thus also your method must always be improved to keep up with all existent variables.
A company culture is a critical success factor for the success and growth of your business. A culture is something that shapes itself, but that doesn’t mean you have to sit back and let it happen. You can move it in the right direction, by defining the values that are important for your company. This is going to take some serious thinking and soul searching. Take time to do it right, organise brainstorm sessions, and involve the right people. Here are three core values that are essential to creating a great culture.
There is a difference between desired and real core values. In order to become real core values, your people need to believe in them and be able to apply them in their work. Unfortunately often there is a huge gap between the culture that you try to set and the one that is experienced by your employees.
Core Values are the fundamental beliefs of a person or organization. These guiding principles dictate behavior and can help people understand the difference between right and wrong. Core Values also help companies to determine if they are on the right path and fulfilling their goals by creating an unwavering guide.
To avoid this from happing make sure you keep it real and involve your employees when finding the core values for your company. Don’t just select values that sound good from a sales and marketing perspective. Choose values that make sense for your company. Saying one thing and doing something else will kill your credibility and will definitely not help create the culture you’re aiming for.
You can write down the most beautiful core values but if nobody can apply them, why even bother. It becomes a nice story with no meaning.
“Values are what we value.” – Netflix
Honest and open communication is the foundation of any healthy company culture. Honest communication is essential to building strong relationships with your people, your customers and your suppliers.
Communication needs to happen at all different levels in a company and should come in all forms. You can share company information in a town hall, do webinars, organise brainstorm sessions, have one-on-one meetings, send e-mails, share information in employee guidelines, have your vision, mission and values printed on the wall, you name it. As long as you take time to communicate.
Communicate everywhere, but don’t forget to also be a good listener. Communication is a two way street. What do your people expect from you? What is going on with them? Is their work challenging enough? How can you help them achieve their ambitions?
However be careful that you don’t over do it. Have you ever experienced sitting down with someone in your team and after the meeting you walk away with a list of problems that need solving? And why might this be a problem? Well sometimes you are your own worst enemy. You want your team to work optimal and in order to do so you try to solve everything, even if it is not yours to solve. The consequence can be that some people stop communicating with each other because it’s easier to go through you. You spoil your team, treat them like kids, and take ownership of their issues. People don’t learn to fix these issues themselves but always go through you! Avoid office politics and only get involved when they can’t resolve it themselves. For example, you have two people in your team that cannot get along. If you immediately get involved in order to remedy the situation, you get caught up in the “he said, she said”. And before you know it people are more worried about convincing you who is right than about resolving the actual conflict. In the end, by stepping in you made the issue bigger than it needs to be. It is much better to say to them, “You are grown ups. I trust you can work it out yourself. Go sit together, talk, explain what is bothering you, try to really understand each other, and get to a solution”.
Ultimately building a great company culture has a lot to do with how much people truly trust you and each other. To build this culture of trust the first two values (‘Honest and open communication’ and ‘Do what you say’) are essential.
“Communicate fearlessly to build trust.” – Spotify
Perfection is an unattainable goal. So stop trying to make your company perfect from day one and just start doing it. Don’t get me wrong, it is good to dream big. I myself believe in Go Big or Go Home. But in order to get there, you sometimes need to break up your goals in smaller containable chunks. You can’t fix the world overnight. Pick those that have the highest priority and provide a solution for them before you start dealing with the next. It gives you more focus, quicker results and step by step you can reach your ultimate goal.
At my previous company I was brought in to fix Operations. At that time the team was underperforming, demotivated, quality was poor, and attrition was high. There were many reasons why this team was so dysfunctional, e.g people where allocated on multiple customers at the same time, there were no standards, no clear communication, no proper on-boarding, no personal development, etc etc. Fixing everything at once would be impossible. It took months, years to get where they are now. By breaking it up you can gradually get better and better at what you do and eventually you achieve more than you ever thought was possible.
It doesn’t matter how much time and energy you spend on defining a process or product, there are always area’s for improvement. The only way to find these out are after implementing and gaining experience with it.
Many years ago I was working as a developer for a big company. They spent months and months on defining their development process. Once the process was finally defined and adopted by the team it wasn’t possible to improve it, even though certain parts were slowing us down. The reason for this? After spending so much time and money the company didn’t want to spend more time and money on improvements; they believed the process was good enough and we just had to get used to it.
In the example above the company didn’t realise that they could have made the process more efficient by allowing continuous improvement which in the end would have saved them time and thus money.
You can make your company so much more successful if you accept that there is always room for improvement. Don’t settle for good is good enough and make continuous improvement part of your company culture. Where everyone in the company is able to contribute and make it better. Your people will be more invested and become more motivated when they are involved in how things are done within your company. In the end continuous improvement has so many benefits, e.g improving employee satisfaction, increasing productivity, improving quality, lowering costs, and decreasing delivery times.
“Through continuous improvement we try to optimize our operations.” – Toyota
Building a great engineering culture is not easy, there are people out there that say it is impossible: it will shape itself! I agree to a certain extent but that doesn’t mean you have to sit back and hope it happens. You can help it move into the right direction. Today I wrote about three core values that are essential to creating a great culture:
If you think this post was useful please like the post or send me your feedback. It will encourage me to write more…