This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-05-11
Channels
- # ask-the-speaker-track-1 (130)
- # ask-the-speaker-track-2 (99)
- # ask-the-speaker-track-3 (94)
- # ask-the-speaker-track-4 (172)
- # bof-arch-engineering-ops (2)
- # bof-leadership-culture-learning (2)
- # bof-project-to-product (23)
- # bof-sec-audit-compliance-grc (2)
- # discussion-azure-ballroom (730)
- # faq (6)
- # games (7)
- # games-self-tracker (1)
- # gather (28)
- # happy-hour (17)
- # help (34)
- # hiring (11)
- # networking (8)
- # project-to-product (1)
- # summit-info (28)
- # summit-stories (1)
- # xpo-bmc-ami-devops (1)
- # xpo-cloudbees (1)
- # xpo-cockroachlabs (2)
- # xpo-github-for-enterprises (1)
- # xpo-gitlab-the-one-devops-platform (3)
- # xpo-itrevolution (4)
- # xpo-launchdarkly (3)
- # xpo-lightstep-observability-incidentresponse (1)
- # xpo-linearb-automate-dev-team-improvement (9)
- # xpo-planview-tasktop (2)
- # xpo-snyk (1)
- # xpo-split (18)
- # xpo-stackoverflowforteams (2)
- # xpo-synopsys-sig (4)
- # xpo-tricentis-continuous-testing (2)
Reminder: Get yourself in front of your browser and into #ask-the-speaker-plenary for the opening remarks. We’re kicking off Day 2 in 15 minutes at 10am BST! https://devopsenterprise.slack.com/files/UATE4LJ94/F01D34MC2KS/image.png
Reminder: Day 2 is starting now – opening remarks and then plenary talks! Join the conversation in #ask-the-speaker-plenary.
Reminder: The breakout sessions are starting in 5 minutes. Get in front of your browser and start navigating your way to whichever session you’re attending. https://devopsenterprise.slack.com/files/UATE4LJ94/F01D34MC2KS/image.png
✨ Introducing @patricia.burke SVP SaaS Operations, and @joshua.d.berry Senior Director, Service Management of Duck Creek Technologies presenting with @jim CTO / VP Engineering Consultant, Cuff Technology Solutions. They will be presenting, Using Value Stream Mapping to Create Shared Understanding and Teamwork Across Functional Boundaries ✨
Credit Hero to Zero talk I mention: https://vimeo.com/104252736
The group really got a full view of the system: https://deming.org/appreciation-for-a-system/
Yes - without mentioning TOC - the biggest constraints on the system "jumped off the page"
we marked them with a image of a sad SpongeBobSquarePants
(which came up organically in the session)
“I don’t need to open spreadsheet; I know we won’t be adversely impacting customers anymore” 🎉
Ah cool. People get confused by constraints and forget some are actually enabling.
It was interesting that there was a strong instinct on self improvement (which was great), but it was focussed on a subsystem - where the individual had control / autonomy to make improvements. This exercise moved that improvement mindset to a whole system view
Miro. And lately the Remote Agility Framework templates which are all encompassing
tools used for VSM: whiteboard, miro, lucidspark... anything which works and you are able to bring all stakeholders to a common discussion
Do you have some examples how a VSM can look like? How to find the perfect amount of high level vs. detailed!
The working copy we came up with is in the slides: https://github.com/devopsenterprise/2022-virtual-europe/blob/main/BURKE-TRICIA_CUFF_BERRY_Using%20Value%20Stream%20Mapping_SLIDES.pdf
it all depends on the context, on what you are addressing, i usually start with very high level view to address it end-to-end, and later dive into details ... key is that next to process, you add the process metrics next to it, as it was shown by @jim and the team in the presentation above
+1 to what Piotr said, right-sizing the map and meeting the participants where they are means it varies, but I try to make very minimal, clear maps like this
Do you think we have a tendency to adopt new tools rather than learning to use our existing ones? Sometimes I think we can fall into the “oooh shiny!” trap which means folks have to learn a new tool as well as engage in the process.
It might have seemed counter-intuitive, but POWERPOINT was the tool that worked best for the group (as it spanned beyond tech AND it was already a familiar / level playing field for everyone)
Agreed - whatever you have to hand (we used MURAL and lots of calls!). I've seen teams delays for so long trying to find the perfect VSM tool (which is what I loved the use of powerpoint to get started 🙂 )
And my apologies that the slide link in your video is wrong: it should be https://github.com/devopsenterprise/2022-virtual-europe/blob/main/BURKE-TRICIA_CUFF_BERRY_Using%20Value%20Stream%20Mapping_SLIDES.pdf @alex Can we fix?
I love the value stream “how it started vs how it’s going” diagrams! 😆
I think this is sometimes what scares people going into a VSM - the expectation that it should look like a nice clean "example" board - whereas in reality is always going to be a mess (in a good way)
Past of our business has the problem now. 1 year of trying to solve for a large problem and zero progress focusing on one tool to rule them all, but without a strong flow principles - agile Culture to leverage off…
⭐ Please welcome, @rob.howse, Executive Director and Chief Operating Officer at Leeds Building Society. He will be presenting, Taming the Complexity – Accelerating Value Delivery ⭐
Thanks Ann. Hi everyone. Hope you enjoy the talk. Would love to hear your questions, thoughts and…advice
yes, the challenge I see is that without a system view, many can only see their local optimizations!
We struggled to change particularly technology heavy change and that threatened our future
I think that is what is so fascinating about financial industry making amazing transformations - every excuse for it to be difficult - funding, legacy architectures, annual funding, regulation, context switching
It is also fascinating to me is that some are realizing the issue but many still aren't. I'm curious what the turning point was
Context Switching = the old name for cognitive load? It's easy to be busy and difficult to be effective.
Hello buddy great to see you here ! And yes I agree on the team cognitive load view ! Although you can have one main context and still Excessive cognitive Load due to interdependence
Good to see you too, it's a late night! True, I hadn't thought of it that way.
"something that could cope in the variety we had in the nature of the work, but in a lean way"
Interesting Rob You picked a product / business domain as the source of demand/ design anchor . Did that still disconnect you from the customer ?
I think across the finance industry the most organisations now recognise this is the journey they need to go on but not all are making the same level of progress. For me I’d seen what was possible in pockets of other organisations and became convinced that we could do it. I also had the benefit that I was brought in by the board to effect that change (not that they knew what agile was when they hired me)
Phil, actually the product business domains mapped very closely to the customer domains. There is very little overlap in the customer base between savings and mortgages
How did you handle dependencies across these product teams? A programme team?
how were the dependencies discovered? Often difficult to make them visible
Katherine, I think we’ve done ok finding the dependencies through the normal existing mechanisms (eg., delivery managers) what we haven’t got really working yet is the measurement of dependencies via tooling. At the moment we’re trying to get tickets to flow between teams using JIRA but we have more to do here. We also haven’t moved to release increment planning sessions (like SAFe). Interesting we used to have a regular cross-stream dependencies meeting at the start but then removed it as very little was being discussed that hadn’t been known about by other means.
I presume that since this is Fintech, the speed of releases never compromised quality (security)?
You can be 160 year old bank to do this. It doesn't need need to be FinTech.
point is, many of my clients focus on reducing time between releases, but compromise security in doing so
I like the connection of engineering metrics to business outcomes. Customer on-boarding, mortgage approvals.
Thanks Matt. One of the benefits of the tight business alignment and business value based OKRs was that it is really easy to tell that story and really easy for everyone working on the teams to understand their contribution.
We kept delivery managers in the model so we still have a ability to coordinate across teams. This was a pragmatic decision. I’ve seen other agile implementations fail because they removed all the project managers before they addressed the dependencies and then wondered why everything stopped.
Also curious how motivation for change was maintained - did teams do demos for business/leadership along the way for example
As you moved to the Programme/Agile team model - what kept the long lived Agile team busy between the larger releases from the programme until you increased the release frequency?
Hi Mark, the agile teams all had their own backlogs, so were working on smaller activity or elements of the larger programmes. I haven’t found a team that isn’t busy yet!
The difference between what you can do in an emergency and what you can do in a normal day is roughly your bureaucracy overhead.
I love that. although to be fair to my risk colleagues, they would probably say that impact of a lack of bureaucracy (“control”!) is often only felt later when you realise, for example, you’ve introduced a big security flaw or upset your regulator
@rob.howse - Great session. We had some mistakes in our own journey - not creating great products owners before great devops teams. Wondering if you had something similar
I am not sure we’ve got the journey or sequencing right - time will tell. We moved structurally to the model before we trained people so have a lot of people in roles where they are quite inexperienced. One example is POs. They challenge that is leading to is a difficultly in value slicing some of the work. However, i think on balance I’d still do it in that order as we got a big improvement in performance and culturally from making the structural change
@rob.howse This is so fascinating and resonates strongly with us at New Look Retailers at a similar scale of tech complexity. I see you have an approach to choosing when to keep delivering as programmes vs changing to continuous streams. What % mix of programme vs stream did you end up with?
I think we are at best 30-50% agile at the moment. Although in some of the big programmes (like data centre) we found ways to be more agilely
Hi Katherine, on motivation, i think success bred success. We talked about this a lot. The work some of the teams did/do has featured in updates our CEO gives to the whole company. We’ve done demos for board members. We spend a lot of time internally as a business talking about what is going on so there was plenty of visibility of progress.
How you tackle The leadership cohort? Giving up so sometimes hard to do !
Hi Phil. As a i was a large part of the leadership cohort and had a fair amount of organisational authority that helped. But I also have a lot of supportive senior colleagues and when they saw some of the benefits in Covid most of them were willing to to support. We still have some challenges in terms of moving the governance culture but we are making progress there and have been delegating more authority but still have further to go. We just keep pushing it a bit, showing that it is not a disaster and pushing a bit further. (And incremental, test and learn approach to changing governance!)
Changing governance for the safer, faster value delivery is a fascinating topic and FSIs have learnt a lot about how to do it. Morgan Stanley gave an excellent talk on that yesterday. @gus.paul for Change Management. I love these conferences as they help join the dots.
Thanks Matt. One of my Heads of Technology was very excited having seen the Gus’s presentation
Totally it's the forgotten element. How often do you see large scale transformation with no change to governance activity and actions ? It limits the effectiveness of any change to system, org design and op model. There's this aura that governance is untouchable which Once you dig past the shared standard narrative / mental model is often incorrect
Totally agree on pushing slowly but incrementally with risk and audit folk who tend to be from legal background not tech - so human accountability written audit trail is instinctively what they want. Even what I presented yesterday is only 10% of changes at the moment, but we are growing steadily and staying stable which gives them confidence.
It also gives us a track record in the data (there is the audit trail again) so that when we get the inevitable blow up, we can show it's the outlier
@rob.howse multiple times you underlined having long-lived teams. Although I know there is a basis in the IT-industry now to keep long-lived teams, I myself have seen short-lived teams deliver astonishing work and short-lived teams are a given in some non-IT industries. Why did you decide on having long-lived vs. short-lived teams? What are your thoughts on long-lived vs. short-lived teams?
Industries/circumstances with short lived teams are numerous, delivering astonishing work: • Operating tables • TV / movies • Especially many freelancer driven industries
Hi Malte, for 2 reasons: 1) while short lived teams can deliver astonishing results generally long lived teams can out perform them. They are able to improve over time, build trust etc. You see this in sports teams were those that are stable are often better and the national teams often underperform (at least in England!) club sides. 2) to get flow going you need a degree of stability in the organisation so that you optimise. Long lived teams give you that. Short lived ones don’t.
Hi Rob, I do understand that, but seeing short-lived teams thrive I am just really not sure about that in general. Also the idea of the Tuckman phases seem off. If they really need to occur they at least might be really short depending on the team. So short in fact, that they don't matter anymore? But maybe it is the expertise of team members that changes the need for longevity. Perhaps when dealing with highly specialiced, highly trained people, the amount of time they work together does not influence the outcome anymore, at least not significantly? And what about the environment? Might it be the case that the environment teams interact in can influence the need for long-lived teams? @me1208 longevity of teams is also a topic in your book and I know there is scientific evidence for long-lived teams. Have the variables mentioned here been taken into account in the studies you looked at? What's your take on this?
@z-itrevolution The variables you mention matter certainly. I suppose, other variables / dimensions are at play as well. When you say "short-lived", what is the time horizon you have in mind? When does "short-lived" end and when does "long-lived" start :)
I think 6 months is seen as a solid timeframe teams stabilize. So I would say short lived < 6 months, long lived > 6 months.
@stephan.stapel Looking at your pattern #3, what is your look on the team's lifetime? How did you manage changing teams in pattern 3, joint development?
The teams themselves remain in their original setup. It is just that they join temporarily to work on a particular feature. The question is rather how we can plan and align the plans of these two teams. Did I understand the question correctly?!
Yes, great, thanks a lot. If I understand correctly, that would be "cooperation" in terms of team topologies. Back to the longevity: In your talk you mentioned that the slow-teams are "longer" lived. Is there a difference between the lifetime of slow and fast teams in your company?
Good point. Not in terms of lifetime of the team but in terms of the time that people actually stay in such teams.
Reminder: The breakout sessions are starting again in 5 minutes. Get in front of your browser and start navigating your way to whichever session you’re attending. https://devopsenterprise.slack.com/files/UATE4LJ94/F01D34MC2KS/image.png
⚡Let's welcome @richard.james2, Technology Lead, Nationwide Building Society, here to present Enterprise on the Bleeding Edge ⚡
Keep seeing more and more Jamstack - love the details here @richard.james2.
From a reslience, experience and environmental perspective Jamstack is win-win-win!
ADRs are a great tool. And @richard.james2 props for delivering to production in a regulated financial institution in an hour! Certainly impressive. I'd be interested in the way you generate your release record and handle approval documentation!
At the time, we had a manual step in there specifically for PR notes & test outcome reports. It has been automated now into ServiceNow.
Did you ever formalise your Open Source interactions? e.g. legal sign-off of giving code, guidelines for adoption or what it more informal?
@TeamTopolgies mention 😀. Not listened to a single talk yet, that didn't mention it.
Not sure 😀. But I am quite happy that it seems to have quite a lot of impact!
⚡We welcome @catchmebala Principal Architect, TJX, who will be sharing Journey to a Continuous Everything ⚡
Happy to share Application tech debt assessment template if anyone interested...
Reminder: The plenary sessions are starting again in 5 minutes. Start making your way back to your browser and join us in #ask-the-speaker-plenary to interact live with the speakers and other attendees. https://devopsenterprise.slack.com/files/UATE4LJ94/F01D34MC2KS/image.png
Reminder: Please submit your feedback for the talks you attended. It’s so valuable for us and the speakers. And after all, feedback is a gift and sharing is caring! Enter your feedback for those talks here: https://members.itrevolution.com/live/schedule https://devopsenterprise.slack.com/files/UATE4LJ94/F03E48CJRF1/image.png
