- February 23, 2022
- By Greg Thomas
- In DevOps, Team
- 425
- 0
Whether you are using Agile, Scrum, Waterfall, your own implementation, the last thing you want to be focused on is the collection and aggregation of data as it pertains to your release. The Data The hallmark of any process you are using is that the data should be easily consumable, aggregated, and rolled up into
If you think you can change your team’s behavior, direction, and course in thirty days and have them executing on that change – you need to reset your goals. Leadership is a long game, the more members on your team, the harder it becomes to implement the change you know that the team needs but
When crafting a Software Delivery Process for your team or organization it’s important to identify what you want it to be. I’m not talking about whether it’s agile, waterfall, or some other variant. I’m talking about what matters to the stakeholders of that process and those that are working within it. Some call these values,
Backlogs are at the heart of your Product Delivery Strategy. Simply put, they are a story of what happens next. Whether they be bugs, epics, features, or user stories – they are a collection of the ideas, suggestions, concepts, and future of the product you one day will build. When left disorganized, they are a
Requirements are about one thing and one thing only – the Story. If you can tell the story, the team will understand what you are asking for and know why they need to build it. Everything else between Epics, Features, User Storys, Product Backlog Items, Tickets, Issues, Work Items (the list goes on and on
Software is everywhere, helping us do many things we couldn’t do years ago. Thinking back to the early days with Source Control, VSS (Visual Source Safe) was my first introduction to source control and it looked something like that. Horrific I know, you should have tried branching with it (I said a prayer each time).
As Software Managers, you need to focus on the Now – your team and deliverables. That is where the immediate need is and where your focus should be (i.e., not in the cloud on some esoteric design of some component that may or may not be used by a customer at some point in time
When you navigate to the Areas and Iterations section of your DevOps Administration you might have noticed a small blue bar at the top of the screen that indicates whether you would like to customize your work item types. In previous incarnations of Azure DevOps, this was a painful exercise as you had to run
Recently I was working with a client to troubleshoot some Azure Data Factory connection issues with an on-premise runtime when connected to Dynamics365 Linked Service. Part of that implementation required setting up the runtime as an on-premise implementation. The primary difference between an on-premise and azure runtime is that the on-premise is deployed as a
Azure DevOps is a great tool for managing your backlog and what your team is focused on “Now”. And although it’s not a project planning tool per se, many a software development team relies on the metrics that come from these systems to answer the following questions to our teams at large; Who is working