location_city Bengaluru schedule Feb 26th 10:30 - Jan 1st 12:00 AM place Esquire

Traditional models of management and corporate governance are failing to keep up with the needs of the modern economy. Change, both technological and cultural, is occurring at faster rates than ever before. In this climate, modern enterprises will live or die on their ability to adapt. This is where Agile, and Agile Business Management, come in. Agile is change; changing how you think, changing how you work and changing the way you interact. This is important whether you are a software developer or a CEO.

In this presentation, Evan will provide engaging and enlightening case studies of Agile beyond IT; from lean startups to large enterprises. These will be reinforced with practical approaches for the leadership of teams, divisions and businesses. 

Taking the successful concepts and methods from the Agile movement and Evan's new book, Agile Business Management is a framework for the day-to-day management of organisations regardless of industry, size or location. We will discuss processes, techniques, and case studies for the 4 key domains from Agile Business Management;

  1. You, the Agile Manager - What makes a good manager and how do their responsibilities change?
  2. Integrated Customer Engagement - Collaboration and communication techniques to build trust and deliver Customer needs efficiently, with minimal waste, and to everyone's satisfaction.
  3. The Structure of an Agile Organisation - Efficient, transparent and collaborative techniques to manage empowered staff.
  4. Work, the Agile Way - Managing all types of business functions, from software, HR, finance to legal, by using Just-In-Time planning and Incremental or Continuous Delivery processes.

Ultimately, the goal of this presentation is to make you think about your role as a leader. 

 
 

Outline/Structure of the Talk

A brief (5 min) introduction will familiarise the audience with the topic of Agile Business Management and the differences between Agile ICT management and Agile Business Management. The bulk of the presentation will be split into discussing the 4 domains (The Agile Manager, Integrated Customer Engagement, The Structure of an Agile Organisation, Work, the Agile Way) with at least 2 real-life case studies. During each domain, we will cover processes and techniques applicable to most industries and business functions, with some specific examples to demonstrate how to tailor the framework.

Depending on the size of the audience, I generally welcome questions throughout the presentation but will allocate approximately 5 minutes at the end for complex and additional questions.

Learning Outcome

Regardless of whether you come from IT, HR, Finance or Sales, the goals of this presentation are to;

  • make you think about your role as a manager or leader
  • raise questions about your Customers; who are they, what are their needs, what are their goals, and how can you work together
  • introduce new possibilities and ways of doing business

You will come away from this presentation with practical understanding of Agile Business Management as well as techniques, based on the 4 domains, that you can apply within your own organisation. These include;

  • Defining the requirements, and KPI's, for a good agile manager and the cognitive distortions that impact on good management
  • Understanding the difference between Customer & consumer and between internal and external Customers
  • Learn to build a light-weight, Agile, business case to meet governance requirements
  • Guidance on how to tailor Agile to different business functions (HR, ICT, Sales, Finance, Media, Legal, Production & Operations)
  • Adapting XP, Scrum and Kanban to manage workflow and requirements across the organisation in non-IT and non-project environments
  • Customising TDD to manage outcomes and quality control across an Agile organisation
  • How to design an organisation structure based on cross-functional teams
  • The benefits of an Agile board and executive governance bodies
  • How to create Agile budgets and funding models, and who has responsibility for their management.

Target Audience

Managers, Agile Coaches and Business Leaders

schedule Submitted 6 years ago

Public Feedback


    • Liked Balaji.M
      keyboard_arrow_down

      Balaji.M / Srinath Chandrasekharan - Visualization and Agile Practices to the Rescue of Traditional Project

      20 Mins
      Experience Report
      Intermediate

      We are from Large Indian IT Services organisation where most of the projects follow traditional/waterfall ways of working and the mindset of the senior management is also used to this way of working for all project types (Application Maintenance, Minor Enhancement, Bug Fixing and L3 Analysis space), while these methods have their own shortfalls and projects suffer because of the methodology, many leaders still believe that by following tradtional process their problems would be solved. Through this experience report, we would like to share how Visualisation and Agile Practices rescued the waterfall project from depleting Customer Confidence and Quality of Service Delivery.

      The Project team of 9 members distributed at onsite and offshore was involved in maintenance / enhancement type of work for a large Investment Bank with several new features being implemented as change requests. Team’s responsibility starts from Analysis to Deployment into Production for the work comes in ad-hoc manner. The issues and challenges by project teams were

      • Longer duration to complete the change requests and ensuring an on-time delivery
      • Low Customer Satisfaction and Quality of Deliverable.
      • Proactively manage application issues despite higher experience of team.
      • Low employee morale
      • Lack of senior management participation and constant fire fighting with the customer.

      Project team focused on 3 areas

      Business/Client IT team

      • Prioritize the change requests by highest business/end user value (Input Cadence)

      • ‘Drive’ the development efforts to incrementally deliver

      Teams

      • Focused on speed in delivering change request by eliminating waste

      • Focused on enhancing knowledge sharing by Collaboration using Visualisation Boards and daily stand up meeting

      • Focus to Deliver right at First Time

      Management

      • Focus on the value stream (cycle time)

      • ‘Drive’ Continuous Improvement (Kaizen)

      • Manage impediments , making blockers visible

      Within 3 months of time after team started adopting the Visualisation and Agile practices the teams and senior management could see the improvement in the areas of 

      1. Increase in Balance Score Card scores from 4 to 6.5 and many areas scored 7.0/7.0
      2. Productivity improvement by 25%

    • Liked Tarang Baxi
      keyboard_arrow_down

      Tarang Baxi / Chirag Doshi - A Practical Guide to Setting up Distributed Agile Projects

      45 Mins
      Talk
      Beginner

      A practical guide to setting up a new agile project team. Based on years of agile delivery and coaching experience for projects in a number of distributed and offshore models, for teams sized from 10 to 200 people, and spread across 4 continents, and 8+ locations. Some areas that will be touched on:

      • People - how to organize distributed teams, cultural factors to consider, ways to build trust, and how to avoid timezone burnout.
      • Process - how to communicate effectively, plan collaboratively, setup distributed practices (standups, retros, pairing, etc), effectively divide work on a common codebase, maintain visibility, and track progress.
      • Tools - (tips provided as a handout) which hardware and software tools should you absolutely invest in to help overcome communication,  visibility and collaboration challenges
    • Liked Raja Bavani
      keyboard_arrow_down

      Raja Bavani - A Principle-Centered Approach to Distributed Agile (OR) Distributed Agile: Ten Guiding Principles

      Raja Bavani
      Raja Bavani
      Chief Architect
      Mindtree
      schedule 6 years ago
      Sold Out!
      20 Mins
      Experience Report
      Beginner

      The challenges in distributed agile can be seen under three broad categories viz., a) Communication and Coordination, b) Time Zone Differences and c) Issues related to People, Culture and Leadership Style. Successful teams consciously adhere to certain principles and it is their principle-centered approach that helps them face such challenges and deliver the best.

      Steven Covey wrote: "Principles always have natural consequences attached to them. There are positive consequences when we live in harmony with the principles. There are negative consequences when we ignore them. But because these principles apply to everyone, whether or not they are aware, this limitation is universal. And the more we know of correct principles, the greater is our personal freedom to act wisely." This is true in all situations of life and it includes application of agile methods in geographically distributed teams too.

      This session is to present the ten principles and elaborate 3-4 principles learned through experience in working with project teams and interactions with industry experts, and applied for more than a decade. These ten principles are above and beyond agile manifesto and agile principles. These are related to areas such as context-specific methodology, tools for productivity improvement, infrastructure for communication and coordination, knowledge management, focus on quality, inclusion, collaborative governance, automation, technical debt management, iteration progression and ensuring early success.

    • Liked Naresh Jain
      keyboard_arrow_down

      Naresh Jain - Scaling XP Practices inside your organization using Train-the-Trainer Model

      Naresh Jain
      Naresh Jain
      Founder
      Xnsio
      schedule 6 years ago
      Sold Out!
      90 Mins
      Workshop
      Advanced

      How do you effectively scale skill-based, quality training across your organization?

      Over the years, I've experimented with different ideas/models to scaling skill-based training across an organization. In the last 4 years, I've pretty much settled down on the following model. Its very useful when mentoring teams on skills like Test-Drive-Development (TDD), Behavior-Driven Development (BDD), Product Discovery, Writing User Stories, Evolutionary Design, Design Patterns, Problem Solving, etc. I've successfully implemented this model at some very prominent fortune 500 enterprises.

      The goal of this workshop is to explore what other successful models organized have used to scale skill-based training in their organization.

    • Liked Tathagat Varma
      keyboard_arrow_down

      Tathagat Varma - Agile, Management 3.0, Holacracy...what next?

      Tathagat Varma
      Tathagat Varma
      Country Manager
      NerdWallet
      schedule 6 years ago
      Sold Out!
      45 Mins
      Talk
      Advanced

      Pesentation deck is now available at http://www.slideshare.net/Managewell/what-next-31791295

      Modern management methods are still based on the then seminal work by Henri Fayol some 200 years back, followed by Frederick Taylor's work some 100 years back! Sadly, those models were predominantly based on industrial work, and don't really work that well in knowledge industry and today's sociological dynamics at workplace. Classical Agile methods codify several people practices that allow for a self-organizing team to evolve, but doesn't offer a lot of guidance on how to develop and groom leadership for agile organizations beyond a software team. Management 3.0 takes this issue further and develops it into a separate discipline altogether. On similar lines, Holacracy seeks to create social technology for purposeful organizations, though not specially targeting software organizations. So, the issue of leadership still continues to be unresolved and rather left to pave its way on its own. Unfortunately, when we want to achieve true end-to-end agility, it is not enough for software teams to be charging at top speeds but leadership not evenly matched to support them well in their endeavors. We clearly have a problem at hand...

      In this talk, we will study how the role of leadership has evolved and what does it look like for agile organizations at present. Many agile methods take an extreme view that limit leadership to team-level collective ownership of leadership. However, that might not be enough because of various reasons. In any non-trivial organization, whether a software organizations or any modern business employing software for business advantage, the reality is that organization units beyond a plain-vanilla software teams do exist. So, how does one go about grooming their top talent for playing an effective part in this process?

      Finally, we will also try to take a shot at some of evolving paradigms. For example, all these management thoughts are still based on the kind of outdated premise that an organization is based on 'boundaries' of operations. However, already we see that model being broken down, and the future teams look more like boundaryless entities bound with nothing but a unifying purpose that brings a bunch of volunteers together for a period of time. If our success increasing depends on such teams being able to effectively self-manage themselves, what role does leadership have to play in it, and are we getting ready for it? 

    • Liked Mike Burrows
      keyboard_arrow_down

      Mike Burrows - Kanban through its Values: An Agenda for Scale

      45 Mins
      Talk
      Intermediate

      Introducing the Kanban method through a 3-layered value system - a familiar core that stimulates and drives change, a middle layer that is about direction and alignment, and a protective outer layer of discipline and working agreements.

      This humane, values-centric model aligns Kanban with the concept of the Learning Organisation and suggests ways to seek resonances with other methods. It has some practical benefits too: it can help us engage more effectively with the organisation as it currently is; it encourages us to self-reflect on our effectiveness as agents of change; it provides a convenient framework for the capture of stories.

    • Liked Johannes Brodwall
      keyboard_arrow_down

      Johannes Brodwall / Buddhima w.wickramasinghe. - Practice agile programming with coding dojo

      90 Mins
      Workshop
      Beginner

      A Coding Dojo is a fun and social way to become a better programmer. Johannes is an experienced coding coach who will guide you through a few hours of programming that will transform your understand your craft and yourself as a programmer. In the workshop you get to try out pair programming, test-driven development and continuous refactoring for yourself and you get lots of recommendations on how to improve your coding and testing. You will need to bring your own computer with a development environment of your choice. Recommended for Java, Ruby, JavaScript and C# developers.

      This is what previous participants say about the workshop:

      • What did you learn? New tools, pair programming and fun exercises; Ide tricks, programming language basics, testing tools, using tests as a reasoning tool; you can comfortably pair with strangers.
      • What surprised you? Small steps work better than planning; It's easy to get started when you pair program; Pair programming is nice
      • What do you plan to do next? Using TDD every day; Listen to partner more carefully - he may already have solved the problem.
    • Liked Lynne Cazaly
      keyboard_arrow_down

      Lynne Cazaly - The Girl with the Chisel Tip Marker

      Lynne Cazaly
      Lynne Cazaly
      Owner
      Lynne Cazaly
      schedule 6 years ago
      Sold Out!
      45 Mins
      Workshop
      Beginner

      One of the quickest ways to achieve greater buy-in, clearer communication and higher levels of engagement with team members, stakeholders, sponsors and business units is to get "visual agility". Using cards, stories, post it notes, visual charts, maps, models, metaphors - and most of all, some hand crafted "drawn-in-the-moment" visuals learn some engaging ways to facilitate with visuals in an Agile world. 

      Many people speak about 'making work visible' - showing progress, visualising solutions, scoping out possibilities - having visual agility gives you the skills to step into any role at a moment's notice and help bring clarity to the problem, quicker. This can apply to individual thinking and brainstorming, or group situations when you're presenting your idea or you're working with the group to create a solution. 

      Lynne Cazaly is a communications specialist and master facilitator. Lynne provides clarity to project complexity through workshops, training and visual strategy. Lynne trains, facilitates, speaks and coaches on visual facilitation, visual thinking and other engaging tools for project people, to help boost buy-in, collaboration and engagement.

      Lynne Cazaly is the author of the book 'Visual Mojo - how to capture thinking, convey information and collaborate using visuals'. 

      http://www.lynnecazaly.com.au/visual-mojo-the-book-lynne-caz/

      Included in this session is 30 icons to use straight away which Lynne calls 'Quick Pics'.

      Lynne recently ran the session again in New Zealand at an Agile Wellington Meetup - read their comments here

    • Liked Johannes Brodwall
      keyboard_arrow_down

      Johannes Brodwall / Niruka Ruhunage - Remote Pair Programming

      45 Mins
      Demonstration
      Beginner

      Can you maintain agile engineering practices with a distributed team?

      Johannes is the Oslo based Chief Scientist for the Sri Lanka based company Exilesoft. In order to promote agile engineering practices, he uses remote pair programming to connect with teams halfway across the world.

      In this talk, we will go through a practical approach for remote pair programming adopted for high-latency situations. We will demonstrate remote pair programming with a live example and we will discuss the advantages and usages of the approach. We will also cover the practical parts of remote pair programming, such as tools and setup.

      After seeing this talk, the audience should be able to remotely pair with members of their distributed team. They will also get a lot of tips on how to use pair programming effectively in both local and remote settings.

    • Liked Mikael Gislen
      keyboard_arrow_down

      Mikael Gislen - Mitigating clashing paradigms between Agile Development and ISO 9000

      45 Mins
      Talk
      Advanced

      There are, on a philosophical level, significant clashes between the agile paradigm and Quality Systems such as ISO 9000 or CMM/CMMi, this is already presented in the Agile Manifesto. Agile Development is based on what I would call post-modern paradigms when compared to the plan-driven and early iterative development methodologies which are based on a positivist paradigm.

      The underlying philosophical challenges cannot be easily mitigated. But a purist agile paradigm may tend to stress a positivist paradigm as well and this can be dangerous since then agile would not be agile any longer.

      While it may not be possible to completely remove the challenges between agile and quality systems, it is possible to learn to live with some tension between different paradigms. 

      There are some obvious areas of conflict, for examplethe Agile methodologies strongly discourages unnecessary documentation, and questions that it is possible to provide all requirements up-front. ISO 9000 on the other hand demands requirements up-front and documented evidence of almost anything, but such practical aspects can actually be mitigated with relative ease. Other aspects may demand much more effort. In particular the internal auditing process is problematic and other means of ensuring compliance may have to be considered.

      We have in my company systematically piloted a number of organisational changes in order to better support agile development. We have done this within the overall framework of our ISO 9000 system which is used a structure anda a gatekeeper. To do this we have used Action Research, which in it self is a kind of agile methodology, although of much older date than agile development.

      I will in my talk focus on the practical experiences we have had of building an organisational framework for agile development and while doing that suggesting a few means to mitigate the challenges mentioned initialy.

    • Liked Sudipta Lahiri
      keyboard_arrow_down

      Sudipta Lahiri - Capacity Planning for Dynamic Teams

      20 Mins
      Experience Report
      Intermediate

      Fixed price (and fixed scope) projects dominate the offshore industry. These projects have offshore/onsite teams. They often have large team size (over 100s of people in one team).

      Agile thinking uses team velocity/ throughput and uses that to project an end date (Kanban system) or how much scope can be accomplished in a given time duration (number of sprints in SCRUM). They assume a stable team. However, this is not applicable for projects. They experience resource and productivity ramp-up issues. Often, resources keep changing as new projects come in. Projects do not have past velocity or throughput data. Extrapolating historical data from other similar projects, though possible, is inaccurate for multiple reasons.

      This talk is based on our experience of working with such project teams. They want to adopt agile methods. We show how they can adopt the Kanban Method and yet do: A) Initial Capacity Planning B) Assess the impact of scope creep to the project end date.

      The session assumes a basic understanding of the Kanban method.

    • Liked Ellen Grove
      keyboard_arrow_down

      Ellen Grove - Build Your Dreams: User Requirements Gathering with LEGO Serious Play

      90 Mins
      Workshop
      Beginner

      Let your hands be the search engine for your brain! LEGO® Serious Play® is a powerful thinking, communicating and problem solving technique that can help you and your team do serious work through structured play activities using a popular and playful 3D modeling toy. Through a facilitated process of building models that, storytelling and reflection, every person at the table is engaged and actively participating in the discussion, whether the topic is individual aspirations, team relationships, developing a new product or solving a wicked organizational problem. Everyone builds and everyone tells their story – all participants have equal opportunity to put their own points of view on the table, unlocking new perspectives and exposing the answers that are already in the room.  LEGO Serious Play has been used successfully for team-building and problem solving in a variety of organizations, from NASA to RBC to academic settings and public utilities.  

      This presentation provides a hands-on introduction to LEGO Serious Play, so that you can experience firsthand how using LEGO to do real work unleashes creativity and enables meaningful conversations in a very short time. We will explore how to use this playful technique to collaboratively elicit information about user requirements and strategic design issues using the open source User Requirements with Lego methodology developed by a team at the University of Lugano, Switzerland.  This approach is particularly suited to Agile teams that want to get team members and stakeholders sharing their different perspectives on common goals in an open and light-weight manner.

    • Liked Jason Yip
      keyboard_arrow_down

      Jason Yip - Think Like an Agilist: Deliberate practice for Agile culture

      Jason Yip
      Jason Yip
      Principal Consultant
      ThoughtWorks
      schedule 6 years ago
      Sold Out!
      90 Mins
      Workshop
      Intermediate

      If I say, culture is important to adopting Agile, most people will just agree without even thinking too much about it.  But what is meant by "culture"?  Why is it important?

      Culture is not typical behaviour; it is not what we say we value (but don't actually do).  Culture is our basic assumptions of how things work.  Culture is the logic we use to think through and respond to any particular situation.

      If you imagine a pyramid, Agile practice and any other visible behaviour is on the top, stated or written Agile values and principles are in the middle, fundamental assumptions (aka culture) is at the base.

      My session is intended to expose people to the base of that pyramid.

      If culture is assumptions, then to understand Agile culture, we need to understand the basic assumptions of Agile.  To do this, I have created an approach called "Think Like an Agilist" that both exposes how we think through an "Agile situation" and allows us to deliberately practice "Agile culture".

      The general idea is that I won't just talk about Agile culture and values, what I'll call "culture theatre", but rather expose people, who nominally consider themselves part of the Agile culture, to their underlying thought processes and assumptions, given a relatively difficult scenario.  Those thought processes and assumptions are the essence of culture (reference Edgar H. Schein).  What is interesting is noting when the thought processes and assumptions are different which indicates that there is a different culture at play.  What I've noticed is that this difference is common between novice vs expert Agilists.

      Note that it isn't even about analyzing vs doing it mechanically but more about exposing what assumptions are being used to respond.

      NOTE: I will be updating the attached slides as when I created them, I was framing it more as "doctrine" rather than "culture", defined as fundamental assumptions"

    • Liked Abhilash Chandran
      keyboard_arrow_down

      Abhilash Chandran - Retrospectives with large projects and (or) multiple teams

      20 Mins
      Experience Report
      Intermediate

      Retrospectives are the one of the most integral components of any agile methodology.  In scrum a retrospective is typically done after each sprint. This process is simple if team is small or only one team is working on a product. The problem starts increasing exponentially when many teams work on a single product. All the teams have ideas to improve the process and production.  One team may have an entire opposite idea of another. How to bridge this gap?

      Last project executed across different teams (onsite & offshore) and different departments was not a great success. How to learn from the past failures and apply it to future projects?

      In this discussion, I will be talking about some the points which can be easily followed in such scenarios. 

      Why did we did this?

      Normally in a scrum environment we have a single team with Product Owner; they do the retrospectives within team. Team identifies the issues and work on them. Many team falls into this category. It is pretty simple

      Let’s complicate this further.

      • A big product with 10 scrum team
      • Each Team has different PO

      Apart from these main stake holders there are many others who are interested in the success of this application

      • Sales team
      • Documentation team
      • UI design team
      • Architecture and performance team

      In such a scenario, a retrospective at team level will be effective only at granular level. But it leaves a gap in few areas; it helps to bring all the teams together for one big retrospective

      • Apply the improvements made at each team level to the whole program
      • A team's retro action item against the process followed by another team can be discussed at a higher level to find an optimal solution
      • Sometimes two team's retrospective action items may be contradictory. This gathering may point a third solution
      • Sr Product owners and manager will get all the teams together. A common focus and improvement plan can be shared across teams.
      •  All team gets to know about the key concerns at the program level and with other teams.
      • Ultimately it gave a feeling of one big family.

      My experience

      Last large retro organized in our group was a big success. The sales team & architecture team had many ley lessons to take back from this meeting.  Many issues were bought out which could have been solved with better co-ordination across team.  Concrete action plans were made by team for the subsequent release.  Some of the key findings were shared across other program teams also.

    • Liked Ram Srinivasan
      keyboard_arrow_down

      Ram Srinivasan - The Conflict Paradox

      90 Mins
      Workshop
      Intermediate

      It is not a question of if a team is going to have a conflict; it is a question of when. Equipping them to deal with conflict is more than creating agreements or having a good facilitator. We look at a conflict model that focuses on dynamics of conflict by understanding- 1. Cognitive skills:self-awareness about triggers, hot spots, emotions,behaviors. 2. Emotional skills:reading emotions, body language, balancing emotions, using curiosity 3. Behavioral skills:understanding others’ perspectives and needs, avoiding 8 destructive behaviors, embracing 8 constructive behavior. In an organizational setting, it is important to understand the source (culture, interdependence, incompatibility, personality, power, etc.) and types of conflict (cognitive vs. affective). Creating awareness about conflict processes, retaliatory cycles and building a conflict profile can empower teams engage in constructive disagreements. 

    • Liked Colin O'Neill
      keyboard_arrow_down

      Colin O'Neill - Achieving Enterprise Agility with the Scaled Agile Framework...and Have Fun Doing It!

      90 Mins
      Tutorial
      Intermediate

      Scrum, XP, Kanban and related methods have been proven to provide step changes in productivity and quality for software teams. However, these methods do not have the native constructs necessary to scale to the enterprise. What the industry desperately needs is a solution that moves from a set of simplistic, disparate, development-centric methods, to a scalable, unified approach that addresses the complex constructs and additional stakeholders in the organization—and enables realization of enterprise-class product or service initiatives via aligned and cooperative solution development.

    • Liked Ram Ramalingam
      keyboard_arrow_down

      Ram Ramalingam - The secret shortcuts to Agile... (that won't get you there)

      Ram Ramalingam
      Ram Ramalingam
      Associate Partner
      IBM
      schedule 6 years ago
      Sold Out!
      45 Mins
      Talk
      Advanced

      This is an exploratory talk, based, first, on some recent insights from cognitive science, behavioural economics (which have enriched Agile folklore already) and then on, some interesting twists from culture based research in sociology and psychology. While the former will be useful in understanding the common pitfalls encountered in a scaled Agile implementation, the latter, maybe useful in understanding the unexpected twists when doing scaled agile in a distributed/off-shore environment that have different cultural norms.

      While the anti-patterns and anti-paths are common across the world, the solution to these does differ. The assumptions behind what leads to a motivated, self-organizing, self-directing team will determine how to bring about a nuanced mindset to Agility, and understanding that what works in the West may not work in India (and other similar higher Power-Distance-Index countries).

      While sharing my experiences in a large scale Agile transformation and working with different cultures, I hope to bring out some subtle variations that could be useful in coaching and working with and transforming Agile teams in an offshore engagement.

    • Liked Carlos Lopes
      keyboard_arrow_down

      Carlos Lopes - Multiple projects, different goals, one thing in common: the codebase!

      Carlos Lopes
      Carlos Lopes
      Software Developer
      ThoughtWorks
      schedule 6 years ago
      Sold Out!
      45 Mins
      Talk
      Intermediate

      Are you developing new functionalities into branches? Have you ever experienced the pain of merging the changes into trunk? The so called "merge hell" is one of the first and probably the most important smell that tells you've been abusing of your source control manager branching capabilities and, most likely, hurting your productivity and your code quality as well. In order to move towards a continuous delivery approach, the practice of trunk based development suggests ways to avoid this type of issues among others like inconsistent feature sets, code that stays in an undeployable state for a long time, regressions introduced by semantic differences that arise during those joyful merging sessions, integration surprises with the other features, and the like. Even if you are not a developer on your team you will benefit from the examples and techniques presented.

    • Liked Fiona Mullen
      keyboard_arrow_down

      Fiona Mullen - Agile - An Australian Journey of Cultural Change

      45 Mins
      Talk
      Beginner

      How did one of Australia's leading financial services organisation become the biggest Agile transformation story in the Southern hemisphere and what did we learn?

      The Suncorp Group leads in general insurance, banking, life insurance, superannuation and investment brands within Australia and New Zealand. The Group has 16,000 employees and relationships with nine million customers. It is a Top 20 ASX listed company with over $93 billion in assets.

      In 2007, we embarked on our Agile journey of cultural change. In this talk we will cover the strategy taken, the roadblocks we came across, the mistakes we made and the achievements along the way.

      You will learn how to tackle an Agile transformation, what to do and what NOT to do, where to start and what to expect and most of all what impact it will have, both negative and positive.

      Today Suncorp are seen as market leaders in Agile and are known globally for the Agile Academy http://www.agileacademy.com.au/agile/ which was designed for both staff and also the external market.

      The role of the Agile PMO, how to get infrastructure to work Agile, what about all those legal challenges, the cultural differences and the resistance to change? These are some of the learning we will share.

      There were challenges and successes and in this honest Aussie presentation will share with you both the highs and the lows.

    • Liked Herry Wiputra
      keyboard_arrow_down

      Herry Wiputra - Crossing the T's and Dotting the I's

      20 Mins
      Experience Report
      Intermediate

      The term "cross functional team" has been made popular by the Agile movement. In cross functional team, we put people with different roles to work together for a common goal/purpose.

      I have seen this worked really well in many agile teams. People are no longer on silo and everyone have better understanding what each other's role is and consequently, what each other do. This leads to better self organising within the team.

      However, I strongly believe we can take this concept to the new level. The concept of cross functional team should be extended to not just the team but also to the individuals within the team. Scott Ambler wrote an essay on "Generalising Specialist". The term T-shaped developer was introduced by Mary and Tom Poppendieck in her famous book "Lean Software Development". By nature, people don't like to get out of their comfort zone, hence the tendency to keep working in area that they are familiar with. When leaders can create an environment where everyone is encouraged to learn, grow and make mistakes, amazing things can happen.

      In my experience leading teams, I have witnessed many transformations that enabled individuals to go beyond their traditional role, such as a manual QA assuming Scrum Master role, a BA doing deployment, a developer doing QA for a story, etc. Not only this enablement help develop the individuals to widen their horizon and skillset, it also helped the productivity of the team through better collaboration. When a team reach this stage, we no longer have problems such as "The QA has nothing to do because there are no stories to test", "The developers have nothing to do because the cannot keep up", "The deployment took longer than expected because the Ops person was not aware of the special configuration".