This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
I was wondering how much of the 3 horizons in TUP was inspired by Zones to Win from Geoffrey Moore? I love the simplicity of Moore’s thinking and it puts it very simply to a CEO /CIO. However I think that the trick is to flow naturally from incubation to performance zone and the transformation zone should just be about on-going adaptability. This is well featured in TUP when they do the innovation incubators. In my view the key job is not to manage a transformation at a time but flow transformation and in fact transform the “productivity” zone that is placing the wrong constraints on the organisation preventing it to change. Thoughts?
I was wondering how much of the 3 horizons in TUP was inspired by Zones to Win from Geoffrey Moore? I love the simplicity of Moore’s thinking and it puts it very simply to a CEO /CIO. However I think that the trick is to flow naturally from incubation to performance zone and the transformation zone should just be about on-going adaptability. This is well featured in TUP when they do the innovation incubators. In my view the key job is not to manage a transformation at a time but flow transformation and in fact transform the “productivity” zone that is placing the wrong constraints on the organisation preventing it to change. Thoughts?
+1!! …and here’s a special sneak peek into the future; I’ll be doing introducing you all to the work of Peter Moore, brother of Dr. Geoffrey Moore — he’s a super interesting person who has done a ton of work in the Zone to Win space, and I’ve learned a ton from him. Catch you soon!
I discovered recently that the References section at the end of the book is broken down by chapter (mostly). Gene has listed the books, articles, YouTube videos, etc. that inspired the book. It might be useful to review this material while discussing each section so we are better informed about what the prose is trying to convey.
I discovered recently that the References section at the end of the book is broken down by chapter (mostly). Gene has listed the books, articles, YouTube videos, etc. that inspired the book. It might be useful to review this material while discussing each section so we are better informed about what the prose is trying to convey.
Happy New Year, everyone! Excited that the book club for The Unicorn Project is kicking off this week, with the AMA call in two days! Thank you for all your interest and enthusiasm and everything you’ve taught me!!! And catch y’all soon!
<!here> Hi everyone and welcome to the IT Revolution Book Club! We’re very pleased to have you and look forward to many great discussions around The Unicorn Project. This week will feature discussion questions from Part I, and the first question for today will be posted shortly!
<!here> Hi everyone and welcome to the IT Revolution Book Club! We’re very pleased to have you and look forward to many great discussions around The Unicorn Project. This week will feature discussion questions from Part I, and the first question for today will be posted shortly!
Lack of documentation and ability to quickly setup an environment and start developing.
Also, there are some wonderful discussions started in previous posts here in this channel. Please scroll up and comment on those if you have someone to add 🙂
There are too many points/people to go through to get something done. It should be simple, but Maxine has to jump through hoops to get something done (like setting up a Dev Environment).
Tickets. I have to go thru an average of 10 tickets to deploy an update. Changes with infrastructure take even more, so every one avoids it. the result is the inevitable clumping of changes together.
I loved the point where she met a developer who was blissfully unaware of how their code was creating value - headphones on continuing to code as things were falling apart around him. To me, that's an issue of unused inventory in code :-)
I loved the point where she met a developer who was blissfully unaware of how their code was creating value - headphones on continuing to code as things were falling apart around him. To me, that's an issue of unused inventory in code :-)
I can feel the lack of self-service. Whether it because of “security” or fief-doms. I hear a lot about security audits saying you can’t self-service. But in my experience if you have good auditing, tracing and controls, then self-service has never been an issue with auditors.
It is also a lack of a good definition of ‘done’ MVP can be a drift into failure because you might never get back to fix any tech debt issues.
Deployment pain, old source code, unnecessary different login systems in servers that maybe she need to access to get her work done.
And not having good feedback loops to actually fix the issues, leads to rebellion. 🙂 or people just give up and/or leave
On a project I'm helping with we've been waiting for a database to be set up for 4 months! Recent report said on average it was taking teams 28 weeks to stand up PCF! So I feel Maxine's pain.
On a project I'm helping with we've been waiting for a database to be set up for 4 months! Recent report said on average it was taking teams 28 weeks to stand up PCF! So I feel Maxine's pain.
I have two teams, at different levels of transformation based on the TPP, I have one team that is all old school OPS networking and now they are looking at everything as code, and using Maxine as an example of moving from traditional IT to developer mindset will be great. The other team is just now starting the DevOps journey. So they are following the TPP more, however, I love the fact that getting core ops as a condition of making life better for all is key to helping developers... I tend to relate to Kurt more in my role, but we definitely have a rebellion team forming.
One case in the book that is a drift into failure is when 3 different network switches, managed by 3 different teams were merged into 1. That created conflict between the teams and co-ordinating changes, etc. It was mentioned that by being separate the teams could move at their own pace. Yet that creates 3 places to request work/access. The book doesn’t really reconcile that. What are people thoughts on that? I think ideally with automation, tests and self-service, it should not matter
One case in the book that is a drift into failure is when 3 different network switches, managed by 3 different teams were merged into 1. That created conflict between the teams and co-ordinating changes, etc. It was mentioned that by being separate the teams could move at their own pace. Yet that creates 3 places to request work/access. The book doesn’t really reconcile that. What are people thoughts on that? I think ideally with automation, tests and self-service, it should not matter
Lots of developers off on their own branches doing their own thing for a long time which leads to one huge (and hugely painful and time consuming) big bang of a merge marathon… rather than continuously integrating small chunks of code with one another all the time.
I also see the different approval bodies made of up committees and even when Senior Individuals (removed from the actual work) are required to change approvals as a Drift into Failure... How can you fail fast if you have to have wait for an approval board that will not approve any changes if they think it will fail or is "too" risky?
Lack of appreciation for developers themselves as users of a service, and lack of thought/attention put into making sure the developer experience is a positive one
Lack of appreciation for developers themselves as users of a service, and lack of thought/attention put into making sure the developer experience is a positive one
Lots of issues for the developers and all the feedback so far is correct. I will add another one. I felt like Maxine and other developers had a fear of doing something wrong. If something goes bad, they could get fired. The emails told part of the story. The processes and approvals showed the IT org wanted to reduce risk to the point nothing was moving forward.
Lots of issues for the developers and all the feedback so far is correct. I will add another one. I felt like Maxine and other developers had a fear of doing something wrong. If something goes bad, they could get fired. The emails told part of the story. The processes and approvals showed the IT org wanted to reduce risk to the point nothing was moving forward.
To restate the original question... “What are some key issues for developers that Maxine uncovers?” Looking back at my highlights, here are the biggies I noticed: • punishing failure, resulting in a culture of fear and a desire to innovate and improve being hampered • glorification of long hours and hero culture • elevation of features in terms of perceived importance above productivity and improvement items (eg, build process, paying down tech debt, etc) • systems that are so ‘complected’ that it was very difficult for developers to make small and safe changes without far reaching (and likely undesirable) impacts. lack of ‘locality’ in the code factors in here too.
To restate the original question... “What are some key issues for developers that Maxine uncovers?” Looking back at my highlights, here are the biggies I noticed: • punishing failure, resulting in a culture of fear and a desire to innovate and improve being hampered • glorification of long hours and hero culture • elevation of features in terms of perceived importance above productivity and improvement items (eg, build process, paying down tech debt, etc) • systems that are so ‘complected’ that it was very difficult for developers to make small and safe changes without far reaching (and likely undesirable) impacts. lack of ‘locality’ in the code factors in here too.
@bwnoll great summary of the key issues for the dev teams in part 1! I would add: • Lack of common process (build/deploy/test) and process documentation. • Lack of centralized code repository & build framework • Lack of automated tests and/or CI framework • Siloed teams (they are already hinting at the value of fully cross-functional teams with the Rebel Alliance) • Generally no understanding between individuals and teams as to what everyone else is doing and how it is all going to work together • No “Product Owner” or clearly communicated acceptance criteria so everyone truly understands what “done” looks like
@bwnoll great summary of the key issues for the dev teams in part 1! I would add: • Lack of common process (build/deploy/test) and process documentation. • Lack of centralized code repository & build framework • Lack of automated tests and/or CI framework • Siloed teams (they are already hinting at the value of fully cross-functional teams with the Rebel Alliance) • Generally no understanding between individuals and teams as to what everyone else is doing and how it is all going to work together • No “Product Owner” or clearly communicated acceptance criteria so everyone truly understands what “done” looks like
None of the Development systems are connected, ie work cannot flow without entering another system, multiple licenses needed etc. Different systems that is not integrated creates more silo behavior
Different source code repos with different owners, multiple tech stacks that seem to have spawned from god knows where over time. No CI/CD Pipeline thought at all?!
I think that all the issues could be summed up with "but we always did it that way" culture.
I think that all the issues could be summed up with "but we always did it that way" culture.
Might just be semantics but nearly all these issues seem to apply to everyone in the org and not just "developers"
Might just be semantics but nearly all these issues seem to apply to everyone in the org and not just "developers"
So right, and worth an echo! Failure to apply the 3 Ways, all beginning with the First Way and not looking at the end to end system. As Deming said: >A bad system will beat a good person every time
They are organized in a tayloristic manner. Everyone adds exactly one screw and no one knows how the product looks like. And no one is responsible from end-to-end.
They are organized in a tayloristic manner. Everyone adds exactly one screw and no one knows how the product looks like. And no one is responsible from end-to-end.
Did anyone mention the the Fouth Ideal yet? (Psychological Safety). In my mind it kind of goes along with the ""but we always did it that way" culture @dejan.menges mentioned. People got so used to how things worked that they didn't feel safe enough to bring up how bad things have gotten to make a change. It took a whole Rebellion of brave frustrated people to get the gears going. If employees (not just developers) were able to say something and be heard, maybe things wouldn't have gotten so bad in the first place.
Did anyone mention the the Fouth Ideal yet? (Psychological Safety). In my mind it kind of goes along with the ""but we always did it that way" culture @dejan.menges mentioned. People got so used to how things worked that they didn't feel safe enough to bring up how bad things have gotten to make a change. It took a whole Rebellion of brave frustrated people to get the gears going. If employees (not just developers) were able to say something and be heard, maybe things wouldn't have gotten so bad in the first place.
Not ever having a stabilized consistant environment and the process getting close before trying to launch
Boarding of new developers, poor documentation, feature blinkered resources just so much waste. The fact it took so much effort for Maxine to get up and (partly) running is pretty damning.
Overly bureaucratic / Kafka-esque absurd systems which have evolved to bake in a sense of safety. Usually the initial reason for them long forgotten and that do not aid the overall goal of the organisation.
“Complected” is a great concept - it’s clear that the system that had been built didn’t have any clear, well understood design that everyone could rally around and get aligned on. Always fun when the HR system goes down when your POS system is changed. 🙂 What are some ways you’ve seen to establish and communicate a clear view of complex systems like this?
Extending technical debt to complexity debt is a key takeaway for me. Addressing these legacy technology and procedure challenges holistically, continuously and creatively.
The developers are focused on their work only and don't have a strong understanding of how their work fits within the system in which they are working. The developers have individual goals for their own work, when it would be more effective if they had a common, unified outcome across the organization. This leads to a lot of "not my problem" behavior.
The developers are focused on their work only and don't have a strong understanding of how their work fits within the system in which they are working. The developers have individual goals for their own work, when it would be more effective if they had a common, unified outcome across the organization. This leads to a lot of "not my problem" behavior.
I think one of the biggest impediments to team and business success can be the organization, which should be their key enabler.
Another dysfunctional situation, not having access to the testers, the alarming amount of silo's - lots of communication but no one is really communicating... easy to see why the rebellion started.. there was no other choice..
Another dysfunctional situation, not having access to the testers, the alarming amount of silo's - lots of communication but no one is really communicating... easy to see why the rebellion started.. there was no other choice..
I think the root cause problem was cultural and that can be explained by Patrick Lencioni the five dysfunctions of a team https://i.pinimg.com/originals/88/ff/32/88ff32f09a157c6b66ce7900142eb1fa.jpg. Those dysfunctions that can be map to the Fourth Ideal - Psychological Safety. Off course there were lot of symptoms and undesirable effects (following ToC) including several of those already mentioned. But, once a team - the Rebellion changed the dysfunctions in actual funcional practices the things evolved for good
I think the root cause problem was cultural and that can be explained by Patrick Lencioni the five dysfunctions of a team https://i.pinimg.com/originals/88/ff/32/88ff32f09a157c6b66ce7900142eb1fa.jpg. Those dysfunctions that can be map to the Fourth Ideal - Psychological Safety. Off course there were lot of symptoms and undesirable effects (following ToC) including several of those already mentioned. But, once a team - the Rebellion changed the dysfunctions in actual funcional practices the things evolved for good