This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
Chris, my firm used to have EVERYTHING go through a formal architecture review board evaluation. You filled out a form and then had to get on the schedule where meetings were held once a month. However, then we moved to a model where potential items where categorized. Those that didn't require representation at one of the formal meetings could be "fast-tracked". They were still reviewed by the board but the scrutiny from other parts of the firm was much less.
Yeah we have moved from an ARB model to a architecture as a functional coach role. They set standards and compliance then train up teams to be self reliant
@cuzza0 fully agree. what I am experiencing is the difficulty for Architects to accept the emergence and how architecture should connect with engineering. Ivory tower does not work! Arie van Benekum (Agile manifesto) said that anybody that can stand in the way of the team should be part of the team itself to facilitate. It fits completely with the idea of an architect as a coach rather than a judge.
I have experience with fast tranck vs formal architectural review process (and security). what it ends being is agile teams trying to shape problems to fit fast track and hiding complexity or other worse things. In my experience this situation comes to place from a leadership that is not align, some being agile, more interative and some others working on a long formal process fit for a more waterfall approach (these feelings spread really easily with side comments from leads to teams which makes it a you vs us scenario too and makes the problems to be owned by no one). I think this is all about culture and leadership. Formal one month reviews, will only hold things from moving. Not setting aligment and comms channel will make architecture to crumble. So I think we need some indivuduals in the teams to hold the architect hat (that being a software architect, a TL or EM), we need those to meet up and openly discuss questions and decision. This is all part of the culture, trust, respect, safety, ... there is no such a thing as an stupid question o discussion. decisions are discussed more organically, but always with the principle of cost of change in mind. Ive been on the opposite word too, where there are no architects, we all sit in open floor and we as IC / TLs raised concers with diversity of approachs, consistency, solving same problems over and over and not really knowing how to work together. The answer was “but you all sit together, you can just talk to each other”. Like putting you in a room should make you to talk and work well together. This I think happens more often that we think too. To avoid that, we also need leadership roles that glue boundaries, see how domains fit together, champion engineering standars / arch primciples, suggest conversations between teams, are invited to design sessions as coaches, ... and help to keep those open forums alive, and are embassadors of the culture (call this solution or enterprise architects / Principle eng /...).
I wonder if it's a lack of alignment with the business is what "agile" means. For example, McKinsey has defined for CEOs that "appropriate" question to assess agility is "how many projects do you kill?" A question I have for the group is if you work for a CIO who isn't convinced to turn to Agile, Lean, and DevOps, is the only option to go the #CS0PBGEU9? "Agile working methods. Agile working methods produce good results quickly by having technology teams develop starter versions of new products, share them with users, and make round after round of improvements that users want.6 CEOs can test IT’s agility by asking, “How many projects has IT shut down because they weren’t providing value?” If IT hasn’t shut down some projects, then the function hasn’t truly embraced agile. That’s because agile practices call for ending projects as soon as it’s clear that they aren’t working out—and for celebrating the discretion of the people involved."
I wonder if it's a lack of alignment with the business is what "agile" means. For example, McKinsey has defined for CEOs that "appropriate" question to assess agility is "how many projects do you kill?" A question I have for the group is if you work for a CIO who isn't convinced to turn to Agile, Lean, and DevOps, is the only option to go the #CS0PBGEU9? "Agile working methods. Agile working methods produce good results quickly by having technology teams develop starter versions of new products, share them with users, and make round after round of improvements that users want.6 CEOs can test IT’s agility by asking, “How many projects has IT shut down because they weren’t providing value?” If IT hasn’t shut down some projects, then the function hasn’t truly embraced agile. That’s because agile practices call for ending projects as soon as it’s clear that they aren’t working out—and for celebrating the discretion of the people involved."
Agree with you Laura. People will do what they can to get what they want via the path of least resistance. They'll learn to job the system if it means having to acquire less approvals and less scrutiny to get what they want. Unfortunately, my workplace is very similar to what Maxine learns while trying to get her development environment. Lots and lots of approvals required to get even the simplest of things done. Bottlenecks are bad and stifle agility!
<!here> We will be starting the first Ask Me Anything AMA with Gene Kim in about 15 minutes. Link to join: https://zoom.us/j/477919024 (recording will be made available afterwards for those who can't join live) The questions he'll be answering are coming from those posted in #ama_unicorn_project if you'd like to follow along.
The interaction with Derek has an interesting arc in that Maxine transitions from seeing him as an enemy to having empathy for the fact that his hands are tied too. It reveals/reinforces that the culture is bureaucracy driven and not “friends doing things for friends”
The interaction with Derek has an interesting arc in that Maxine transitions from seeing him as an enemy to having empathy for the fact that his hands are tied too. It reveals/reinforces that the culture is bureaucracy driven and not “friends doing things for friends”
It is also an example of what is called task identify in hr motivation theory. This is a major part of what motivates people and gives purpose. Derek does not understand how his piece of work fits into the larger picture. This is a demotivating force and also leads to outcomes which do not create value (or contributes to unnecessary costs). It is not driven from Derek himself - he has no desire to do a bad job. It is a problem with the organization of work. The opposite would be Derek understanding what the overall goal would be, perhaps by an effective common vision or perhaps from a transparency of how work affects others (a de-silo-ing of work). I.e. understanding the identity of the task and why it is required. Difficult to do if you just do the same boring repetitive task that has been given to you without your input. This is generally why teams are granted autonomy to address this (which brings its own coordination and communication issues - but these are better problems to solve).
Reminder: we are currently live with Gene in the AMA!! Join us: https://zoom.us/j/477919024
Reminder: we are currently live with Gene in the AMA!! Join us: https://zoom.us/j/477919024
<!here> Reminder: Please use threads when replying to a comment or participating in a discussion here. To do so, hover over a comment and click "Start a thread" if you aren't already in one (you can't open a thread inside another thread)
<!here> Thanks everyone for all the engagement with the AMA earlier. The recording is being processed and will be made available as soon as possible. We'll email and ping here on Slack. Your evening (for some of you) discussion topic.
<!here> Thanks everyone for all the engagement with the AMA earlier. The recording is being processed and will be made available as soon as possible. We'll email and ping here on Slack. Your evening (for some of you) discussion topic.