CitconWiki - User contributions [en]

Program Management

2023-02-06T02:31:09Z

Yuliya: Created page with "Context: In lots of situations Program Management isn't the problem. A lot of times development practices could be better, product selection could be better, etc. But what if..."

Context: In lots of situations Program Management isn't the problem. A lot of times development practices could be better, product selection could be better, etc. But what if developers are on top of it, and the product is good? How does program management look, and can it be a useful and honest activity, i.e. not just scheduling meetings and not operating in a world of "make pretense" plans that no one believes in.
----
# TPM - makes it clear how what we are doing comparing to the plan. Forcing conversations about "we were planning for it to take 3 weeks, it's gonna take 3 months, we need to talk". Heavily use data for calling bs.
# Someone created a plan, they talked to engineers, they did their best. Assume they did their best, and life happens, we are learning the plan is wrong.
# Important not to have the culture of "you guys made a plan, stick with it", it's important to have a culture of trust and improvement and collective decision.
# Program management - project manager across projects. Part of their job is calling bs, and making people talk, and make decisions, changing the time or the scope. "What do we do?" - collective decision and ownership.
# Does TPM ID the problem or is also part of the solution? Depends on the level of a TPM, starts with program management and asking good questions. With experience - more technical and more solutioning.
# TPM is in some way a bridge between different disciplines that might not be motivated to drive
# In another company, TPM is facilitating a recurrent Risk meeting. However, there's a fortnightly release meeting, which is way too slow. In a lot of implementations, program planning is coupled with releases, and TPMs represent the engineering team to the larger corporate people, and talking x-functional talk (eg. legal, marketing, etc)
# Still, the role of the TPM to force the visibility
# Planning
* If there's a specific deadline - go back from the deadline, that makes it easier to give realistic estimates
* Not granular. 5-10 rows, if you need to scroll - too much detail. What needs to be done before what, what can be done in parallel, what has a long lead.
* Pushing back the rest of the schedule if that's what happens. Eg. We were planning to get this done in 4 weeks. 2 weeks later we are not half way in. Means it's gonna take more than 4 weeks. What do we do now".
* Being a time domain person, helping everyone
* If there's a gahnnt chart, people are gonna manage it. Sometimes it's helpful to hide it
* Starting with a plan - take a roadmap without dates. Or with dates. Eg. CEO told the board we're gonna do something by some date. Good to understand why that date.
* TPM's role is asking questions, and following up with "but my original question wasn't answered"
* During the planning time, find dependencies and interfaces, which is regardless of time and estimates. Sometimes a way to facilitate a conversation is to remove schedule off the table, and learn about dependencies and interfaces and uncertainties/risks and what needs to come before what.
* Unicorn or making x-discipline people talk? Unicorn is helpful, also can see if can enable someone to raise into this role. Otherwise, those two people need to talk, and why would they not?
* Episode 248 from Troubleshooting agile
* SAFe works for some (rare) occasions. But it can work, and it can work well. It shows what's ahead of us, what we need to deliver, what are dependencies. Let's say you have a large 10m project. Break it down into thirds, and see if you can do a third in 3m. That's how you'll get information about whether it's realistic. Prioritize projects using WSJF. Then the team says "we can only do 3 projects, not 5" for example, then you negotiate. WSJF motivates slicing :)

CITCONNA2023Sessions

2023-02-04T23:18:06Z

Yuliya:

10am

# [[Beyond XP]] (Story of Pivotal Cloud Foundry post VMware acquisition)
# [[Impact Driven Testing and Gap Analysis]]

11am

# [[Testing Microservices]] (Queen's gambit)
# [[ADRs, Guardrails and Golden Paths]] (Bojack Horseman)

2pm
# [[Monitoring driven development]]

3.15pm
# [[Program Management]]

Monitoring driven development

2023-02-04T22:53:56Z

Yuliya:

Context: There was this company who was doing all the agile things looking from the outside, however from the inside...
It was a SaaS product, and they were incredibly immature in terms of running a production system - lots of trivial knowledge, lots of reliance on that one guy.
We walked through the "marketecture", and go through every line - "what would happen if this arrow didn't work?". And things broke down very quickly. And then I thought about it from TDD background - how would we develop software differently if we were to think about how are we gonna monitor software.
----
Conversation notes:
* Would this replace testing? Maybe some, maybe acceptance testing, but not unit testing or TDD. Or maybe running your acceptance testing in production is a form of monitoring. Not replacing or removing acceptance testing before production, instead running acceptance tests in prod in addition to running them during the pipeline.
* Why isn't it done already? Probably cause there's traditionally separation of concerns between dev team and ops/maintenance team.
* So, what are the goals? Eg. unit testing = code works as expected, acceptance testing = product works as expected ==> monitoring = user receives value as expected.
* Eg. in the origin of DevOps there was an idea of using what's happening in production to inform next work in development. And not only whether features are broken or not, but also whether features are used
* Staggered rollout process: if unit tests or system tests fail - roll back the commit. If it works - roll it out to one node, and monitor number of dollars per minute that node produces, compare to other nodes, and if it produces less dollars - do not roll out the change more widely.
* Bringing telemetry into the conversation, the question comes up - when do you analyze it? And who gets alerted? And for monitoring or alerting - you can't add that after the fact if the data doesn't exist, you need to design the system with alerting and monitoring in mind.
* You can also do something like that with a test customer account and feature flags. The number of feature flags creeps up though, and becomes very challenging to manage. There's a policy to remove the feature flags that are older than 6m old, and there's an internal module to manage feature flags and removing flags that's older than threshold.
* Sometimes it's easier to add monitoring to the existing code then finding seams, extracting code, wrapping it in tests, etc.
* Honeycomb was mentioned several times.
* Data volume problem shows up, what do you do when you have 1Tb data per day (which happens if you have too much data).
* Sounds like lots of us are doing it, what's the problem? - We aren't discussing monitoring from the start, we aren't developing with monitoring in mind. Monitoring is supposed to answer a question whether the product is bringing the value it was intended to bring.
* Done vs Done-done = on one of the kanban boards we expanded it all the way to "1st customer used it", and we wouldn't take it off the board until the first customer used it.
* Product management lots of time thinks about what to build, and might even think about market adoption - but rarely go back when the feature is used, and monitor how well their features perform. Which gives no accountability to product management. This could be a healthy thing to look at when the pressure is always on developers to build faster, it gives accountability to PMs about choosing what to build. Cause if we build trash faster - won't make a difference.
* Another approach - check usage by months. How many people used the product at least once month during the year? Two months? How come this feature, that people should use every day, and it's used one month of the year. So, distinguish between "is it working now" and "is it working over time".
* How to get PMs to pay attention? - Ask "How would we know that it works in production? How would we know it makes the impact we hope it makes" when you're talking about a new feature.
* "We are gonna A/B test it" - how many interactions you want to see for statistically significant information? How many users do you have? How much improvement do you want to see? Cause in some situation it's gonna take a year to get that information, and then A/B isn't a good solution
* How much a process helps to solve a problem? Thinking about it from Cynefin framework perspective: situation can be simple, complicated, complex, or chaotic - and in some situations process is helpful, and in some - you need mastery of a person with expertize.

Monitoring driven development

2023-02-04T22:44:39Z

Yuliya:

Monitoring driven development

2023-02-04T22:08:52Z

Yuliya: Created page with "Context: There was this company who was doing all the agile things looking from the outside, however from the inside... It was a SaaS product, and they were incredibly immatu..."

CITCONNA2023Sessions

2023-02-04T22:03:40Z

Yuliya:

Testing Microservices

2023-02-04T20:14:57Z

Yuliya:

Conversation notes
* Splunk stack and hashi wrapper for monitoring
* NOC (Network Ops Center) -
* New bank - common stack, clojure, AWS
* Netflix also started with same stack, but it diverged assuming commonality of contracts. But Netflix has fantastic monitoring practices
* Challenge - in a micro-services environment, how do you catch issues before production if all tests were fine for individual environments?
* Heavy Monitoring
* Learning the process for a year before automating it was helpful (some automations are not needed)
* Disney provides client libraries. Versioning - providing min and max. Netflix - started with that, had to stop cause there was too many different libraries.
* Sometimes new practices require change in culture.
* Deploying across different geographic zones has to be staggered - deploy to EU, wait for 6 hours, confirm it works, deploy to next region
* Microservices could become distributed monolith, one reason - relying on shared datastore.
* At Netflix, rather than trying to find issues in test, and trying to reproduce production (too expensive), Netflix invested in monitoring and expediting the fixing, and implementing "roll back" and "roll forward".
* In context of "roll back", do people use SLAs or KPIs? SLAs are helpful to make data driven decisions to invest into improving certain services, but also can become a stick for management to use in a toxic way.
* Is there a gold standard for data around service performance? Alternative way - find outliers comparing to average performance of similar services.
* In the notion of error-budget, in some cases you'd halt deployment if service isn't complying with specific metrics. You could override it, it's manual effort, and with timezones you sometimes need a duplicate team that you need. Netflix decided against error budgets not to introduce the additional burden of bureaucracy around it.
* When we need teams to update their services, "should" didn't help - teams need to do a lot of things they "need" to do. What worked for some folks - include this kind of work into a plan, and set up expectation with the company and leadership that engineering will spend 70% of time on features, and 30% on all kinds of "stuff comes up". Still takes time, but works. But the culture change needs to come from the top down.
* So, what do you do when stuff still goes down in prod? There's an incident commander / coordinator / collator - finding who needs to roll back / roll forward whatever needs to be done, and then coordinating a post mortem, which everyone can join. Action items are separated into short-term, med-term, and long-term.
* COE (correction of error) can become a cause of tension, who's responsible for fixing things? How do you ensure teams are motivated and enabled to spend time fixing their things?
* A lot of engineers understand technical KPIs but not business KPIs. Helping developers see how their work affects actual business metrics proved helpful. And severity of the incident must depend on the business impact, not on the internal politics (i.e. trying to hide incidents under "p2" to not get on CEO's radar)
* "If it's painful - do it more often" principle

Testing Microservices

2023-02-04T20:14:42Z

Yuliya:

Conversation notes
* Splunk stack and hashi wrapper for monitoring
* NOC (Network Ops Center) -
* New bank - common stack, clojure, AWS
* Netflix also started with same stack, but it diverged assuming commonality of contracts. But Netflix has fantastic monitoring practices
* Challenge - in a micro-services environment, how do you catch issues before production if all tests were fine for individual environments?
* Heavy Monitoring
* Learning the process for a year before automating it was helpful (some automations are not needed)
* Disney provides client libraries. Versioning - providing min and max. Netflix - started with that, had to stop cause there was too many different libraries.
* Sometimes new practices require change in culture.
* Deploying across different geographic zones has to be staggered - deploy to EU, wait for 6 hours, confirm it works, deploy to next region
* Microservices could become distributed monolith, one reason - relying on shared datastore.
* At Netflix, rather than trying to find issues in test, and trying to reproduce production (too expensive), Netflix invested in monitoring and expediting the fixing, and implementing "roll back" and "roll forward".
* In context of "roll back", do people use SLAs or KPIs? SLAs are helpful to make data driven decisions to invest into improving certain services, but also can become a stick for management to use in a toxic way.
* Is there a gold standard for data around service performance? Alternative way - find outliers comparing to average performance of similar services.
* In the notion of error-budget, in some cases you'd halt deployment if service isn't complying with specific metrics. You could override it, it's manual effort, and with timezones you sometimes need a duplicate team that you need. Netflix decided against error budgets not to introduce the additional burden of bureaucracy around it.
* When we need teams to update their services, "should" didn't help - teams need to do a lot of things they "need" to do. What worked for some folks - include this kind of work into a plan, and set up expectation with the company and leadership that engineering will spend 70% of time on features, and 30% on all kinds of "stuff comes up". Still takes time, but works. But the culture change needs to come from the top down.
* So, what do you do when stuff still goes down in prod? There's an incident commander / coordinator / collator - finding who needs to roll back / roll forward whatever needs to be done, and then coordinating a post mortem, which everyone can join. Action items are separated into short-term, med-term, and long-term.
* "If it's painful - do it more often"
* COE (correction of error) can become a cause of tension, who's responsible for fixing things? How do you ensure teams are motivated and enabled to spend time fixing their things?
* A lot of engineers understand technical KPIs but not business KPIs. Helping developers see how their work affects actual business metrics proved helpful. And severity of the incident must depend on the business impact, not on the internal politics (i.e. trying to hide incidents under "p2" to not get on CEO's radar)
* "If it's painful - do it more often" principle

Testing Microservices

2023-02-04T20:12:57Z

Yuliya:

Conversation notes
* Splunk stack and hashi wrapper for monitoring
* NOC (Network Ops Center) -
* New bank - common stack, clojure, AWS
* Netflix also started with same stack, but it diverged assuming commonality of contracts. But Netflix has fantastic monitoring practices
* Challenge - in a micro-services environment, how do you catch issues before production if all tests were fine for individual environments?
* Heavy Monitoring
* Learning the process for a year before automating it was helpful (some automations are not needed)
* Disney provides client libraries. Versioning - providing min and max. Netflix - started with that, had to stop cause there was too many different libraries.
* Sometimes new practices require change in culture.
* Deploying across different geographic zones has to be staggered - deploy to EU, wait for 6 hours, confirm it works, deploy to next region
* Microservices could become distributed monolith, one reason - relying on shared datastore.
* At Netflix, rather than trying to find issues in test, and trying to reproduce production (too expensive), Netflix invested in monitoring and expediting the fixing, and implementing "roll back" and "roll forward".
* In context of "roll back", do people use SLAs or KPIs? SLAs are helpful to make data driven decisions to invest into improving certain services, but also can become a stick for management to use in a toxic way.
* Is there a gold standard for data around service performance? Alternative way - find outliers comparing to average performance of similar services.
* In the notion of error-budget, in some cases you'd halt deployment if service isn't complying with specific metrics. You could override it, it's manual effort, and with timezones you sometimes need a duplicate team that you need. Netflix decided against error budgets not to introduce the additional burden of bureaucracy around it.
* When we need teams to update their services, "should" didn't help - teams need to do a lot of things they "need" to do. What worked for some folks - include this kind of work into a plan, and set up expectation with the company and leadership that engineering will spend 70% of time on features, and 30% on all kinds of "stuff comes up". Still takes time, but works. But the culture change needs to come from the top down.
* So, what do you do when stuff still goes down in prod? There's an incident commander / coordinator / collator - finding who needs to roll back / roll forward whatever needs to be done, and then coordinating a post mortem, which everyone can join. Action items are separated into short-term, med-term, and long-term.
* "If it's painful - do it more often"
* COE (correction of error) can become a cause of tension, who's responsible for fixing things? How do you ensure teams are motivated and enabled to spend time fixing their things?
* A lot of engineers understand technical KPIs but not business KPIs. Helping developers see how their work affects actual business metrics proved helpful. And severity of the incident must depend on the business impact, not on the internal politics (i.e. trying to hide incidents under "p2" to not get on CEO's radar)

Testing Microservices

2023-02-04T20:11:58Z

Yuliya:

Testing Microservices

2023-02-04T20:11:20Z

Yuliya:

Conversation points
* Splunk stack and hashi wrapper for monitoring
* NOC (Network Ops Center) -
* New bank - common stack, clojure, AWS
* Netflix also started with same stack, but it diverged assuming commonality of contracts. But Netflix has fantastic monitoring practices
* Challenge - in a micro-services environment, how do you catch issues before production if all tests were fine for individual environments?
* Heavy Monitoring
* Learning the process for a year before automating it was helpful (some automations are not needed)
* Disney provides client libraries. Versioning - providing min and max. Netflix - started with that, had to stop cause there was too many different libraries.
* Sometimes new practices require change in culture.
* Deploying across different geographic zones has to be staggered - deploy to EU, wait for 6 hours, confirm it works, deploy to next region
* Microservices could become distributed monolith, one reason - relying on shared datastore.
* At Netflix, rather than trying to find issues in test, and trying to reproduce production (too expensive), Netflix invested in monitoring and expediting the fixing, and implementing "roll back" and "roll forward".
* In context of "roll back", do people use SLAs or KPIs? SLAs are helpful to make data driven decisions to invest into improving certain services, but also can become a stick for management to use in a toxic way.
* Is there a gold standard for data around service performance? Alternative way - find outliers comparing to average performance of similar services.
* In the notion of error-budget, in some cases you'd halt deployment if service isn't complying with specific metrics. You could override it, it's manual effort, and with timezones you sometimes need a duplicate team that you need. Netflix decided against error budgets not to introduce the additional burden of bureaucracy around it.
* When we need teams to update their services, "should" didn't help - teams need to do a lot of things they "need" to do. What worked for some folks - include this kind of work into a plan, and set up expectation with the company and leadership that engineering will spend 70% of time on features, and 30% on all kinds of "stuff comes up". Still takes time, but works. But the culture change needs to come from the top down.
* So, what do you do when stuff still goes down in prod? There's an incident commander / coordinator / collator - finding who needs to roll back / roll forward whatever needs to be done, and then coordinating a post mortem, which everyone can join. Action items are separated into short-term, med-term, and long-term.
* COE (correction of error) can become a cause of tension, who's responsible for fixing things? How do you ensure teams are motivated and enabled to spend time fixing their things?
* A lot of engineers understand technical KPIs but not business KPIs. Helping developers see how their work affects actual business metrics proved helpful. And severity of the incident must depend on the business impact, not on the internal politics (i.e. trying to hide incidents under "p2" to not get on CEO's radar)

Testing Microservices

2023-02-04T20:05:20Z

Yuliya:

Testing Microservices

2023-02-04T19:38:09Z

Yuliya:

Tools
* Splunk stack and hashi wrapper for monitoring
* NOC (Network Ops Center) -
* New bank - common stack, clojure, AWS
* Netflix also started with same stack, but it diverged assuming commonality of contracts. But Netflix has fantastic monitoring practices
* Challenge - in a micro-services environment, how do you catch issues before production if all tests were fine for individual environments?
* Heavy Monitoring
* Learning the process for a year before automating it was helpful (some automations are not needed)
* Disney provides client libraries. Versioning - providing min and max. Netflix - started with that, had to stop cause there was too many different libraries.
* Sometimes new practices require change in culture.
* Deploying across different geographic zones has to be staggered - deploy to EU, wait for 6 hours, confirm it works, deploy to next region

CITCONNA2023Sessions

2023-02-04T19:26:45Z

Yuliya:

10am

# [[Beyond XP]] (Story of Pivotal Cloud Foundry post VMware acquisition)
# [[Impact Driven Testing and Gap Analysis]]

11am

# [[Testing Microservices]] (Queen's gambit)

CITCONNA2023Sessions

2023-02-04T19:26:35Z

Yuliya:

10am

# [[Beyond XP]] (Story of Pivotal Cloud Foundry post VMware acquisition)
# [[Impact Driven Testing and Gap Analysis]]

11am

# [[Testing Microservices (Queen's gambit)]]

Testing Microservices

2023-02-04T19:25:33Z

Yuliya:

Testing Microservices

2023-02-04T19:22:47Z

Yuliya: Created page with "Tools - - Splunk stack and hashi wrapper for monitoring - NOC (Network Ops Center) -"

Tools
-
- Splunk stack and hashi wrapper for monitoring
- NOC (Network Ops Center) -

CITCONNA2023Sessions

2023-02-04T19:20:55Z

Yuliya:

10am

# [[Beyond XP]] (Story of Pivotal Cloud Foundry post VMware acquisition)
# [[Impact Driven Testing and Gap Analysis]]

11am

# [[Testing Microservices]]

CITCONNA2023Sessions

2023-02-04T19:20:44Z

Yuliya:

10am

# [[Beyond XP]] (Story of Pivotal Cloud Foundry post VMware acquisition)

# [[Impact Driven Testing and Gap Analysis]]

11am

# [[Testing Microservices]]

CITCONNA2023Sessions

2023-02-04T19:20:30Z

Yuliya:

10am

1. [[Beyond XP]] (Story of Pivotal Cloud Foundry post VMware acquisition)

2. [[Impact Driven Testing and Gap Analysis]]

11am

# [[Testing Microservices]]

Beyond XP

2023-02-04T18:56:56Z

Yuliya:

"Post-XP something" (will be replaced by the real name)

'''Attendees'''
- Jesse, Jeffrey, Nat, Yuliya, Andreas

'''Discussion'''

This was a discussion about how Cloud Foundry practices changed since VMware acquisition and pandemic
What happened?
# Moved product managers and designers away (engineers could take over the backlog, but what about talking with customers?)
# Changed what managers did (80% sw development -> full time manager)
# Not using any co-location enabled practices (eg. breakfast, synchronization)
# Emotional anguish of losing something special

And maybe pivotal wasn't perfectly solving some things in the first place. Eg. Pivotal PMs operating on tactical levels were operating more as business analysts, and couldn't focus on product vision and strategic work.

----

Post acquisition,
# the team was 16 people.
# Decision to stop looking at pivotal tracker, because pivotal tracker assumed pivotal process and we couldn't do that with the new team. The team switched to basecamp
# The team decided to try "Shape up" methodology for 6 months. 6 week iterations with "bets" (shaped solutions for chunky problems) + 2 week off for adjusting, evaluating, planning. It was very successful for prioritizing and getting done work of the "Shapeup" size
# It became much easier to advocate for your career advancement cause collective effort and accomplishment transitioned to personal accomplishment. Which freed up a lot of management time, however it also meant that a lot of "non-glamorous work" wasn't getting done
# Added a notion of "home team", everyone defaults to it. However, when there's a "pitch" to be worked on - 3-4 people become a "crew", and step away from the home team for 6 weeks.
# There's also a concept of "tribute" - people volunteering to fill in roles that were missing
# After a year with the "home team", the moved away from leadership writing pitches and leadership making allocation decisions to people starting to do writing "pitches" and doing self-allocation to different "bets"
# Once the team was smaller, and working on specific problems, the team ended up going back to Pivotal Tracker sometime, and after a break it was actually easier to use it again and for a new problem the team was trying to solve

CITCONNA2023Sessions

2023-02-04T18:51:39Z

Yuliya:

10am

1. [[Beyond XP]] (Story of Pivotal Cloud Foundry post VMware acquisition)

2. [[Impact Driven Testing and Gap Analysis]]

11am

Beyond XP

2023-02-04T18:47:49Z

Yuliya:

"Post-XP something" (will be replaced by the real name)

'''Attendees'''
- Jesse, Jeffrey, Nat, Yuliya, Andreas

'''Discussion'''

This was a discussion about how Cloud Foundry practices changed since VMware acquisition and pandemic
What happened?
# Moved product managers and designers away (engineers could take over the backlog, but what about talking with customers?)
# Changed what managers did (80% sw development -> full time manager)
# Not using any co-location enabled practices (eg. breakfast, synchronization)
# Emotional anguish of losing something special

And maybe pivotal wasn't perfectly solving some things in the first place. Eg. Pivotal PMs operating on tactical levels were operating more as business analysts, and couldn't focus on product vision and strategic work.

----

Post acquisition,
# the team was 16 people.
# Decision to stop looking at pivotal tracker, because pivotal tracker assumed pivotal process and we couldn't do that with the new team. The team switched to basecamp
# The team decided to try "Shape up" methodology for 6 months. 6 week iterations with "bets" (shaped solutions for chunky problems) + 2 week off for adjusting, evaluating, planning. It was very successful for prioritizing and getting done work of the "Shapeup" size
# It became much easier to advocate for your career advancement cause collective effort and accomplishment transitioned to personal accomplishment. Which freed up a lot of management time, however it also meant that a lot of "non-glamorous work" wasn't getting done
# The team ended up going back to Pivotal Tracker sometime later in order to solve new problems, and after a break it was actually easier to use it again and for a new problem the team was trying to solve

Beyond XP

2023-02-04T18:38:21Z

Yuliya:

"Post-XP something" (will be replaced by the real name)

'''Attendees'''
- Jesse, Jeffrey, Nat, Yuliya

'''Discussion'''

Discussed how Cloud Foundry practices changed since VMware acquisition and pandemic

1. Moved product managers and designers away (engineers could take over the backlog, but what about talking with customers?)
2. Changed what managers did (80% sw development -> full time manager)
3. Not using any co-location enabled practices (eg. breakfast, synchronization)

Alternative approach
1. Empower engineers to groom and own the backlog

Different teams have different problems: sometimes when the question is "who's gonna groom the backlog" people answer "not me", and sometimes there's 2 engineers and 5 people who are trying to tell them what to do, and solutions will be different

Pivotal PMs operating on tactical levels were operating more as business analysts, and couldn't focus on product vision and strategic work.

Post acquisition, the team was 16 people. Decision to stop looking at pivotal tracker, because pivotal tracker assumed pivotal process and we couldn't do that with the new team. Plus there was a lot of emotional reasons why it was hard to continue trying to do pivotal process despite the acquisition.

Switched to basecamp, 6 week iterations with "bets" (shaped solutions for chunky problems) + 2 week off for adjusting, evaluating, planning. The methodology is called "Shape up". The team decided to try this methodology for 6 months.

Beyond XP

2023-02-04T18:22:44Z

Yuliya:

"Post-XP something" (will be replaced by the real name)

'''Attendees'''
- Jesse, Jeffrey, Nat, Yuliya

'''Discussion'''

Discussed how Cloud Foundry practices changed since VMware acquisition and pandemic

1. Moved product managers and designers away
2. Changed what managers did (80% sw development -> full time manager)
3. Not using any co-location enabled practices (eg. breakfast, synchronization)

Alternative approach
1. Empower engineers to groom and own the backlog

Different teams have different problems: sometimes when the question is "who's gonna groom the backlog" people answer "not me", and sometimes there's 2 engineers and 5 people who are trying to tell them what to do, and solutions will be different

Pivotal PMs operating on tactical levels were operating more as business analysts, and couldn't focus on product vision and strategic work.

Beyond XP

2023-02-04T18:22:03Z

Yuliya: Created page with ""Post-XP something" (will be replaced by the real name) Attendees - Jesse, Jeffrey, Nat, Yuliya Discussion - Discussed how Cloud Foundry practices changed since VMware acqui..."

"Post-XP something" (will be replaced by the real name)

Attendees
- Jesse, Jeffrey, Nat, Yuliya

Discussion
- Discussed how Cloud Foundry practices changed since VMware acquisition and pandemic
1. Moved product managers and designers away
2. Changed what managers did (80% sw development -> full time manager)
3. Not using any co-location enabled practices (eg. breakfast, synchronization)

Alternative approach
1. Empower engineers to groom and own the backlog

Different teams have different problems: sometimes when the question is "who's gonna groom the backlog" people answer "not me", and sometimes there's 2 engineers and 5 people who are trying to tell them what to do, and solutions will be different

Pivotal PMs operating on tactical levels were operating more as business analysts, and couldn't focus on product vision and strategic work.

CITCONNA2023Sessions

2023-02-04T18:11:27Z

Yuliya:

10am
- [[Beyond XP]]
-

11am

CITCONNA2023Sessions

2023-02-04T18:10:47Z

Yuliya: Created page with "10am - Beyond XP - 11am"

10am
- Beyond XP
-

11am