My presentation at LAST Conference 2012 in Melbourne: http://www.lastconference.com/
The general idea was to share edgy ideas that the audience hadn't heard of. I started with ideas that everyone should have heard of and then add on next level concepts.
Edgy Agile Things That You May Not Have Heard Of: Melbourne Agile and Scrum m...Jason Yip
Pretty much the opposite of Agile 101. A summary of more edgy and obscure Agile ideas and practices that you may find useful.
This version is was presented at the Melbourne Agile and Scrum meetup
If we are agile, why do we need managers (code camp, 10.14)Ron Lichty
A common misconception about agile is that managers are unnecessary. After all, agile is based on self-organizing teams. If the teams organize themselves, what do managers do?
Unfortunately, most scrum training plays into that. Think about it: how many trainers or coaches have you seen sketch the structure of a scrum team with a drawing that includes a manager? While there's always a scrum master and a product owner, the core team and maybe some stakeholders, have you ever seen a manager in that drawing?
This misconception can be a problem all around: A frequently cited barrier to agile adoption is managers who don't know what to do when their teams become self-managing. When they're not included in training, how would they (or anyone else, for that matter) know how to characterize their role. At the same time, organizations often lay down expectations of managers, some compatible with agile, some not.
Agile has clearly shifted the old roles and responsibilities. Managers bent on command-and-control are clearly a barrier to agile adoption. But managers who take a hands-off approach or are treading water in a sea of ambiguity will almost certainly stymie adoption, as well.
Ron Lichty believes (and so do a lot of the early agile thought leaders) that managers have critical roles to play in enabling success, both of transitions to agile and of agile itself. This session is about those roles.
Think Like an Agilist - Agile Sydney 2014Jason Yip
Culture is not just visible artefacts and behaviour, value statements, and culture books. The foundation of culture is our underlying mental processes, beliefs, and assumptions.
Think Like an Agilist is an exercise using difficult scenarios, and think-aloud protocol, to expose and allow us to examine and practice adjusting our assumptions (aka culture).
Agile Sydney 2014 version.
Lean Software Development: On Radiators and RefrigeratorsJason Yip
My presentation at the first Ignite Sydney. In hindsight I should have titled it: "No Problem is a Problem: Lean Thinking for Managing Software Development"
Becoming an Agile Manager (Agile Camp, 9.21.13), by Ron LichtyRon Lichty
A common misconception about agile is that managers are unnecessary. After all, agile is based on self-organizing teams. If the teams organize themselves, what do managers do?
Unfortunately, most scrum training plays into that. Think about it: how many trainers or coaches have you seen sketch the structure of a scrum team with a drawing that includes a manager? While there's always a scrum master and a product owner, the core team and maybe some stakeholders, have you ever seen a manager in that drawing?
This misconception can be a problem all around: A frequently cited barrier to agile adoption is managers who don't know what to do when their teams become self-managing. When they're not included in training, how would they (or anyone else, for that matter) know how to characterize their role. At the same time, organizations often lay down expectations of managers, some compatible with agile, some not.
Agile has clearly shifted the old roles and responsibilities. Managers bent on command-and-control are clearly a barrier to agile adoption. But managers who take a hands-off approach or are treading water in a sea of ambiguity will almost certainly stymie adoption, as well.
Ron Lichty believes (and so do a lot of leading agile thought leaders) that managers have critical roles to play in enabling success, both of transitions to agile and of agile itself. This session is about those roles.
Transforming chaos to clarity - acm 6.15Ron Lichty
Does your software development feel chaotic?
If you have ever been dissatisfied with your software development flow - if you would like to figure out how to avoid chaos - this is a presentation for you!
Ron Lichty has found himself repeatedly called in as the cavalry to help development groups stuck in confusion. A recognized engineering leader, Ron says, “I've found that I excel at coming in cold, identifying the causes of chaos, untangling organizational knots, creating roadmaps everyone can follow, building communications with other parts of the organization, and getting teams productive and focused on delivery, quality and customers.” He adds, “With a few pointers, any team member can more deeply diagnose their team.”
Ron is author of Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams, which has been compared by reviewers to Fred Brooks’ The Mythical Man Month. After managing software and product organizations for 25 years, Ron has catered his leadership roles to the needs of his clients, including interim VP Engineering and acting CTO roles.
Six years ago, Ron began training teams in agile and a year ago training managers in the nuances of managing software people and teams, whether in waterfall environments, or iterative or agile ones.
If you would like to become an effective agile team member then you'll want to attend this presentation. We’ll look at agile trends, software team pain points, product team solutions, and how every team member contributes to making teams excel.
Drawing from his experience with dozens of product development organizations, Ron will walk through the steps needed to assess your organization’s workings and pull together the elements that will bring order and increased productivity for your business.
Bio:
Ron Lichty has been managing and more recently consulting with software development and product organizations for over 25 years, engaged in untangling the knots in software development and transforming chaos to clarity. Originally a programmer, where he earned several patents and wrote two popular programming books, he was hired into his first management role by Apple Computer, which nurtured his managerial growth in both development and product management.
Principal and owner of Ron Lichty Consulting, Inc. (www.RonLichty.com), he has trained teams in scrum, transitioned teams from waterfall and iterative methodologies to agile, and coached teams using agile, iterative and waterfall approaches alike to make their software development "hum". In his continued search for effective best practices, Ron co-authors the annual Study of Product Team Performance.
Ron's most recent book is Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams - http://www.ManagingTheUnmanageable.net - co-authored with CTO Mickey W. Mantle. Published by Addison Wesley, it has been compared by reviewers to Mythica
Edgy Agile Things That You May Not Have Heard Of: Melbourne Agile and Scrum m...Jason Yip
Pretty much the opposite of Agile 101. A summary of more edgy and obscure Agile ideas and practices that you may find useful.
This version is was presented at the Melbourne Agile and Scrum meetup
If we are agile, why do we need managers (code camp, 10.14)Ron Lichty
A common misconception about agile is that managers are unnecessary. After all, agile is based on self-organizing teams. If the teams organize themselves, what do managers do?
Unfortunately, most scrum training plays into that. Think about it: how many trainers or coaches have you seen sketch the structure of a scrum team with a drawing that includes a manager? While there's always a scrum master and a product owner, the core team and maybe some stakeholders, have you ever seen a manager in that drawing?
This misconception can be a problem all around: A frequently cited barrier to agile adoption is managers who don't know what to do when their teams become self-managing. When they're not included in training, how would they (or anyone else, for that matter) know how to characterize their role. At the same time, organizations often lay down expectations of managers, some compatible with agile, some not.
Agile has clearly shifted the old roles and responsibilities. Managers bent on command-and-control are clearly a barrier to agile adoption. But managers who take a hands-off approach or are treading water in a sea of ambiguity will almost certainly stymie adoption, as well.
Ron Lichty believes (and so do a lot of the early agile thought leaders) that managers have critical roles to play in enabling success, both of transitions to agile and of agile itself. This session is about those roles.
Think Like an Agilist - Agile Sydney 2014Jason Yip
Culture is not just visible artefacts and behaviour, value statements, and culture books. The foundation of culture is our underlying mental processes, beliefs, and assumptions.
Think Like an Agilist is an exercise using difficult scenarios, and think-aloud protocol, to expose and allow us to examine and practice adjusting our assumptions (aka culture).
Agile Sydney 2014 version.
Lean Software Development: On Radiators and RefrigeratorsJason Yip
My presentation at the first Ignite Sydney. In hindsight I should have titled it: "No Problem is a Problem: Lean Thinking for Managing Software Development"
Becoming an Agile Manager (Agile Camp, 9.21.13), by Ron LichtyRon Lichty
A common misconception about agile is that managers are unnecessary. After all, agile is based on self-organizing teams. If the teams organize themselves, what do managers do?
Unfortunately, most scrum training plays into that. Think about it: how many trainers or coaches have you seen sketch the structure of a scrum team with a drawing that includes a manager? While there's always a scrum master and a product owner, the core team and maybe some stakeholders, have you ever seen a manager in that drawing?
This misconception can be a problem all around: A frequently cited barrier to agile adoption is managers who don't know what to do when their teams become self-managing. When they're not included in training, how would they (or anyone else, for that matter) know how to characterize their role. At the same time, organizations often lay down expectations of managers, some compatible with agile, some not.
Agile has clearly shifted the old roles and responsibilities. Managers bent on command-and-control are clearly a barrier to agile adoption. But managers who take a hands-off approach or are treading water in a sea of ambiguity will almost certainly stymie adoption, as well.
Ron Lichty believes (and so do a lot of leading agile thought leaders) that managers have critical roles to play in enabling success, both of transitions to agile and of agile itself. This session is about those roles.
Transforming chaos to clarity - acm 6.15Ron Lichty
Does your software development feel chaotic?
If you have ever been dissatisfied with your software development flow - if you would like to figure out how to avoid chaos - this is a presentation for you!
Ron Lichty has found himself repeatedly called in as the cavalry to help development groups stuck in confusion. A recognized engineering leader, Ron says, “I've found that I excel at coming in cold, identifying the causes of chaos, untangling organizational knots, creating roadmaps everyone can follow, building communications with other parts of the organization, and getting teams productive and focused on delivery, quality and customers.” He adds, “With a few pointers, any team member can more deeply diagnose their team.”
Ron is author of Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams, which has been compared by reviewers to Fred Brooks’ The Mythical Man Month. After managing software and product organizations for 25 years, Ron has catered his leadership roles to the needs of his clients, including interim VP Engineering and acting CTO roles.
Six years ago, Ron began training teams in agile and a year ago training managers in the nuances of managing software people and teams, whether in waterfall environments, or iterative or agile ones.
If you would like to become an effective agile team member then you'll want to attend this presentation. We’ll look at agile trends, software team pain points, product team solutions, and how every team member contributes to making teams excel.
Drawing from his experience with dozens of product development organizations, Ron will walk through the steps needed to assess your organization’s workings and pull together the elements that will bring order and increased productivity for your business.
Bio:
Ron Lichty has been managing and more recently consulting with software development and product organizations for over 25 years, engaged in untangling the knots in software development and transforming chaos to clarity. Originally a programmer, where he earned several patents and wrote two popular programming books, he was hired into his first management role by Apple Computer, which nurtured his managerial growth in both development and product management.
Principal and owner of Ron Lichty Consulting, Inc. (www.RonLichty.com), he has trained teams in scrum, transitioned teams from waterfall and iterative methodologies to agile, and coached teams using agile, iterative and waterfall approaches alike to make their software development "hum". In his continued search for effective best practices, Ron co-authors the annual Study of Product Team Performance.
Ron's most recent book is Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams - http://www.ManagingTheUnmanageable.net - co-authored with CTO Mickey W. Mantle. Published by Addison Wesley, it has been compared by reviewers to Mythica
Crash Course: Managing Software People and Teams (IEEE, 4.4.13)Ron Lichty
"We'd like you to manage the team now." That's about as much introduction - and training - as many of us get before our first day managing. Often preceded only by, "You're a great programmer and you've got some people skills." But while programming cred and facility with people are helpful qualifications, what do you really need to know to manage well? What makes a manager great? What are the qualities that meld teams and deliver great software? Those are among the questions that led Ron Lichty and his co-author Mickey W. Mantle to write "Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams" (Addison-Wesley, September), now available for pre-order online. In this interactive session, we'll examine the great managers each of us has experienced, and the qualities, skills, finesse and gifts of greatness that made them stand out. We'll talk about "the rest of the job": managing up, managing out, and other aspects of being a seasoned manager that reports mostly don't see. And you'll take away a few best practices that take most managers years to discover.
Effective, experienced technical product management is crucial to make software engineering hum: Engineering and Product Management are symbiotic. When engineering is chaotic, many times applying a product management “fix” can do the trick. Ron Lichty has repeatedly been brought in to transform chaos to clarity in software development. Here’s a set of diagnoses, each with a product management fix that product managers can apply to make engineering hum.
AIPMM talk - chaos to clarity: managing the unmanageable, ron lichty, 12.7.12Ron Lichty
Good software management:
⁃ How to recognize it when you see it
⁃ How to encourage it
⁃ How to encourage senior management to encourage it
⁃ How to collaborate with it effectively
What does good software development management look like?
How do good programming managers motivate their teams?
What are programming managers bedeviled by?
How are programming managers tormented by product managers?
What are the forces that cause discord between product and software development managers?
What can be done about feature creep and late changing requirements?
Why do so many parts of organizations expect feature requirements to change but not delivery schedules?
What are objectives shared between programming managers and product managers that could encourage collaboration?
What would happen if programming managers and product managers formed mutual admiration societies with each other?
Product Owners - How to get your development team to love you (ProductTankSV,...Ron Lichty
Product managers and product owners can engage and motivate their teams to delight customers - or they can distract and dishearten their teams.
Ron Lichty has been a product manager, a CTO, and a VP leading both development organizations and product teams. As a development leader, he regards product managers who "get it" as key partners.
Here are 16 ways to engage and motivate product teams - to ensure that together that you delight customers!
Points to take away:
▪ Delighting customers is the metric to which we should manage
▪ Delighting customers relies on tight collaboration between product managers, product owners, and development teams
▪ Product managers and development leaders are uniquely positioned to, together, motivate product teams
▪ Product managers and product owners are uniquely positioned to connect the dots
BIo:
Ron Lichty has, for 30-plus years, championed delighting customers. He believes that strong product/engineering collaboration is essential to achieving that goal. Ron co-authored the Addison-Wesley book Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams (http://www.ManagingTheUnmanageable.net) and annually coauthors the Study of Product Team Performance (http://www.ronlichty.com/study.html).
Ron spent seven years as a programmer, two years as a product manager, and 25 years managing product and development organizations at all levels - to VP of engineering, VP of product and CTO - at companies ranging in size from tiny startups to Charles Schwab, Stanford and Apple.
He now consults across that realm, taking on fractional interim VP Engineering and acting CTO roles, training teams in agile, training managers in managing software people and teams, and coaching development teams and executives in making software development hum. (http://www.ronlichty.com)
Ron has long been a popular speaker at product, development and agile meetups and conferences.
Becoming an Agile Manager (bay scrum, 10.24.13)Ron Lichty
A common misconception about agile is that managers are unnecessary. After all, agile is based on self-organizing teams. If the teams organize themselves, what do managers do?
Unfortunately, most scrum training plays into that. Think about it: how many trainers or coaches have you seen sketch the structure of a scrum team with a drawing that includes a manager? While there's always a scrum master and a product owner, the core team and maybe some stakeholders, have you ever seen a manager in that drawing?
This misconception can be a problem all around: A frequently cited barrier to agile adoption is managers who don't know what to do when their teams become self-managing. When they're not included in training, how would they (or anyone else, for that matter) know how to characterize their role. At the same time, organizations often lay down expectations of managers, some compatible with agile, some not.
Agile has clearly shifted the old roles and responsibilities. Managers bent on command-and-control are clearly a barrier to agile adoption. But managers who take a hands-off approach or are treading water in a sea of ambiguity will almost certainly stymie adoption, as well.
Ron Lichty believes (and so do a lot of leading agile thought leaders) that managers have critical roles to play in enabling success, both of transitions to agile and of agile itself. This session is about those roles.
Ict educators win-win-win w agile, ron lichty, 1.4.13Ron Lichty
"Delivering a Win-Win-Win Workforce with Agile Programming Methods", presentation to the 2013 Winter ICT Educator conference in San Francisco January 4, 2013.
If We Are Agile, Why Do We Need Managers? (AgileIndy, 5.14)Ron Lichty
A common misconception about agile is that managers are unnecessary. After all, agile is based on self-organizing teams. If the teams organize themselves, what do managers do?
Unfortunately, most scrum training plays into that. Think about it: how many trainers or coaches have you seen sketch the structure of a scrum team with a drawing that includes a manager? While there's always a scrum master and a product owner, the core team and maybe some stakeholders, have you ever seen a manager in that drawing?
This misconception can be a problem all around: A frequently cited barrier to agile adoption is managers who don't know what to do when their teams become self-managing. When they're not included in training, how would they (or anyone else, for that matter) know how to characterize their role. At the same time, organizations often lay down expectations of managers, some compatible with agile, some not.
Agile has clearly shifted the old roles and responsibilities. Managers bent on command-and-control are clearly a barrier to agile adoption. But managers who take a hands-off approach or are treading water in a sea of ambiguity will almost certainly stymie adoption, as well.
Ron Lichty believes (and so do a lot of the early agile thought leaders) that managers have critical roles to play in enabling success, both of transitions to agile and of agile itself. This session is about those roles.
Almost no one on software teams believes in waterfall any longer. That's what we learned from the surveys we took in the course of authoring The 2013 Study of Product Team Performance.
But that doesn't make agile a magic pill.
Mike Cohn notes, "Becoming agile is hard. It is harder than most other organizational change efforts I've witnessed or been part of [for reasons] including the need to change from the top-down and bottom-up simultaneously, the impossibility of knowing exactly what the end state will look like, the dramatic and pervasive changes caused by Scrum, the difficulty adding more change on top of all that is already occurring, and the need to avoid turning Scrum into a list of best practices."
How do we get beyond that?
Glossing over the reality that agile is hard leads us to ignore the very things we need to address to succeed.
On the other hand, acknowledging that agile is hard lets us focus on the challenges that have been preventing us from becoming high performance teams.
This session combines a presentation, a panel and some shared thinking to move beyond how simple agile seems - to what in fact makes agile transformations hard - to how we can face down those challenges to achieve agile's promise.
Expected Takeaways (outcome) for Audience *
For those just starting agile transformations: a heads-up that implementing practices only goes so far.
For those well into agile but struggling, a sense they're not alone.
For all of us, a window into how to get to where we want to go.
Product owners - how to get your development team to love you (product school...Ron Lichty
Product managers and product owners can engage and motivate their teams to delight customers - or they can distract and dishearten their teams.
Ron Lichty has been a product manager, a CTO, and a VP leading both development organizations and product teams. As a development leader, he regards product managers who "get it" as key partners.
Here are 16 ways to engage and motivate product teams - to ensure that together that you delight customers!
BIo:
Ron Lichty has, for 30-plus years, championed delighting customers. He believes that strong product/engineering collaboration is essential to achieving that goal. Ron co-authored the Addison-Wesley book Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams (http://www.ManagingTheUnmanageable.net) and annually coauthors the Study of Product Team Performance (http://www.ronlichty.com/study.html).
Ron spent seven years as a programmer, two years as a product manager, and 25 years managing product and development organizations at all levels - to VP of engineering, VP of product and CTO - at companies ranging in size from tiny startups to Charles Schwab,Stanford, and Apple.
He now consults across that realm, taking on fractional interim VP Engineering and acting CTO roles, training teams in agile, training managers in managing software people and teams, and coaching development teams and executives in making software development hum. (http://www.ronlichty.com)
Ron has long been a popular speaker at product, development and agile meetups and conferences. Ron@RonLichty.com
Keys to crafting an effective agile culture (svcc, 10.15)Ron Lichty
What differentiates a successful software development culture?
Among successful cultures, what makes an agile one stand out?
We think successful software development cultures are ones that are not just performant but that both delight customers and are a joy for every team member to be part of.
One of the characteristics that differentiates agile cultures is that (finally!), it’s not just managers who are responsible for crafting culture - but everyone. And agile, done well, means every one of us engages in the crafting of it.
In addition to training teams in agile, Ron Lichty has spent years coaching managers about how their roles change with agile. While his recent Addison Wesley book, Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams, didn’t zero in on agile, both the book and the classes that he and his coauthor give current and prospective managers espouse a deeply agile mindset for managers.
If I handed you a sealed envelope with a list of problems I know exist in most software development shops, this is what would be inside.
Presented at SyXPAC
12 take aways - managing the unmanageableRon Lichty
Silicon Valley Code Camp presentation, October 2013, drawing 12 of the top actionable take-aways for managing programmers and programming teams, from the book, Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams, by Mickey W. Mantle and Ron Lichty.
Sydney Limited WIP Society presentation on "Systems Traps and Opportunities". Part of series introducing Systems Thinking based on Thinking in Systems by Donella Meadows
Crash Course: Managing Software People and Teams (IEEE, 4.4.13)Ron Lichty
"We'd like you to manage the team now." That's about as much introduction - and training - as many of us get before our first day managing. Often preceded only by, "You're a great programmer and you've got some people skills." But while programming cred and facility with people are helpful qualifications, what do you really need to know to manage well? What makes a manager great? What are the qualities that meld teams and deliver great software? Those are among the questions that led Ron Lichty and his co-author Mickey W. Mantle to write "Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams" (Addison-Wesley, September), now available for pre-order online. In this interactive session, we'll examine the great managers each of us has experienced, and the qualities, skills, finesse and gifts of greatness that made them stand out. We'll talk about "the rest of the job": managing up, managing out, and other aspects of being a seasoned manager that reports mostly don't see. And you'll take away a few best practices that take most managers years to discover.
Effective, experienced technical product management is crucial to make software engineering hum: Engineering and Product Management are symbiotic. When engineering is chaotic, many times applying a product management “fix” can do the trick. Ron Lichty has repeatedly been brought in to transform chaos to clarity in software development. Here’s a set of diagnoses, each with a product management fix that product managers can apply to make engineering hum.
AIPMM talk - chaos to clarity: managing the unmanageable, ron lichty, 12.7.12Ron Lichty
Good software management:
⁃ How to recognize it when you see it
⁃ How to encourage it
⁃ How to encourage senior management to encourage it
⁃ How to collaborate with it effectively
What does good software development management look like?
How do good programming managers motivate their teams?
What are programming managers bedeviled by?
How are programming managers tormented by product managers?
What are the forces that cause discord between product and software development managers?
What can be done about feature creep and late changing requirements?
Why do so many parts of organizations expect feature requirements to change but not delivery schedules?
What are objectives shared between programming managers and product managers that could encourage collaboration?
What would happen if programming managers and product managers formed mutual admiration societies with each other?
Product Owners - How to get your development team to love you (ProductTankSV,...Ron Lichty
Product managers and product owners can engage and motivate their teams to delight customers - or they can distract and dishearten their teams.
Ron Lichty has been a product manager, a CTO, and a VP leading both development organizations and product teams. As a development leader, he regards product managers who "get it" as key partners.
Here are 16 ways to engage and motivate product teams - to ensure that together that you delight customers!
Points to take away:
▪ Delighting customers is the metric to which we should manage
▪ Delighting customers relies on tight collaboration between product managers, product owners, and development teams
▪ Product managers and development leaders are uniquely positioned to, together, motivate product teams
▪ Product managers and product owners are uniquely positioned to connect the dots
BIo:
Ron Lichty has, for 30-plus years, championed delighting customers. He believes that strong product/engineering collaboration is essential to achieving that goal. Ron co-authored the Addison-Wesley book Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams (http://www.ManagingTheUnmanageable.net) and annually coauthors the Study of Product Team Performance (http://www.ronlichty.com/study.html).
Ron spent seven years as a programmer, two years as a product manager, and 25 years managing product and development organizations at all levels - to VP of engineering, VP of product and CTO - at companies ranging in size from tiny startups to Charles Schwab, Stanford and Apple.
He now consults across that realm, taking on fractional interim VP Engineering and acting CTO roles, training teams in agile, training managers in managing software people and teams, and coaching development teams and executives in making software development hum. (http://www.ronlichty.com)
Ron has long been a popular speaker at product, development and agile meetups and conferences.
Becoming an Agile Manager (bay scrum, 10.24.13)Ron Lichty
A common misconception about agile is that managers are unnecessary. After all, agile is based on self-organizing teams. If the teams organize themselves, what do managers do?
Unfortunately, most scrum training plays into that. Think about it: how many trainers or coaches have you seen sketch the structure of a scrum team with a drawing that includes a manager? While there's always a scrum master and a product owner, the core team and maybe some stakeholders, have you ever seen a manager in that drawing?
This misconception can be a problem all around: A frequently cited barrier to agile adoption is managers who don't know what to do when their teams become self-managing. When they're not included in training, how would they (or anyone else, for that matter) know how to characterize their role. At the same time, organizations often lay down expectations of managers, some compatible with agile, some not.
Agile has clearly shifted the old roles and responsibilities. Managers bent on command-and-control are clearly a barrier to agile adoption. But managers who take a hands-off approach or are treading water in a sea of ambiguity will almost certainly stymie adoption, as well.
Ron Lichty believes (and so do a lot of leading agile thought leaders) that managers have critical roles to play in enabling success, both of transitions to agile and of agile itself. This session is about those roles.
Ict educators win-win-win w agile, ron lichty, 1.4.13Ron Lichty
"Delivering a Win-Win-Win Workforce with Agile Programming Methods", presentation to the 2013 Winter ICT Educator conference in San Francisco January 4, 2013.
If We Are Agile, Why Do We Need Managers? (AgileIndy, 5.14)Ron Lichty
A common misconception about agile is that managers are unnecessary. After all, agile is based on self-organizing teams. If the teams organize themselves, what do managers do?
Unfortunately, most scrum training plays into that. Think about it: how many trainers or coaches have you seen sketch the structure of a scrum team with a drawing that includes a manager? While there's always a scrum master and a product owner, the core team and maybe some stakeholders, have you ever seen a manager in that drawing?
This misconception can be a problem all around: A frequently cited barrier to agile adoption is managers who don't know what to do when their teams become self-managing. When they're not included in training, how would they (or anyone else, for that matter) know how to characterize their role. At the same time, organizations often lay down expectations of managers, some compatible with agile, some not.
Agile has clearly shifted the old roles and responsibilities. Managers bent on command-and-control are clearly a barrier to agile adoption. But managers who take a hands-off approach or are treading water in a sea of ambiguity will almost certainly stymie adoption, as well.
Ron Lichty believes (and so do a lot of the early agile thought leaders) that managers have critical roles to play in enabling success, both of transitions to agile and of agile itself. This session is about those roles.
Almost no one on software teams believes in waterfall any longer. That's what we learned from the surveys we took in the course of authoring The 2013 Study of Product Team Performance.
But that doesn't make agile a magic pill.
Mike Cohn notes, "Becoming agile is hard. It is harder than most other organizational change efforts I've witnessed or been part of [for reasons] including the need to change from the top-down and bottom-up simultaneously, the impossibility of knowing exactly what the end state will look like, the dramatic and pervasive changes caused by Scrum, the difficulty adding more change on top of all that is already occurring, and the need to avoid turning Scrum into a list of best practices."
How do we get beyond that?
Glossing over the reality that agile is hard leads us to ignore the very things we need to address to succeed.
On the other hand, acknowledging that agile is hard lets us focus on the challenges that have been preventing us from becoming high performance teams.
This session combines a presentation, a panel and some shared thinking to move beyond how simple agile seems - to what in fact makes agile transformations hard - to how we can face down those challenges to achieve agile's promise.
Expected Takeaways (outcome) for Audience *
For those just starting agile transformations: a heads-up that implementing practices only goes so far.
For those well into agile but struggling, a sense they're not alone.
For all of us, a window into how to get to where we want to go.
Product owners - how to get your development team to love you (product school...Ron Lichty
Product managers and product owners can engage and motivate their teams to delight customers - or they can distract and dishearten their teams.
Ron Lichty has been a product manager, a CTO, and a VP leading both development organizations and product teams. As a development leader, he regards product managers who "get it" as key partners.
Here are 16 ways to engage and motivate product teams - to ensure that together that you delight customers!
BIo:
Ron Lichty has, for 30-plus years, championed delighting customers. He believes that strong product/engineering collaboration is essential to achieving that goal. Ron co-authored the Addison-Wesley book Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams (http://www.ManagingTheUnmanageable.net) and annually coauthors the Study of Product Team Performance (http://www.ronlichty.com/study.html).
Ron spent seven years as a programmer, two years as a product manager, and 25 years managing product and development organizations at all levels - to VP of engineering, VP of product and CTO - at companies ranging in size from tiny startups to Charles Schwab,Stanford, and Apple.
He now consults across that realm, taking on fractional interim VP Engineering and acting CTO roles, training teams in agile, training managers in managing software people and teams, and coaching development teams and executives in making software development hum. (http://www.ronlichty.com)
Ron has long been a popular speaker at product, development and agile meetups and conferences. Ron@RonLichty.com
Keys to crafting an effective agile culture (svcc, 10.15)Ron Lichty
What differentiates a successful software development culture?
Among successful cultures, what makes an agile one stand out?
We think successful software development cultures are ones that are not just performant but that both delight customers and are a joy for every team member to be part of.
One of the characteristics that differentiates agile cultures is that (finally!), it’s not just managers who are responsible for crafting culture - but everyone. And agile, done well, means every one of us engages in the crafting of it.
In addition to training teams in agile, Ron Lichty has spent years coaching managers about how their roles change with agile. While his recent Addison Wesley book, Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams, didn’t zero in on agile, both the book and the classes that he and his coauthor give current and prospective managers espouse a deeply agile mindset for managers.
If I handed you a sealed envelope with a list of problems I know exist in most software development shops, this is what would be inside.
Presented at SyXPAC
12 take aways - managing the unmanageableRon Lichty
Silicon Valley Code Camp presentation, October 2013, drawing 12 of the top actionable take-aways for managing programmers and programming teams, from the book, Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams, by Mickey W. Mantle and Ron Lichty.
Sydney Limited WIP Society presentation on "Systems Traps and Opportunities". Part of series introducing Systems Thinking based on Thinking in Systems by Donella Meadows
Content strategy workshop for LACONI, an association of 150 Chicago-area libraries, given September 20, 2013. Comprehensive look at content strategy goals, opportunities, challenges, definitions, processes, elements for libraries today and in the future.
Security Visualization - Let's Take A Step BackRaffael Marty
I gave the keynote at VizSec 2012. I used the opportunity to take a step back to see where security visualization is at and propose a challenge for how some of the problems we should be focusing on going forward.
Video recording is here: http://youtu.be/AEAs7IzTHMo
DNA_Arbitrage opportunity for investors in Buyback offers_Jan 9, 2009Jagannadham Thunuguntla
Jagannadham Thunuguntla, equity
head, SMC Capitals Ltd said an
investor who is bullish on any of
these scrips can buy it at current
levels. “There is an opportunity to
book a profit if it rises closer to the
maximum buyback price, thus providing
a window of opportunity for
arbitrage.”
[Stretch 2023] We're in it together and other perspectives on effective produ...Jason Yip
Have you watched those Spotify engineering culture videos? They were trendy and influential but that was around nine years ago. What might we say about effective product development culture today? In this talk, Jason will share a summary of 2023-era effective product development culture based on his eight years at Spotify and 14 years at ThoughtWorks. This will include core beliefs, guiding principles, and core practices. Which ones will align with what you see at your workplace? Which ones will highlight opportunities for improvement? This talk is not to encourage copying something that will become obsolete in another nine years, but instead to share an example of reflecting on effective product development culture to hopefully encourage your own ongoing reflection and improvement.
[Stretch 2023] What does productivity really mean at different levels_ Indivi...Jason Yip
Do you want to learn how to boost your productivity at individual, team, and organisational levels? If so, this presentation is for you. Individual productivity is about increased focus, frequent feedback, and reduced friction. Team productivity is about “flow over utilisation” and integration. Organisational productivity is about allocating effort, reducing relearning, and taking parallel bets. By the end of this presentation, you will better understand how to improve productivity at different scales and contexts.
[NYC Scrum] The top 3 points you should have paid attention to in the Spotify...Jason Yip
You’ve probably seen the famous Spotify Engineering Culture videos that describe how Spotify organizes its teams and processes to foster agility, autonomy, and innovation. But did you pay attention to the details?
In this presentation, we will revisit the videos and highlight the top three points that you should have noticed instead of Squads, Chapters, Tribes, Guild:
Aligned autonomy
Creating trust-at-scale
Decoupling
[AgileDevOps West 2023] We're in it together and other perspectives on effect...Jason Yip
Have you watched those Spotify engineering culture videos? They were trendy and influential in the agile community but that was around nine years ago. What might we say about effective product development culture today? In this keynote, Jason Yip will share a summary of 2023-era effective product development culture based on his eight years at Spotify and 14 years at ThoughtWorks. This will include core beliefs, guiding principles, and core practices. Which ones will align with what you see at your workplace? Which ones will highlight opportunities for improvement? This keynote is not to encourage copying something that will become obsolete in another nine years, but instead to share an example of reflecting on effective product development culture to hopefully encourage your own ongoing reflection and improvement.
[Craft Conf 2023] We're in it together and other perspectives on effective pr...Jason Yip
Have you watched those Spotify engineering culture videos? They were trendy and influential but that was around nine years ago. What might we say about effective product development culture today? In this talk, Jason will share a summary of 2023-era effective product development culture based on his eight years at Spotify and 14 years at ThoughtWorks. This will include core beliefs, guiding principles, and core practices. Which ones will align with what you see at your workplace? Which ones will highlight opportunities for improvement? This talk is not to encourage copying something that will become obsolete in another nine years, but instead to share an example of reflecting on effective product development culture to hopefully encourage your own ongoing reflection and improvement.
[Agile Lean Ireland June 2022] Tactics for influencing leaders at different l...Jason Yip
There are different levels of leaders, each of which require different tactics to influence. Jason will describe the differences he's seen between leaders at different levels (leaders of individual contributors, leaders of leaders, leaders of leaders of leaders) and then explore different tactics that seem to work better or worse for each level.
[CoPA 2022] Effective Product Development Culture circa 2022.pdfJason Yip
Presentation about effective product development culture as an evolution of Spotify Engineering Culture for the Bosch internal Community of Practice Agile conference
[Business Agility Conference 2022] The top 3 points you should have paid atte...Jason Yip
When people say “Spotify Model” they’re almost always thinking about org structure (Squads, Chapters, Guilds, Tribes). Structure is the last thing you should worry about. Before structure, I’ll expand on what you should have been paying attention to.
Agile India 2021: Experimenting with BAPO in Spotify Ads R&DJason Yip
BAPO stands for Business Architecture Process Organisation. It is Jan Bosch's more fleshed out expression of "structure should follow strategy". I recently experimented with applying this framework within Spotify Ads R&D and would like to share what worked and what didn't. Concepts expanded beyond BAPO to include product capabilities versus architecture services; overlapping product lifecycle s-curves; Simon Wardley's Pioneers, Settlers, Town Planners; and a reframing of the teaching people how to fish metaphor. Beyond sharing my successes and failures, this session will also encourage attendees to sketch how they might try this framework in their own context and anticipate what issues may appear.
Frug'Agile 2021: Agile as doctrine (and that's a good thing)Jason Yip
What are the fundamental principles by which Agile practitioners should guide their actions in support of objectives, that are authoritative but require judgement in application?
Using BAPO to apply structure follows strategyJason Yip
BAPO stands for Business Architecture Process Organisation. It is Jan Bosch's more fleshed out expression of "structure should follow strategy". I recently experimented with applying this framework and would like to share what worked and what didn't. Concepts expanded beyond BAPO to include product capabilities versus architecture services; overlapping product lifecycle s-curves; Simon Wardley's Pioneers, Settlers, Town Planners; and a reframing of the teaching people how to fish metaphor.
[Yow! 2019] 3 insights from 4 years at SpotifyJason Yip
Thinking back over my 4 years at Spotify, I see 3 main insights:
1. Aligned autonomy is an ongoing struggle;
2. Building teams in the context of high growth require different assumptions;
3. Consulting companies are generally better at forming high-performing teams fast.
How things still don’t quite work at Spotify... and how we’re trying to solve itJason Yip
Cerner Tech Talk version of my Culture and Methods talk. Exploration of key problems with how Spotify currently works to encourage "no problem is a problem" thinking
Agile 2017: What i've learned from 10+ years of evaluating Agile consultants ...Jason Yip
Agile is mainstream enough that the demand for Agile consultants and coaches is high. High demand attracts many people who lack relevant practical experience or only know how to practice, but don't know how to consult or coach. Organizations need effective ways to filter good candidates from bad. On the other side, candidates want to know what it takes to be considered good. I will share several patterns of selection approaches based on my experiences at Spotify and ThoughtWorks.
Agile Toronto 2016: What do you mean when you say "leadership"?Jason Yip
The word leadership can trick us into believing that we are talking about the same thing when are actually not. This presentation explores different leadership accountabilities and how they might manifest in different roles. I also describe different patterns of how this might play out using a couple specific examples from ThoughtWorks and Spotify.
UiPath Test Automation using UiPath Test Suite series, part 3DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 3. In this session, we will cover desktop automation along with UI automation.
Topics covered:
UI automation Introduction,
UI automation Sample
Desktop automation flow
Pradeep Chinnala, Senior Consultant Automation Developer @WonderBotz and UiPath MVP
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
GraphRAG is All You need? LLM & Knowledge GraphGuy Korland
Guy Korland, CEO and Co-founder of FalkorDB, will review two articles on the integration of language models with knowledge graphs.
1. Unifying Large Language Models and Knowledge Graphs: A Roadmap.
https://arxiv.org/abs/2306.08302
2. Microsoft Research's GraphRAG paper and a review paper on various uses of knowledge graphs:
https://www.microsoft.com/en-us/research/blog/graphrag-unlocking-llm-discovery-on-narrative-private-data/
GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using Deplo...James Anderson
Effective Application Security in Software Delivery lifecycle using Deployment Firewall and DBOM
The modern software delivery process (or the CI/CD process) includes many tools, distributed teams, open-source code, and cloud platforms. Constant focus on speed to release software to market, along with the traditional slow and manual security checks has caused gaps in continuous security as an important piece in the software supply chain. Today organizations feel more susceptible to external and internal cyber threats due to the vast attack surface in their applications supply chain and the lack of end-to-end governance and risk management.
The software team must secure its software delivery process to avoid vulnerability and security breaches. This needs to be achieved with existing tool chains and without extensive rework of the delivery processes. This talk will present strategies and techniques for providing visibility into the true risk of the existing vulnerabilities, preventing the introduction of security issues in the software, resolving vulnerabilities in production environments quickly, and capturing the deployment bill of materials (DBOM).
Speakers:
Bob Boule
Robert Boule is a technology enthusiast with PASSION for technology and making things work along with a knack for helping others understand how things work. He comes with around 20 years of solution engineering experience in application security, software continuous delivery, and SaaS platforms. He is known for his dynamic presentations in CI/CD and application security integrated in software delivery lifecycle.
Gopinath Rebala
Gopinath Rebala is the CTO of OpsMx, where he has overall responsibility for the machine learning and data processing architectures for Secure Software Delivery. Gopi also has a strong connection with our customers, leading design and architecture for strategic implementations. Gopi is a frequent speaker and well-known leader in continuous delivery and integrating security into software delivery.
Slack (or Teams) Automation for Bonterra Impact Management (fka Social Soluti...Jeffrey Haguewood
Sidekick Solutions uses Bonterra Impact Management (fka Social Solutions Apricot) and automation solutions to integrate data for business workflows.
We believe integration and automation are essential to user experience and the promise of efficient work through technology. Automation is the critical ingredient to realizing that full vision. We develop integration products and services for Bonterra Case Management software to support the deployment of automations for a variety of use cases.
This video focuses on the notifications, alerts, and approval requests using Slack for Bonterra Impact Management. The solutions covered in this webinar can also be deployed for Microsoft Teams.
Interested in deploying notification automations for Bonterra Impact Management? Contact us at sales@sidekicksolutionsllc.com to discuss next steps.
UiPath Test Automation using UiPath Test Suite series, part 4DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 4. In this session, we will cover Test Manager overview along with SAP heatmap.
The UiPath Test Manager overview with SAP heatmap webinar offers a concise yet comprehensive exploration of the role of a Test Manager within SAP environments, coupled with the utilization of heatmaps for effective testing strategies.
Participants will gain insights into the responsibilities, challenges, and best practices associated with test management in SAP projects. Additionally, the webinar delves into the significance of heatmaps as a visual aid for identifying testing priorities, areas of risk, and resource allocation within SAP landscapes. Through this session, attendees can expect to enhance their understanding of test management principles while learning practical approaches to optimize testing processes in SAP environments using heatmap visualization techniques
What will you get from this session?
1. Insights into SAP testing best practices
2. Heatmap utilization for testing
3. Optimization of testing processes
4. Demo
Topics covered:
Execution from the test manager
Orchestrator execution result
Defect reporting
SAP heatmap example with demo
Speaker:
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
DevOps and Testing slides at DASA ConnectKari Kakkonen
My and Rik Marselis slides at 30.5.2024 DASA Connect conference. We discuss about what is testing, then what is agile testing and finally what is Testing in DevOps. Finally we had lovely workshop with the participants trying to find out different ways to think about quality and testing in different parts of the DevOps infinity loop.
Kubernetes & AI - Beauty and the Beast !?! @KCD Istanbul 2024Tobias Schneck
As AI technology is pushing into IT I was wondering myself, as an “infrastructure container kubernetes guy”, how get this fancy AI technology get managed from an infrastructure operational view? Is it possible to apply our lovely cloud native principals as well? What benefit’s both technologies could bring to each other?
Let me take this questions and provide you a short journey through existing deployment models and use cases for AI software. On practical examples, we discuss what cloud/on-premise strategy we may need for applying it to our own infrastructure to get it to work from an enterprise perspective. I want to give an overview about infrastructure requirements and technologies, what could be beneficial or limiting your AI use cases in an enterprise environment. An interactive Demo will give you some insides, what approaches I got already working for real.
The Art of the Pitch: WordPress Relationships and SalesLaura Byrne
Clients don’t know what they don’t know. What web solutions are right for them? How does WordPress come into the picture? How do you make sure you understand scope and timeline? What do you do if sometime changes?
All these questions and more will be explored as we talk about matching clients’ needs with what your agency offers without pulling teeth or pulling your hair out. Practical tips, and strategies for successful relationship building that leads to closing the deal.
LF Energy Webinar: Electrical Grid Modelling and Simulation Through PowSyBl -...DanBrown980551
Do you want to learn how to model and simulate an electrical network from scratch in under an hour?
Then welcome to this PowSyBl workshop, hosted by Rte, the French Transmission System Operator (TSO)!
During the webinar, you will discover the PowSyBl ecosystem as well as handle and study an electrical network through an interactive Python notebook.
PowSyBl is an open source project hosted by LF Energy, which offers a comprehensive set of features for electrical grid modelling and simulation. Among other advanced features, PowSyBl provides:
- A fully editable and extendable library for grid component modelling;
- Visualization tools to display your network;
- Grid simulation tools, such as power flows, security analyses (with or without remedial actions) and sensitivity analyses;
The framework is mostly written in Java, with a Python binding so that Python developers can access PowSyBl functionalities as well.
What you will learn during the webinar:
- For beginners: discover PowSyBl's functionalities through a quick general presentation and the notebook, without needing any expert coding skills;
- For advanced developers: master the skills to efficiently apply PowSyBl functionalities to your real-world scenarios.
6. “the minimum viable product is
that version of a new product
which allows a team to collect
the maximum amount of
validated learning about
customers with the least effort.”
http://www.startuplessonslearned.com/2009/08/minimum-viable-product-guide.html
8. Magic Test
“…simply to put up a web page that says ‘Do you
have this problem? I’m going to solve it for you.’
And not really specify, be a little vague on how
you’re going to solve it. You’re basically saying ‘I’m
going to solve it by magic’. And then see if people
sign up and with those people that sign up then
you want to engage in dialog with them. We always
say ‘If you can’t sell magic, you definitely can’t sell
your product’…”
http://mixergy.com/eric-ries-lean-startup-interview/
11. Retrospectives
• What did we do well, that if we don’t discuss
we might forget?
• What did we learn?
• What should we do differently next time?
• What still puzzles us?
http://retrospectives.com/pages/RetrospectiveKeyQuestions.html
12. sheet. They are intended to stimulate discussion.
software development" Steve McConnell You might, or might not agree with the quotes along the edge of the John Maynard Keynes
path to a solution.” - Ward Cunningham
"Stable requirements are the holy grail of “It is better to be roughly right than precisely wrong.” -
“What is simplicity? Simplicity is the shortest
change them yourself.” -- Andy Warhol
They always say time changes things, but you actually have to
"Ugly programs are like ugly suspension bridges: they're much
each idea.
more liable to collapse than pretty ones" Eric Raymond
many of you agree with
count (and record) how re
pos de as mt on thi .
doing?
he n
inclu the lis k bette next
all ideas then quickly
Wri t to wo erently you
w o
sprin do di f thing
should stop
sibl
cou e a list
Make a long list, include se e s
Mak o diffe
el lti
te
9.
anything you
e - a any id sheet
or cu
ld
Is there
keep doing. e iffi
D
t. elin e d is u
t lea
8. Stop ee th yo
you did which you want to im th g
in did
sh t
r
rd
ff
ur s
st 4 s as
Make a list of all the things Enough? e
o
th eco
have you left? r d tie s
t? te ul tie
r
7. Keep R
!
ea
ent
How much time
s
This way round...
rin un iffic ul
r
sp nco t d ffic
s
e ha Di
Retrospective Dialogue Sheet (Sprint)
W
6.
,
t
rin te
Sp da
shorter: ʻ
"The maxim ʻ
d
en
question reader lead
Remember to let the
"Typing is not the bottleneck" Kevlin Henney
Paralysisʻ Winston Churchill
the discussion
Nothing avails but perfectionʻ
."
http://www.softwarestrategy.co.uk/dlgsheets/
From the list in #8, choose
10.
of work better?
do, to make the next piece
3 things you will do, or not
may be spelt
be the greatest successes
Action plan
the timeline or write it on
What do you consider to
Highlight successes on
5. Successes
I do and I understand.” -- Confucius
“I hear and I forget. I see and I remember.
of this sprint?
"Most teams are so far from good enough that perfection and
good enough are effectively the same thing" Jason Gorman
the sheet.
Nearly there....
good. Talk about both sides
on
significant and memorable You don't have to agree is
everything, discussion
of the argument
see in the world." Mahatma Ghandi
"We need to be the change we wish to
#3 .....................
#2 .....................
#1 .....................
Create a timeline for the sprint
Mark the start and end of the
sprint (iteration) then mark
you are considering in the
shortest schedules, lowest costs, and best customer satisfaction levels." Capers Jones
4. Create a timeline
"projects with low defect potentials and high defect removal efficiency also have the
space above.
But it is, perhaps, the end of the beginning." Winston Churchill
"Now this is not the end. It is not even the beginning of the end.
events.
Everyone who took part
11.
should sign here.
agrees with the actions
in this exercise, and
Sign-up
This way round...
Use this space however you like notes,
www.dialoguesheets.com
ideas, comments and suggestions.
Does everyone agree to
working on this sheet?
Send feedback to: feedback@dialoguesheets.com
Please tell us about your experience using this sheet.
follow Kerth's Prime
apportion blame. Focus on the
Directive (left) while
cause of problems and not the
The aim of this sheet is to find
better way of working, not to
individuals involved.
..................
..................
..................
..................
..................
..................
..................
..................
The team
"Insanity: doing the same thing over and over again
3. Set up
t
ar
and expecting different results." Albert Einstein
t
ts
rin
Sp ate
d
B
in T fo
p te h i r
e
1. Start here 2. Set up e er
iv v
,
ct sco uly st
l eo p nd e s d e y
o a
r rge le d al
i o This is a dialogue sheet, it is designed to Make sure everyone ire di tr be t
ea mo r t . I for ogu u D e d a
e w an the h er
c re ha f y gr e b promote good conversation. has a pen to write on im at d id n w r h s
to h g se n 8 ou ou she e Pr wh tan d ve o rce
a w ro p h p g this sheet. 's of rs ne gi his u at
ct or up ara the ave s of et is in Team members should seat themselves equally
io k n th s de yo d, e, eso on
n on a s te sp a 2 t er s n er ul r i
pl g g o
an an epa rou lit in rou 8 around the sheet so each question can be read K rdle st u ev co tim he uat
s d r p p Agree how long you will a u at e he , t sit
at co ate s, two by at least one person easily. Take one question eg m h sh t t s
R we ve t or n a ilitie the .
Fix the problem, not the blame.
th mp sh giv
Th ast and urs.
e
en are eet e at a time, skip questions if you like. The spend working on this lie he ow ab nd nd
at plete o ho
c om v er
is s one ma
be job kn nd e, a ha
le
d.
person closest to the question should read out sheet and write it in this l
o
he
as a b
w kills aila
et h ou r be
oal of
this the question and take notes of the discussion. box:
tw
wil
s av
The g to help
l ta to
is
sheet er Each person should get a chance to read and
d bett
ke
you fin orking.
y
ways
of w note at least one question.
(c) Software Strategy Ltd, 2010-2011 - Permission granted for individuals and Created by Allan Kelly Based on ideas from Royal Institute For more dialogue sheet downloads, printed sheets and
organization to print and use this sheet for their own purposes. Copying to http://www.allankelly.net of Technology, KTH, Stockholm
third parties, modification, redistribution and sale of this sheet is not permitted. information see http://www.dialoguesheets.com
13. Solution-Focused Goal-Driven
Retrospectives
1. "Imagine that a miracle occurred and all our
problems have been solved. How could you
tell? What would be different?”
2. "If 10 is the ideal and 0 is where nothing is
working, where are we now?”
3. "What are we already doing that works? That is,
why are we [for example] 5 rather than 0?”
4. "Using the resources we have, what can we do
to move one step closer to 10?"
http://jchyip.blogspot.com.au/2012/02/solution-focused-goal-driven.html
14. Idealised Design
• The system was destroyed last night
• No science fiction, technology available now
• How things should be, not how things could
be
http://www.organizationaldynamics.upenn.edu/node/2008
16. Continuous Testing
“What is continuous testing? It’s turning the
knob on Test Driven Development up to 11, by
automatically running the tests on every save.”
http://blog.objectmentor.com/articles/2007/09/20/continuous-testing-explained
http://topfunky.com/clients/blog/autotest-tm.mov
17. Guantanamo
“Do you have problems maintaining high test
coverage? All code is guilty until tested
innocent. Send the untested code to
Guantanamo!”
http://docs.codehaus.org/display/ASH/Guantanamo
19. Chaos Monkey
“One of the first systems our engineers built in
AWS is called the Chaos Monkey. The Chaos
Monkey’s job is to randomly kill instances and
services within our architecture. If we aren’t
constantly testing our ability to succeed despite
failure, then it isn’t likely to work when it
matters most – in the event of an unexpected
outage.”
http://techblog.netflix.com/2010/12/5-lessons-weve-learned-using-aws.html
20. Game Day
“Gameday is an exercise designed to increase
resilience through large-scale fault injection
across critical systems where resilience is seen
as the ability of a system to adapt to changes,
failures, & disturbances. By “system”, he means:
people, culture, processes, applications &
services, infrastructure, software and
hardware.”
http://server.dzone.com/videos/creating-resiliency-through
22. Lean Startup for Change
1. Identify an organisational problem
2. Propose a hypothesis for change
3. Identify assumptions in hypothesis
4. Design Minimal Viable Changes to test
assumptions
5. When “value hypothesis” has been refined,
switch to validate the “growth hypothesis”
http://yuvalyeret.com/2012/05/16/so-what-is-lean-startup-for-change-ls4chg/
27. Lewin Leadership Styles
• Authoritarian / Autocratic: “Do what I say!”
(less creative)
• Delegative / Laissez Faire: “Good luck!” (least
productive)
• Participative / Democratic: “Why did you
decide that? Have you considered this?” (most
effective)
http://psychology.about.com/od/leadership/a/leadstyles.htm
Editor's Notes
Key point: We’re introducing an expectation of behaviour here that moves us away from “Whose job is this?” “Not my problem” to “What is the right thing to do?” “How can I help?” That’s because the WIP limit policy makes it *our* problem, not just your problem.