Productside Webinar
How Teams and Leaders Can Unleash the Power of Agile
Date:
Time EST:
According to the Agile Alliance, “Agile is the ability to create and respond to change. It is a way of dealing with, and ultimately succeeding in, an uncertain and turbulent environment.”
But business leaders set rules and processes that inhibit a company’s ability to adapt to change. Agile practices help teams deliver better products more effectively, but there’s often a mishmash of practices at play. What’s more, teams are seldom aligned about what they mean when they use the word “Agile.”
When software VP of Engineering consultant Ron Lichty queries developers about their experience with Agile methodologies, they often tell him not that they’re doing Agile but working at a company that claims to be Agile. According to Ron, the term “Agil-ish” comes up frequently.
Similarly, when product management consultant Tom Evans speaks with Product Managers about Agile, they often say that their development teams are doing Agile, but their business isn’t Agile – and the discrepancy diminishes the benefits of Agile product development.
There is tremendous value to be gained from being truly Agile. During our upcoming webinar, Ron and Tom will explore what being truly “Agile” looks like, for your product development as well as your business teams. They’ll cover what’s in it for products, customers, and your organization as a whole, and what we as leaders can do to achieve the best outcomes from our teams.
Key Takeaways:
- Why Agile and not “Agil-ish” — and why you should care
- How leaders inadvertently sabotage the productivity and effectiveness of their teams
- How leaders can instead, support their teams to achieve the best business outcomes
Welcome & Introductions
Tom Evans | 00:00:00–00:01:44
hello everyone welcome and good morning good afternoon or good evening depending upon which part of the world you are in uh thank you so much for joining us today today we are discussing how teams and leaders can unleash the power of agile
my name is tom evans and i’m a principal consultant and trainer at Productside i have been with Productside for just over 11 years and have had an opportunity over that time period to interact with organizations uh from across many different industries that are looking at implementing agile practices and one of the things that i’ve seen is one is the benefit of implementing agile within organizations and then the second thing is just seeing the many different challenges that both product development and product management teams are facing as they try to implement uh the agile practices processes and and values within the organization but as i’ve had this opportunity to engage with clients one of the great honors i’ve had is to work with ron lichty so ron and i met about seven years ago when we worked together on a client engagement and i will have to say ron is one of those people that have an amazingly deep understanding of agile and i would and i’m happy to say is many of the things that i now uh apply in agile are things that i learned from ron so i’m excited to introduce ron and ron please tell us a little bit about yourself and what makes you so passionate about this topic
Tom’s Background and Why Agile Matters
Ron Lichty | 00:01:45–00:04:08
thanks tom so on i i began my career probably as many of you did as a programmer i spent seven years as a programmer transitioned into product management actually at apple computer to product manage the tools i’ve been using as a software developer i spent a spent a couple of years doing product management unlike most of you transitioned back into engineering and they made me a manager i’ve been managing software development teams and software development organizations ever since i left apple after a number of years after actually getting to manage the team developing the ui of the macintosh i transitioned into my first director of engineering role uh spent spent a number of years as a director of engineering get promoted to a vp of engineering at charles schwab i was at some startups and some medium-sized companies uh a little bit of a little bit of the few of the companies that i spent time at i ran into agile for the first time in 1999 when i was at charles schwab and the form of extreme programming uh really encountered uh i had heard up and really encountered scrum for the first time in 2002 uh and uh began training teams in uh in agile about 12 years ago and i um my um i the part of the part of managing software development organizations that i really love is making software development calm and uh nine years ago i transitioned to consulting because it lets me work with a whole bunch of companies and let and and help them to make their software development home and uh and so i peer i occasionally peer assured as a vp of engineering an interim vp of engineering i think i i come in and and do some uh some assessments of software development organizations and how we can make them home how we can untangle the nuts in their software development i coach some engineering leaders and i train teams in agile and training executive teams in how to support their product teams in agile i
Introducing Ron Lichty
Ron Lichty | 00:04:10–00:09:00
am in the co-author of two two things that i want to share with you right now one of them is the continuing study of product team performance so we’ve had seven studies over the last decade uh you can you can go to ronlichty.com my website and and there’s a page that you can look at the studies themselves as well as highlights of the studies that uh have been pretty insightful into the value of agile among other things but also the value of good product management uh and i’m also the co-author my fifth book is uh managing the unmanageable rules tools and insights from managing software people and teams and uh this is the second edition we in the second edition we added the an entire chapter on the effect of agile on managers uh one of the one of the delights of working with tom is that both of us have a very strong belief that product managers and engineering managers need to be basically joint to hip we need to be working together we need to be collaborative with each other it is the core relationship for um for both of us
Housekeeping, Webinar Overview & Productside Mission
Tom Evans | 00:09:00–00:12:09
all right thank you very much ron and glad that you’re here with us today now let’s go over a few housekeeping items items for this webinar after this webinar continue to stay engaged with the product management community being in an online community can help you feel connected so join your peers by joining our linkedin leadership group use it as a forum to chat about best practices and tips we’ll paste the url into the chat box shortly which has been done thank you at the Productside uh next like please at the Productside we love interacting with you during this webinar we encourage you to ask questions you can use the q a box on the right of your screen to type in questions at any time we will leave time for q a at the end of this webinar our most popular question is can i watch this webinar later and the answer is yes all attendees will receive a link to view the webinar recording after it has ended i should i should uh add tom that there’s gonna be a huge temptation that all of us have to type your questions into chat but there’s a q a box that uh that will uh you’re probably gonna chat with each other and uh and it will pop them out so that we can so that so that we can get fed them yep yeah now and i if you make that mistake of looking at the chat put it in the chat instead of q a we’re monitoring both of those and so we will uh keep track of that uh and make sure that those questions are addressed before we begin i will take a uh first take a minute and introduce you to what the Productside uh does at Productside our mission is to empower product professionals with the knowledge and tools to build products that products that matter unlike other companies we’re focused on just the needs of product professionals whether you need help as an individual growing your knowledge and skills or you are working on improving your team’s effectiveness we have the experience and services you need check us out at Productside.com
Doing Agile vs. Being Agile
Ron Lichty | 00:12:10–00:15:59
and so with that now it’s time to move on into the webinar so ron i’m going to let you uh take the lead here in uh guiding that discussion and as you go through the slides i will engage with you and uh ask some questions and i’ll also be watching the uh the q a just to see whether there are some questions that we want to bring up and address at the moment that we’re on this slide so ron please go ahead and uh kick us off terrific so uh we want to start with talking about doing agile versus being agile then we’re going to talk about why we’re agilish what’s why we’re agilish what gets in the way us the symptoms of that that you can see in your own organizations to uh to determine whether you think you are agile or not and uh how to become truly agile uh and uh and i’m gonna start with this notion that being agilish just won’t cut it anymore so i come into software development organizations all the time where people tell me yeah we’re agilish we’re um we frankenstein together an agile process uh we uh we do scrum butt uh we um uh i get all i get all kinds of uh of stories about it but there’s a lot of unbeing agile so we want to start with a poll how can you bring up the poll so you think your team your organization your company lies in terms of being agile you think you’re fully agile or not agile at all or somewhere in between
Agile Values, Principles & Misunderstandings
Tom Evans & Ron Lichty | 00:16:00–00:21:19
all right and as you’re working on that uh ron i’m just curious have you found uh seen an organization that you would consider uh a hundred percent agile i’m not sure that i have so i’ll be curious and whether you have seen one that might qualify under that you know it’s it’s a it’s an interesting question tom because i think agile is a journey not a destination and even the most agile teams and organizations keep learning …
History, Culture, and Command-and-Control Barriers
Ron Lichty | 00:21:20–00:22:55
so first i think is misunderstandings i i think there’s uh a misunderstanding just the practices alone tom the misunderstanding of stat of stand-ups i see stand-ups degrade devolve into being being status meetings where people are just reporting status where where the intention uh in xp of stand-ups in scrum of the daily scrum was uh uh you know software development’s a team sport we need to talk to each other at least once a day
Ron Lichty | 00:22:55–00:24:02
it’s intended to be a re-planning meeting
Ron Lichty | 00:24:02–00:24:52
i think lack of role models is a really significant one and uh you know we’re we’re in a transition from uh from waterfall from from what came before agile to agile and and we are uh you know the critical mass in agile is is now we the the previous generation of role models the ones that were our managers when we were kids when we were individual contributors when we were first-time managers um they some of them were really good and and uh you know the the ideas behind agile have been around for a long time and some of them really embraced those but what many more of them well the next bullet here is history and and the history dates to the industrial revolution we have we have uh decades and decades of uh getting it wrong well decades and decades of industrial telling people what to do their cogs in the wheel as opposed to bringing everyone and bringing everyone’s wisdom and and and embracing collaboration
Tom Evans | 00:24:52–00:25:40
yeah you know and along that line i think that history definitely uh does stand out because if you look at the early discussions around management you know uh dating back into the late 1800s and where it became a science you know it was a very top-down approach in terms of how you organize how you manage how you control and i was just reading a a quote here recently from mckinsey and this is the mckinsey founder uh where he talks about all organizations must implement a budget as a way to control you know to be able to have control of what’s going on in the organization so i think there there’s a there’s a long history in there of that command to control perspective uh that can get in the way of being that making organizations agile
Symptoms of “Agilish” Teams
Ron Lichty | 00:25:40–00:27:50
now the sad thing is that there’s also history of proposing change so we we in our in our book we realized that we needed to talk about three thought leaders in management and uh and then motivate and motivating teams and organizations uh one of those being maslow who everyone recognized but another one being douglas mcgregor who is the guy who came up with x theory y theory management who in the 1950s pointed out that pretty much all of what we had in management is what we’ve just been talking about telling people what to do directing directing authoritarian command and control kind of management and that what we needed going forth this is the 1950s what we needed going forth for thought workers for who we are what we do thought workers was theory y management where managers the point of managers is to support their organizations is to uh is to create the environment in which teams thrive
Ron Lichty | 00:27:50–00:29:55
so let me move on to the next one which is culture uh you know the many of us are working inside of organizations that the culture uh we have we have to change mindset uh of ourselves and our teams and uh and our organizations and that can be a tough one and then and then mindset so culture and mindset pretty much go together so uh why do we do agile and not be agile uh you know i think there’s probably a ton more reasons than this but but these are five really significant ones yeah and and going back to where i you know mentioned here is that idea of command and control you know and i feel like uh organization their organizations you know as they’re focusing on pri on the uh practices and the processes as you talk about there still is often a command to control perspective in the organization of where uh you know if you want to change anything you still need to come back up through us go through that budgeting cycle and be able to get approval to uh to make a change and really agile is about being able to respond to change
Tom Evans | 00:29:55–00:34:29
and you know you and i you know talked about this term you know vuca but you know which nobody can remember off what it means but you know the the volatility you know the ambiguity that we uh deal with the change that is going on the uncertainty yeah uncertainty you know uh you know we we typically go into a world you know as we go through our planning cycles we feel like we know exactly how everything is going to look out in front of us but and you know from a software development perspective we used to plan projects for a year and a half as if we knew exactly how those were going to execute but you know we’ve we tried to apply these practices in software development and and we did have a question come up also about you know applying agile practices and hardware development and i do want to say that you know organizations are also thinking about uh are doing that in the the hardware world we’ll talk a little bit more about that but they still run into this problem of we’re doing these practices but we can’t respond to change and i was just i was just on a call uh here about an hour ago where i was talking to somebody and he says we get our annual budget planned and you know we’re expected to execute against that uh project and if any change comes along we have to go back through that whole uh cycle you know to uh get a change and and one of the things that stands out to me when i think about responding to this change is how fast can you make decisions and and if i remember right i think it was uh jj sutherland jeff sutherland’s son wrote a book on the scrum field guide and i believe if if i’m remembering correctly he talks about how when you look at projects and project success that one of the indicators of project success is decision making and how quickly can you have a decision made and those that take a lot longer to have decisions made like turn it into weeks sometimes or even months those are the projects that fail where those that have uh you know pushed that authority down to the right level that’s where uh those projects tend to be a lot more successful
Poll Discussion: Where Teams Struggle
Ron Lichty | 00:34:30–00:38:00
yep so we’re we’re precursoring the uh i know i’m jumping ahead to some things there some symptoms of agilish so uh so let’s talk about some some more symptoms of agilish uh one one of them and we precursed this one uh standups standups turned into really just status meetings and and i see them evolve even further into well let’s just use a slack bot and uh and do our and do our stand-ups that way stand-ups are intended to be replanting meetings there they are intended to be a time when the team comes together and says are we on track for what we intended to get done and and how do we need to adjust if we’re not …
Becoming Truly Agile: Six Core Shifts
Ron Lichty | 00:38:00–00:42:39
so we’re going to talk about how to become truly agile and we’re going to jump into six different uh six different areas the first of the first being working on products not projects having stable teams to which we bring product development as opposed to pulling together random i’m going to call them random it’s not it’s usually not randomly organized but pulling together teams in order to solve a project you want to say more about that tom yeah you know i agree with you i i worked with an organization about uh four years ago …
Products vs. Projects & Stable Teams
Tom Evans & Ron Lichty | 00:42:40–00:45:49
and one of the things that they had been doing is moving project teams around between different uh projects you know keep maybe keeping the project team together and in other cases they just reorganize completely every time there is new projects and that made it really complicated you know both uh from from a product management perspective …
Outcomes over Output
Ron Lichty | 00:45:50–00:48:44
so then outcomes driven not output driven so we’ve got this we’ve got this uh this challenge that comes out of manufacturing i think of how many piece parts did you make today and and so you know i’m old enough i was around for the uh well let’s count the number of lines of code that you generated it’s like no no we want fewer lines of code not more lines of code we want more delighted customers …
Psychological Safety as the Core of High Performance
Ron Lichty | 00:48:45–00:52:19
respect and trust and psychological safety we’ve we’ve talked throughout this uh this webinar about respect and trust and psychological safety the um the uh the thing we haven’t mentioned is google’s study the aristotle study that that um where they looked for where why google just like everybody else has high performance teams and low performance teams unlike everybody else they have a ton of money and so they they set up a study to study their own people …
Customer Collaboration & Continuous Learning
Tom Evans | 00:52:20–00:53:40
you know and one of the things that i emphasize around that is too often we’re waiting until the product is almost completely ready or ready before we start getting those feedback cycles and you know this applies whether i’m talking software or whether i’m talking a manufacturer good i should find times in that early uh you know even maybe pre-design but definitely in the design process to get go out and get that customer feedback so i can respond then before something is all set in stone versus waiting until the very end to uh where all of a sudden it’s like oh no that’s gonna cost us six months or a year to be able to go and uh adapt and change to meet the customer uh expectation
Ron Lichty | 00:53:40–00:54:30
it’s why in pre-pandemic times we we we had product managers or product owners and designers sitting next to developers so that developers could nudge and say is this what is this what’s going to delight our customers is this you know we we absolutely count on product managers to bring the customer into the room but if product managers aren’t in the same room i had a challenging uh company i was working with a few years ago that very very agile i put them in the 80 but they were they were wondering why that they were getting designs from designers that were that took so long to while the designers were sitting in a different room
Ron Lichty | 00:54:30–00:55:20
so we have to figure out in post-pandemic times uh how to how to how to make that communication work how to make that collaboration work and and use the agile manifesto as a window and and i tell every team i train to do this i tell every executive team that the agile manifesto is it is a window that we can look at our practices our practices aren’t set in stone we aren’t going to be practicing zombies or process zombies as yours as you’re saying tom we’re we’re actually looking at are these serving our values and principles
Q&A: Agile in Hardware, Offshore Teams, and Team Size
Tom Evans | 00:56:10–00:56:40
all right do you want to say something more about this slide you know i i know i don’t think so i think i think you know the key message here is that and i think it goes back to the point that you made earlier is that being agile is a journey and you’re not going to go from we’re not you know we’re not agile to agile it’s it’s really a journey journey it’s it’s discovery it’s it’s finding new ways and i think in the agile manifesto they talk about we’re finding new ways to do things better and so don’t feel like you’re gonna you know get there overnight but look at it as a journey and and having that willingness to experiment uh to try new things
Ron Lichty | 00:56:40–00:58:05
great and that brings us to q a yeah let’s go ahead and uh do q a and uh i want to touch one question that came up really early and this was from frank and he was saying you know it sounded like we were talking a lot around uh software where you know he was interested in terms of uh phys you know physical or manufacture type goods and and i know as i’ve had the chance to engage with uh several companies that are starting to look at how do we implement some of these agile practices in a more hardware uh driven type world and i i just wondered whether in your research you you’ve been able to at least observe or see any companies that do manufactured goods that have implemented uh agile practices
Ron Lichty | 00:58:05–00:59:15
yeah so that uh actually what i’ve looked at is is not manufacturing itself manufacturing itself right right the product development side of manufacturing yeah it relies on the toyota process yes it’s sort of where where agile came from was from uh uh it was from agile being used in manufacturing it was from from toyota and the toyota way in terms of designing hardware in terms of developing hardware agile and and i’ll say specifically scrum is being used in uh in hardware …
Tom Evans | 00:59:15–01:00:20
but but yeah along that point is uh you know exactly they’re they’re they’re using sprints you know they’re creating backlogs but it’s not a requirement backlog as much as maybe a task backlog and and they’re doing uh daily scrums you know they’re creating that sense of urgency accountability they’re bringing in you know the collaborative uh aspects of uh scrum and uh just has another reference and i mentioned both jeff sutherland and jj sutherland uh you know do uh reach out and check out their books …
Tom Evans | 01:00:20–01:00:50
do we have another question yes we do uh let’s see uh one from michael and this has to do with the daily stand-ups themselves where they’re working with an offshore uh team and uh they’re only including the senior engineer and so they they feel like by not including the offshore engineers in the scrum that it really turns into a status meeting and do you have any uh thoughts or recommendations in terms of working with offshore teams and making scrums work successfully
Ron Lichty | 01:00:50–01:02:00
yeah i um i was working with a company uh actually early in my consulting practice i was working with a company that was offshoring so it was offshoring to colombia to medellin and uh medellin colombia and and a little bit smoketop but mostly to medellin and the offshoring company said great we will we will take on this project here’s the deal we we’re going to we’re going to supply and you’re going to pay us for it we’re going to supply us from master and we’re going to prove and we’re going to supply a product owner and that product owner is is we don’t expect the the product owner to understand every we expect them to to basically have a bulk and mind meld with your product manager …
Ron Lichty | 01:02:00–01:02:48
yeah and and you know even though uh and again you know when you think about the offshore teams you know there’s the practice of having a local scrum also and so not necessarily saying i have to have a scrum that includes everyone around the world but we can still do a uh a scrum from a uh at a local basis too
Tom Evans | 01:02:48–01:03:30
yeah and so going to that my my goal as an engineering leader is to divide up the work so that i’ve got i’ve got um in the post-pandemic times teams with the same time zones teams that are in the same time zones that that can collaborate with each other over the same core working hours and so i don’t want to cross people in india singapore china with people in the united states with uh people in eastern europe i want to create teams in each of those places that that are cross-functional teams that each can deliver value to customers on their own well and they have all the resources they need to do that
Tom Evans | 01:03:30–01:04:15
okay let’s look at a uh another question here and this actually is uh there’s a little bit of commonality here but uh someone is talking about in a smaller organization in environment where they aren’t necessarily able to get dedicated teams because they just don’t have the resources to do that any any thoughts on that in terms of how do you best manage that situation uh when you’re in a smaller team environment a smaller organization trying to you know keep teams together
Ron Lichty | 01:04:15–01:05:00
so so i’m not i’m not understanding the question yeah just like let me go and uh re-look at the question yeah it says with regards to products not projects what would you recommend for smaller companies that do not have the personnel to have separate teams organized around products so if we’ve got one if we’ve got one team and they have to handle everything they have to support multiple products and then we’ve got then we’ve got a team that actually is stable and holds together and um and maybe has the motivation around delighting customers from this one and this one and this one and now it’s a matter for product management just simply to tell us what’s the story with the most value …
Ron Lichty | 01:05:00–01:05:45
i’ve been uh i’ve been part of the the transformation of uh our our business unit has this is our developer seven business units seven our developers to a team of seven that supported all of those teams now there’s a couple of things that a couple of a couple of things that are a problem with our developer one our developer doesn’t doesn’t know and doesn’t have anywhere near the sphere of knowledge that all seven of them together have …
Final Thoughts, Resources & Closing Remarks
Tom Evans | 01:06:40–01:07:30
all right well ron there there are a number of other questions and and apologize that we couldn’t get to all of them and there was one question on budgeting but what what we’ll do is for those that we didn’t get to your question we will be looking at those and creating answers putting those together in the uh blog post and so but we do need to wrap up and uh real quick uh ron is offering a special discount yeah so if any of you think that you might want the the book the fifth book i wrote or the video training behind it take a snapshot of this discount code so that you don’t pay full price
Tom Evans | 01:07:30–01:08:10
right and we’ll be handling sending out that information in uh follow-up email also and then finally uh if you are interested in getting your team signed up for our agile product management self-study course please visit our website and if you’re interested in customizing the agile course please contact us we want to thank everyone who was in the webinar today listening to it we thank you for the conversation that was going on and for the questions and we look forward to engaging with you in the future so thank you again for everyone and uh have a great day
Ron Lichty | 01:08:10–01:08:28
and thank you ron hey our tom has been a delight collaborating with you on this absolutely thank you
Webinar Panelists
Tom Evans