ATC’s Post

Signal-Boost-of-the-Day (SCRUM Edition): As a PRODUCT (not Project) Manager I don't really have a dog in the fight over methodologies. I've designed, helped build, and deployed products big, small, and in-between using Agile and Waterfall both. However... Based on my direct observations over the past ((mumble)) years, I think this video makes excellent points about the way that many organizations use Agile wrong. And hey... let's be honest: before those companies were 'Agile shops'. I'd bet they were 'Waterfall groups' with the exact same problems, mainly way too many meetings, too much stress from busy-body middle managers, and extreme anxiety over endless meetings and measurements striving to 'boost efficiency'. Not, you know, *using the end product as the measure* like is supposed to happen. Good PRODUCT Management is also critical to both Agile-built and Waterfall-built products. A good Product Manager will (as the video recommends) design an ENTIRE PRODUCT, with well-reasoned, financially viable, prioritized features, then break down those features' build-out into Sprints. Devs will be able to look at the big picture at all times. They'll see the target everyone is aiming for. Definitely worth taking a look - enjoy: https://lnkd.in/gsktvYWY

Software development methodologies are only as good as the results they produce. What doesn't matter: ⛔ What methodology you use. (Agile, DevOps, Extreme, Safe Agile, etc) ⛔ What tools you use. (Jira vs Basecamp, Github vs Bitbucket, vscode vs pycharm, Productboard vs ProductPlan, and on and on) ⛔ Following process for the sake of process. (Did you have that daily standup for the sake of having it, or did it add value)? What does matter: ✅ Team buy in, ownership, and collaboration. (Are the teams happy, communicating and producing quality?) ✅ Understanding what aspects of a process or methodology bring value and what don't. (Do you need to do a code release every day?) ✅ Results. (How fast are you producing a product your customers love and will pay for?) The best methodology is one that engineering teams own.

Because the first rule of agile is ‘be agile about agile’. I (with my team) tried loads of (new) tools and methods because everyone was talking about agile. In the end we realised we’d been doing our own form of agile all along, so went back to what worked for is. The biggest key things: - a simple whole team todo list that got archived (but still searchable) at end of each month. Some things got carried forwards. We had limited people. - a technical project manager role who anybody can message or phone whenever. - an emphasis of getting some part of a new feature in and live. Maybe within a few hours. And get feedback. - Chat to the users as often as possible.

What Is the Role of a Release Train Engineer? The software development industry is constantly evolving. And as such, new techniques of creating, releasing, and deploying software solutions are emerging. With the emergence of these new techniques comes new job roles and descriptions never seen before. Ever wondered how large software development enterprises with hundreds of employees and teams tend to deliver software releases seamlessly and on schedule? The answer is simple: most of these large enterprises make use of the release train, a technique offered in the Scaled Agile Framework (SAFe). In this post, we’ll be exploring the role of a release train engineer. We’ll also be looking at the need for this new role, its importance, and the qualities and skills one needs to possess in order to assume this role. But before we dive in properly, let us explore what the release train entails in itself. What Is a Release Train? A release train, which is formally called an agile release train (ART), can be said to be a long-lived collection of various agile teams working together on the same project in order to achieve the desired final product. The release train, as likened to a real-life train, harbors people from across the organization who take part in cross-functional collaboration to maintain a continuous flow of high values. There are many critical high-level personnel who operate the train. But we’ll be exploring one role in particular: the release train engineer. Who Is a Release Train Engineer (RTE)? A release train engineer is the driver and the topmost member of the agile release train. The RTE is a servant leader who uses a deep understanding of the agile framework and SAFe to steer the course of the ART with the goal of maximizing the value delivery output of the organization. The RTE coaches the teams, helps manage risks, interacts with relevant stakeholders, and, most importantly, ensures the achievement of the project goals. A train operating below its expected performance ability is no train at all. Bearing this in mind, the RTE ensures the agile release train functions are at their highest operational capability. This is necessary in order to maximize service value delivery. Responsibilities of a Release Train Engineer Every role has some peculiar responsibilities assigned and expected from the person occupying the office. Let’s explore the responsibilities of a release train engineer. 1. Personnel Management : The release train engineer is highly involved in working with every team in the agile release train. 2.Program Increment (PI) Creation : The release train engineer is also charged with the responsibility of creating the program increment chart for the project at hand. 3.Team Education : The RTE is responsible for training the entire release train on the best practices for delivering greater value #ReleaseTrainEngineer #AgileCoach #SAFe #AgileLeadership #Technology #Management #ScrumMaster

Interesting video about agile. The personal impression I got about Agile and similar methodologies is that they have one or two points, but then they degenerate when they are applied in a "dogmatic" way. In some cases I have the impression that they become an "eternal MVP" development approach: push out new features as fast as possible, without a preliminary "gran vision" planning which brings no added value to the customer, who sees only the features. This approach is quite short-sighted since, I was told, after few iterations your software is a messy patchwork of pieces of software glued by some hack to make them work together. [ I have been there (incrementally developed software) because it is how research-related software is born and grows: you do something simple to automate something, then you need to do something more, and more and more... and in the end your software is mishy mushy bowl of muesli code, fragile as egg shells. ] #devop #development #agile #scrum #scrummaster #excellence #software #pm #projectmanagement #software #quality

How relevant is Agile today? An assessment of the current relevancy of the Manifesto for Agile Software Development

Checking all the values and principles boxes in the Manifesto for Agile Software Development isn't what makes you agile. The ability to move quickly and easily is. SAFe practitioners aren't agile. But not because they don't follow the Manifesto. They aren't agile because they are the opposite of someone who moves quickly and easily. It's not a matter of preference. It's all in the definitions.

Interesting take on Agile and Scrum. For me, the question is whether Agile (Scrum) is an unsuitable way of working or if it’s often executed poorly and thus unfairly blamed. I'm not trying to defend Agile or Scrum; I'm just trying to understand whether something truly fails when not done correctly or if differing interpretations within the company are causing issues. I always point out that we are using Agile (Scrum) with certain tweaks. I listen to people to understand what works, what doesn't, what distracts them, and what wastes their time without adding value. These insights lead to custom adjustments, which might work in one environment but not in another. The key is to find the right approach for the current setup. This should be the focus for engineering managers and Agile coaches—not enforcing rigid rules, but finding a balance between productivity and team happiness. What has been your experience? Which variations of Agile (Scrum) have you tried, and have you experimented with any methodologies besides Agile (Scrum)? #Agile #Scrum #ProjectManagement #AgileCoaching #Productivity #TeamHappiness #WorkLifeBalance #EngineeringManagement #CustomAdjustments #AgileVariations #WorkplaceEfficiency #TeamSuccess #AgilePractices #AgileMethodologies https://lnkd.in/dTkJSkMS

Here is a short clip about Scrum. Do you use it for your software development?

Undertaking an Agile transformation requires an understanding of the entire software development life cycle (SDLC). Guidehouse Defense and Security has a proven history of helping government clients implement Agile projects of varying scopes. Read the article below, where we debunk six common myths about Agile implementation.