Organizations which have diverse functional units and technology portfolios (BI, Mobile, Web Application development, Web Design etc) following different methods cannot make an overnight or a sudden transformation to following a mature model of Agile method.

These teams need to come up with a structured approach towards Agile adoption and transformation enabling the different teams to make a gradual progression towards the adoption of Agile in their projects and teams.

We at Aditi Technologies realized this and came up with a Aditi Agile Transformation Maturity Model which provides guidance to the different project teams and functional groups on the transformation journey within their engagement. The salient points of the Maturity model include:

* Agile Project Planning and Management Maturity Model - Traditional teams are used to tradition planning methods plan around the typical 3 constraints of Scope, Cost and Time. A transformation to a model where emphasis is on delivering the highest priority items is arguably one of the more difficult lifecycle areas of the transformation. The Agile Project Planning and Management maturity model provides guidance to such teams on moving from a managed team services model to a self directed and self managing teams services model.

* Collaboration Maturity Model - Moving from a SLA driven environment to a collaborative environment is again a massive cultural mindset change for the different teams. The collaboration maturity model at Aditi for Agile engagements provides a framework for teams to start collaborating better in a gradual manner. Starting with a well defined collaboration model within the Agile sprints between the QA and Development teams leading to an end to end collaborative lifecycle involving the different stakeholders is the overall approach we have adopted at Aditi to improve the Collaboration within the lifecycle in a phase wise manner.

* Agile Requirements Engineering Maturity Model - The Aditi AREMM provides the business and product ownership teams with a gradual migration approach from the traditional Business Requirements Document based Requirements Management approach to an Agile approach towards the same incorporating basic principles like story card based requirements engineering to a more collaborative and leaner approach incorporating starting principles such as Product Backlog and Story Cards and moving to more advanced models such as executable specification models prescribed by BDD.

* Engineering Maturity Model - While there are well prescribed best practices and models within the Engineering phase for Agile teams, adopting an all at once approach can be fraught with danger for the teams especially given the constraints of a global delivery model such as staffing pyramid (practitioners at different levels of capability including graduate hire resources), the Engineering maturity model provides teams with a prescriptive model around adoption starting with relatively basic principles like refactoring to adoption of more advanced practices like TDD, BDD etc.  

* Metrics - Based on the level of the maturity of the Agile adoption, Aditi has come up with prescription around metrics the teams could adopt. These are classified into different buckets using the MoSCoW prioritization principles.

* Tooling - Aditi has come up with a well prescribed guideline for Agile teams in the adoption of tools across the lifecycle (Ex: for Collaborative lifecycle management, Continuous Integration, Build management, Code quality management etc) and has come up with bootstrap assets which teams can leverage to run with when they start the transformation.

* Organization readiness - For an organization to embrace Agile, many of the current internal practices (Recruitment, Sales etc) and current infrastructure (Ex: Collaboration platforms, infrastructure) needs to scale up as well. A well defined maturity model towards transformation allows organizations to adopt a more phase wise approach towards these areas of transformation and helps the different business units to also scale up at a sustainable pace.

 
3 favorite thumb_down thumb_up 5 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/structure of the Session

This will be in the form of a presentation of about 10-15 slides. Depending on the time allowed, we might consider a fewer/more number of slides.

Learning Outcome

Adopting a structured gradual approach to the transformation of the different functional and engineering teams at Aditi has helped us demonstrate incremental business value from the transformation at every stage of the adoption and has also been a relatively less risky approach as we have been able to work on the organization readiness in a more gradual manner.

Target Audience

Organizations which are on the Agile transformation journey/planning to start their transformation

schedule Submitted 3 years ago

Comments Subscribe to Comments

comment Comment on this Proposal
  • Ellen Grove
    By Ellen Grove  ~  3 years ago
    reply Reply

    Hi Ravi

    You've categorized this as an experience report (which are usually 20 min long), yet the proposal describes a model with no reference to how it's been applied in practice (sounds like a 45 min theoretical talk)

    What would really interest me would be a 20 min experience report where you spend a bit of time describing the model and more time describing the experiences applying the model (how did it help the team succeed?  which practices were the most challenging).  What do you think?

    Thanks!

    Ellen 

    • Ravi Krishnan
      By Ravi Krishnan  ~  3 years ago
      reply Reply

      Hi Ellen,

      Yes, that is definitely do-able. We have proposed a flexible schedule with respect to the time and can tailor the message accordingly.

      Best Regards,
      Ravi

  • Ram Srinivasan
    By Ram Srinivasan  ~  3 years ago
    reply Reply

    Hi Ravi and Naresh,

    Thanks for submitting a proposal. I have a few questions. 

    1. Why should business people (say CXO) care about a model like this?

    2. L1 - Story card based Why? Is that the only way of gathering agile requirements? 

    3. What are the differences between L1 Agile Planning practices and L2 Strengthened Project Planning and Management? 

    4. Doing as it process right - I am seeing this in L0 and L2 - I am confused. What are you trying to convey? Are there different levels of doing it right? 

    5. What is L3 testing lifecycle ? In frameworks like scrum, you have a shippable increment at the end of the sprint, what exactly are you trying to convey? And by encouraging a formal defect management approach, I contend that you are promoting writing buggy code. If you have good engineering practices like automated testing and CI, why do you need this at L3? 

    6. What is the difference between L1 core engineering practices (which I assume as TDD/ATDD, CI, and all good technical practices) and L2 Automated and Frequent release enabling engineering practices

    7. What are L2 collaboration level practices and L3 collaboration level practices? 

    8. Can you elaborate more on L3 Org level practices?

    9. Also, I may be wrong, but I feel the framework misses the entire point  about Agile values and principles by superficially focuses only on practices and process. Can you help me understand it better? 

    Thanks,
    Ram

    • Ravi Krishnan
      By Ravi Krishnan  ~  3 years ago
      reply Reply

      Ram,


      Thanks for the feedback - responding to the clarifications you have asked for (in a particular order):

      2. L1 - Story card based Why? Is that the only way of gathering agile requirements? 

      Story Card essentially is a metaphor here. We are looking at the teams moving from detailed business requirements or large use cases to working with smaller manageable set of requirements (using INVEST principle on the requirements if you will). The intent is to have the teams start slicing the requirements into smaller verifiable units which can be managed within a sprint.

      3. What are the differences between L1 Agile Planning practices and L2 Strengthened Project Planning and Management? 

      In many distributed engagements involving a client-vendor model, the Agile principles are perhaps best introduced during the Engineering phases. The L1 Agile planning practices focuses more around Release and Sprint planning with the business and in some instances the testing teams still functioning in a serial manner while the Level 2 focuses on extending the principles to an end to end lifecycle including business envisioning and in some instances the testing teams as well.

      4. Doing as it process right - I am seeing this in L0 and L2 - I am confused. What are you trying to convey? Are there different levels of doing it right? 

      You can ignore this - we didnt have any slides handy and we created something in a rush to load to Slideshare.  It didn't come out right. We will make available updated slides for abstract in a day or two.

       

      5. What is L3 testing lifecycle ? In frameworks like scrum, you have a shippable increment at the end of the sprint, what exactly are you trying to convey? And by encouraging a formal defect management approach, I contend that you are promoting writing buggy code. If you have good engineering practices like automated testing and CI, why do you need this at L3? 

      Imagine a project which has been running a while using traditional methods. Such projects typically tend to have very low/non existent level of automation approach within their testing lifecycles over the years. These teams need to be given some time to plan and automate the different formal testing phases. Level 3 essentially is looking at very high coverage across all the different forms of testing phases leading to close to production ready software at the end of every sprint. Teams will not reach this level on day 1 especially when they are transforming. You can maybe think of a an Iteration 0 where the team develops a framework which gets built on incrementally over the subsequent iterations. The emphasis on automation is across all the levels of maturity - in terms of planning and achieving certain levels of coverage and automation across each of the levels.

      6. What is the difference between L1 core engineering practices (which I assume as TDD/ATDD, CI, and all good technical practices) and L2 Automated and Frequent release enabling engineering practices

      Ram, again, you need to look at this from the perspective of many different teams with a legacy of methodologies and techniques from the past that they need to "unlearn". Such teams will struggle to slice a requirement into smaller manageable chunks to begin with. When the teams are faced with such constraints, doing TDD or ATDD is much more than what the teams can chew on on the first day. Level 1 starts with basic engineering principles, initiating the different things you have identified and laying the foundation to aid the transformation. Level 2 focuses on bringing these all together. In Utopia, all these things would happen in the first release. Global delivery teams making a transformation have to unlearn what they have done so far and cannot reach there in the first sprint.

      7. What are L2 collaboration level practices and L3 collaboration level practices? 

      Part of the answer lies here in 3. Difficult to achieve end to end lifecycle Agile adoption for existing projects and a lot of this depends on how you transform the client.

      Likewise, the collaboration practices are also focused within the different phases. What can be easily achieved within the team vs what needs a greater stakeholder transformation.

      Additionally, with distributed teams, its difficult to achieve a true level of collaboration across all the areas. Teams adopt practices like "bridge team" or "bridge hours" with focused collaboration around specific areas. Also, practices like pre sprint planning and the follow up activities help teams reduce the actual level of collaboration required during say a sprint level meeting. Some distributed teams may use roles like a proxy BA who is empowered to help bridge the collaboration constaints. The differences are around these areas.

      8. Can you elaborate more on L3 Org level practices?

      This is not to be misunderstood as something that the Org does only at Level 3. Its an ongoing journey which touches multiple aspects of an organization (read "legacy" organization) across all the levels:

      * Tooling platforms to facilitate a collaborative lifecycle

      * Infrastructre/Floor spaces/Workspaces

      * Functions such as Hiring and People Management (Performance, Appraisals etc)

      * Functions such as Sales etc

      * Role based workshops etc

      List all these down, put them into a prioritized item list and go about catering to them as and when your teams being needing them.

       

      9. Also, I may be wrong, but I feel the framework misses the entire point  about Agile values and principles by superficially focuses only on practices and process. Can you help me understand it better? 

      I would differ on it. If I have to answer this loosely, I would say the emphasis is more on getting the values and principles right up-front and ingraining the practices and processes within in a gradual manner. Its possible that the PPT slide may have given that perception. As I mentioned, that was assembled in a hurried manner to put something on slideshare.

      1. Why should business people (say CXO) care about a model like this?

      Not sure I understood the intent of the question. I think the answer lies in whether you are trying to transform a 10 member team vs a transformation of a xxxx member organization spanning multiple project teams, technology sets, multiple cultural mindsets etc. If its the latter, the adoption needs to be more structured and phased out vs doing a big bang approach on a single team working on a new project.

      Relatively less risky and the teams demonstrate added business value at each of the phases of transformation. And it also gives you the ability to learn from your experiences and plug it back into the overall framework for future projects.

       

      HTH,

      Regards,
      Ravi

       

    • Ravi Krishnan
      By Ravi Krishnan  ~  3 years ago
      reply Reply

      Ram,


      Thanks for the feedback - responding to the clarifications you have asked for (in a particular order):

      2. L1 - Story card based Why? Is that the only way of gathering agile requirements? 

      Story Card essentially is a metaphor here. We are looking at the teams moving from detailed business requirements or large use cases to working with smaller manageable set of requirements (using INVEST principle on the requirements if you will). The intent is to have the teams start slicing the requirements into smaller verifiable units which can be managed within a sprint.

      3. What are the differences between L1 Agile Planning practices and L2 Strengthened Project Planning and Management? 

      In many distributed engagements involving a client-vendor model, the Agile principles are perhaps best introduced during the Engineering phases. The L1 Agile planning practices focuses more around Release and Sprint planning with the business and in some instances the testing teams still functioning in a serial manner while the Level 2 focuses on extending the principles to an end to end lifecycle including business envisioning and in some instances the testing teams as well.

      4. Doing as it process right - I am seeing this in L0 and L2 - I am confused. What are you trying to convey? Are there different levels of doing it right? 

      You can ignore this - we didnt have any slides handy and we created something in a rush to load to Slideshare.  It didn't come out right. We will make available updated slides for abstract in a day or two.

       

      5. What is L3 testing lifecycle ? In frameworks like scrum, you have a shippable increment at the end of the sprint, what exactly are you trying to convey? And by encouraging a formal defect management approach, I contend that you are promoting writing buggy code. If you have good engineering practices like automated testing and CI, why do you need this at L3? 

      Imagine a project which has been running a while using traditional methods. Such projects typically tend to have very low/non existent level of automation approach within their testing lifecycles over the years. These teams need to be given some time to plan and automate the different formal testing phases. Level 3 essentially is looking at very high coverage across all the different forms of testing phases leading to close to production ready software at the end of every sprint. Teams will not reach this level on day 1 especially when they are transforming. You can maybe think of a an Iteration 0 where the team develops a framework which gets built on incrementally over the subsequent iterations. The emphasis on automation is across all the levels of maturity - in terms of planning and achieving certain levels of coverage and automation across each of the levels.

      6. What is the difference between L1 core engineering practices (which I assume as TDD/ATDD, CI, and all good technical practices) and L2 Automated and Frequent release enabling engineering practices

      Ram, again, you need to look at this from the perspective of many different teams with a legacy of methodologies and techniques from the past that they need to "unlearn". Such teams will struggle to slice a requirement into smaller manageable chunks to begin with. When the teams are faced with such constraints, doing TDD or ATDD is much more than what the teams can chew on on the first day. Level 1 starts with basic engineering principles, initiating the different things you have identified and laying the foundation to aid the transformation. Level 2 focuses on bringing these all together. In Utopia, all these things would happen in the first release. Global delivery teams making a transformation have to unlearn what they have done so far and cannot reach there in the first sprint.

      7. What are L2 collaboration level practices and L3 collaboration level practices? 

      Part of the answer lies here in 3. Difficult to achieve end to end lifecycle Agile adoption for existing projects and a lot of this depends on how you transform the client.

      Likewise, the collaboration practices are also focused within the different phases. What can be easily achieved within the team vs what needs a greater stakeholder transformation.

      Additionally, with distributed teams, its difficult to achieve a true level of collaboration across all the areas. Teams adopt practices like "bridge team" or "bridge hours" with focused collaboration around specific areas. Also, practices like pre sprint planning and the follow up activities help teams reduce the actual level of collaboration required during say a sprint level meeting. Some distributed teams may use roles like a proxy BA who is empowered to help bridge the collaboration constaints. The differences are around these areas.

      8. Can you elaborate more on L3 Org level practices?

      This is not to be misunderstood as something that the Org does only at Level 3. Its an ongoing journey which touches multiple aspects of an organization (read "legacy" organization) across all the levels:

      * Tooling platforms to facilitate a collaborative lifecycle

      * Infrastructre/Floor spaces/Workspaces

      * Functions such as Hiring and People Management (Performance, Appraisals etc)

      * Functions such as Sales etc

      * Role based workshops etc

      List all these down, put them into a prioritized item list and go about catering to them as and when your teams being needing them.

       

      9. Also, I may be wrong, but I feel the framework misses the entire point  about Agile values and principles by superficially focuses only on practices and process. Can you help me understand it better? 

      I would differ on it. If I have to answer this loosely, I would say the emphasis is more on getting the values and principles right up-front and ingraining the practices and processes within in a gradual manner. Its possible that the PPT slide may have given that perception. As I mentioned, that was assembled in a hurried manner to put something on slideshare.

      1. Why should business people (say CXO) care about a model like this?

      Not sure I understood the intent of the question. I think the answer lies in whether you are trying to transform a 10 member team vs a transformation of a xxxx member organization spanning multiple project teams, technology sets, multiple cultural mindsets etc. If its the latter, the adoption needs to be more structured and phased out vs doing a big bang approach on a single team working on a new project.

      Relatively less risky and the teams demonstrate added business value at each of the phases of transformation. And it also gives you the ability to learn from your experiences and plug it back into the overall framework for future projects.

       

      HTH,

      Regards,
      Ravi

       


  • Naresh Jain
    Naresh Jain
    Founder
    ConfEngine.com
    schedule 3 years ago
    Sold Out!
    45 mins
    Workshop
    Advanced

    As the popularity of Agile methods have grown, so have the misconceptions or myths associated with Agile also grown. These myths get even more glorified when we talk about them in the offshore or distributed context. And to make matters worse, you can throw in a fixed-price contract spanner into the engine.

    Worry not! In this fun-filled activity, we'll collect facts from the participants that they believe are true and then we'll declare them as confirmed or busted after an interactive (heated) discussion.

  • Corey Haines
    Corey Haines
    CTO
    Wavetable
    schedule 3 years ago
    Sold Out!
    45 mins
    Tutorial
    Beginner

    Everyone has acronyms, mnemonics, and a list of rules to guide their everyday software design. In order to get the most out of these age-old gems, one needs to deliberately practices them. Rules are a good way to remind ourselves of these gems.

    Corey Haines emphasies his design guidelines in form of the "4 Rules of Simple Design." Attend this talk to understand the four rules and their importance in everyday programming.

  • Liked Corey Haines
    keyboard_arrow_down

    Corey Haines - Stories from 10 Years of Extreme Programming

    Corey Haines
    Corey Haines
    CTO
    Wavetable
    schedule 3 years ago
    Sold Out!
    45 mins
    Talk
    Intermediate

    10 years ago I was introduced to Extreme Programming. Since then, I've been an avid practitioner, applying the techniques and values to my life as a software developer. Over that time, I've bounced between many extremes, learning and reflecting on the value that I get when building systems both for myself and for others.

    In this talk, I'll share some of those learnings and how my life as a software developer has changed with the times.

  • Liked Mukesh Bhangria
    keyboard_arrow_down

    Mukesh Bhangria - Continuous Refactoring at Amazon: A Case Study

    45 mins
    Talk
    Beginner

    Between the project deadlines, we always feel there is code which needs to be improved

    Usually Developers have the following 3 options:

    - Bite the bullet and do the refactoring as they go along.
    - Park the issue and address it later.
    - Allocate special time when the project gets out-of-control.

    As customer facing stories take higher priority, usually Developers are forced to choose the last option.

    However a team at Amazon took a different approach. Attend this session to listen to their first-hand story of how they changed this typical behavior to achieve Continuous Deployment on a critical service.

  • Liked Victoria Schiffer
    keyboard_arrow_down

    Victoria Schiffer - Agile Coaching? Sure thing! What about Life Coaching in Agile Thinking?

    Victoria Schiffer
    Victoria Schiffer
    Agile Coach
    SEEK
    schedule 3 years ago
    Sold Out!
    45 mins
    Talk
    Beginner

    I love being around awesome people, who build great products customers desire. 
    I love learning from and together with these amazing minds. 
    I love creating the right environment for teams to flourish. 
    I love change, and learning from new experiences. 
    I love working in Agile environments.

    How about you? 
    I bet there are some elements of this list why you're in Agile, too. And you can probably add even more elements to it.

    The Agile Manifesto states amongst others individuals and interactions, customer collaboration and responding to change.

    In our everyday life doing Agile we already respect these aspects in many ways. 
    But do we practice what we preach as best we can?

    I'd like to challenge your current way of thinking about people and processes. 
    I'd like to challenge you to focus on you, before you focus on others. 
    I'd like to challenge your current way of reflecting. 
    I'd like to inspire you to go different ways. 
    I'd like to inspire you to inspire others.

    In Agile we're already good in improving our processes and creating well performing teams and hence building the right things in the right way. And in the Agile Manifesto's communication and collaboration piece we can even get better.
    "You have not yet reached the limit of what you're capable of!" means we can always further improve. And we do follow this idea in our Agile processes, too, through continuous feedback (Retrospectives) and improvement.

    And why not take it even further? Why not go "Beyond Agile"?!

    Here's where aspects of Life Coaching come in handy: through also understanding and improving ourselves (how do we interact with people due to how we perceive our environment) we will even further improve communication and collaboration.

    Life Coaches believe our clients know the answer. And even if Agile Coaching is slightly different than Life Coaching, I see it as very relevant in Agile Coaching, too. If we apply this in Agile, instead of giving our clients (team, colleagues) the answers, asking them powerful questions to help them be more aware of what's happening at the moment, they will find their answer for it and will have a much better commitment to making the change for themselves, their teams and the company. It's not for us to TELL them what to do, but to ASK them what's going on for themselves. Here's where I see a huge chance for improvement.

    In my session I give lots of examples on how to link Life Coaching ideas to our Agile work environments. I've given the session at LAST Conference Melbourne and at the Agile Coaching Circles Meetup Melbourne. The audience was engaged and the attendees were very happy about having some new ideas on how to improve their daily work life.

    Come along to be inspired by Life Coaching and thus to benefit our Agile Thinking!

  • Liked Naresh Jain
    keyboard_arrow_down

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

    Naresh Jain
    Naresh Jain
    Founder
    ConfEngine.com
    schedule 4 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 Daniel Zen
    keyboard_arrow_down

    Daniel Zen - Agile Engineering Javascript with Jasmine & AngularJS, Karma & Jenkins

    Daniel Zen
    Daniel Zen
    CEO
    Zen Digital
    schedule 4 years ago
    Sold Out!
    90 mins
    Tutorial
    Intermediate

    Agile & Test Driven Development of frontend JavaScript User Interface code is often passed over using the excuse that the UI code is "declarative" (What you see is what you get) and therefore does not 'need' to be tested. Others, will dismiss testing frontend AJAX code as too difficult to maintain or unnecessary because it is only important in context with the server. We will show how these misconceptions are false. 

    We will cover several popular JavaScript tools and technologies that make Agile frontend web development easy. We will show how these front end technologies cannot only be functionally tested, but Unit Tested. If time is available will cover Continuous Integration, Dependency Injection, & Mock objects.  

    By including your front-end code in your automated testing process you can prevent the inclusion of bugs that are usually only caught with manual testing.

  • Naresh Jain
    Naresh Jain
    Founder
    ConfEngine.com
    schedule 4 years ago
    Sold Out!
    45 mins
    Demonstration
    Intermediate

    "Release Early, Release Often" is a proven mantra and many companies have taken this one step further by releasing products to real users with every commit a.k.a Continuous Deployment (CD).

    Over the years, I've built many web/infrastructure products, where we've effectively practiced CD. However at Edventure Labs, when we started building iPad games, we realized there was no easy was to practice CD, esp. given the fact that Apple review takes a few days.

    Our main question was: As mobile app developers, how should we architect/design our apps for CD?

    We were a young startup, learning new behavior about our users (kids aged 5-8) everyday. We could not afford any delay in releasing latest, greatest features to our users. To solve this problem, I believe we've built an innovative solution to enable any mobile app developer to achieve CD.

    If you are building real products, which have platform/3rd-party dependencies and you want to practice CD, this session is for you.

  • 45 mins
    Experience Report
    Intermediate

    Agile processes are the new order of IT implementations. These talk will elaborate on our experience and learnings during agile process implementation at Walmart. 

    We will touchupon following 3 key areas and our learnings that helped us scale agile in large enterprises.

    • Process Visualization - Our learnings related to visualization of existing processes and practices and how it helped us identify signals from noise

    • Product Backlog Elaboration - In a complex and large programs product backlog management and role of product owner needs to be revisited.

    • Team Working Agreement - This is particulary crucial for scaling agile as dependency management is one of the key aspects of enterpsie agile implementation.

    We will conclude with our key learning of how processes needs to be continuously evolved in large scale implementation.

  • 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 4 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 Sreerupa Sen
    keyboard_arrow_down

    Sreerupa Sen - Changing our Rhythm: Our Ongoing Journey towards Continuous Delivery

    Sreerupa Sen
    Sreerupa Sen
    Architect/Developer
    IBM
    schedule 3 years ago
    Sold Out!
    20 mins
    Experience Report
    Beginner

    Annual software release cycles cramping the agility of the team? Too many hot fixes reducing the efficiency of your organization? Customers waiting impatientlyfor  the next cool features hot off the press? These are some of the painful and common problems faced by development teams worldwide. In today's world, most things get outdated or out-of-fashion very fast - and software is no different. Users cannot afford to wait for the next cool set of features for a year. They want a steady stream of cool new features that they can adopt and use immediately.

    My team follows a development model that we like to call Open Commercial Development - where we're always connected to our stakeholders, our plans are out in the open, and we're always gathering feedback and reprioritizing. We used to have yearly releases of our product - a sort of big bang release with a host of new featres. Based on our stakeholder interactions, however, we figured that our software delivery wasn't agile enough for our customers. Users wanted new features incrementally throughout the year. They especially didn't want to wait a year for a feature that they'd requested that was critical for their business.

    So began our journey to Continuous Delivery - an interesting one for sure. It's not easy to deliver new features, manage technical debt, collaborate with users and incorporate their feedback into the new features - once every quarter. To do it consistently, with quality and on time, you need to have a framework in place - a combination of planning, process, automation and team organization - that lets teams focus on the right things to get to DONE DONE for their new features, and at the same time manage their quality and tecnical debt. Over the past year, we like to think that we've put that framework in place, and that is what I'd like to talk about in this session.

  • Liked Phil Abernathy
    keyboard_arrow_down

    Phil Abernathy - The Sixth Force

    45 mins
    Talk
    Intermediate

    Over the last 2 years, in small pockets all over the world, people have been experimenting with the use of Agile and Lean in formulating and executing corporate strategy.

    The finding will astound you and lay the foundations for what may become the next wave of ‘Agilean’ transformations, thus paving the way for vertically transformed ‘Agilean’ organisations that deliver outstanding profitability.

    The ‘Lean Startup’ mentality or ‘Management 3.0’ are tips of the iceberg in recent strategic thinking.

    This talk draws on experience and real life examples to outline how Agile and Lean, and not just Porter’s 5 forces, can be used effectively to not only formulate and execute corporate strategy but also to enable transformation throughout the organisation.

  • 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 Andrea Heck
    keyboard_arrow_down

    Andrea Heck - Distributed Product Owner Team for an Agile Medical Development

    Andrea Heck
    Andrea Heck
    Agile Coach
    Siemens AG Healthcare
    schedule 4 years ago
    Sold Out!
    45 mins
    Case Study
    Advanced

    We are developing medical imaging and workflow software in an agile way with development teams distributed to several countries. One of the major challenges is how to set up and communicate within the Product Owner team. There we have to deal with the distribution, e.g., have the Product Owner either onsite with her peers or with her Scrum team, travelling, or with proxy. We need people who are good in two different fields of knowledge: medical and software development. As a third issues, the environment of the customers may be different in different countries.

    We have ramped up local Product Owners in different countries, have found local collaboration customers, and have developed a set of communication channels and workshops how to synchronize Product Owners in the team, share a common vision and backlog with their Scrum teams, and collaborate with customers locally and globally.

  • Liked Prasanna Vaste
    keyboard_arrow_down

    Prasanna Vaste - Should we stop using Story Points and Velocity?

    Prasanna Vaste
    Prasanna Vaste
    Business Analyst
    Thoughtworks
    schedule 4 years ago
    Sold Out!
    20 mins
    Experience Report
    Beginner

    On Agile projects we estimate user stories in order to allow team to

    1. 1. Track velocity
    2. 2. Decide scope for the Iteration
    3. 3. Help Prioritize stories
    4. 4. Help Release planning

    But most of the time we faced issues with estimation. It takes lot of time in estimating user stories, managers tend to relate estimate to number of days it will take to complete the story, in some teams estimate is equal to deadline. Most of the teams which use story points to estimate the work face these issues. This results in lack of confidence on development team when stories are taking more time to complete.

    Here I am going to talk about better alternative for both the suppliers of software products (financially and ethically) and their customers (internal and external). This alternative is being used in real companies delivering to real customers with great effect where team uses count of stories completed in an Iteration as measure of progress. Will talk about how this alternative can be used to track velocity, prioritize stories, planning Iteration and for release planning.

    I will share some exmples from my past projects where team did not use story points/velocty but used count of stories completed in Iteration to measure progress and also as best indicator of future performance.

  • Liked Roy Nuriel
    keyboard_arrow_down

    Roy Nuriel - The Quality Assurance Journey - From Waterfall to Continuous Delivery

    45 mins
    Case Study
    Intermediate

    In the past several years we have seen more and more organization taking the decision and moving their development divisions to adopt Agile methodology. In most cases the change starts with a POC of a new and – in most cases – small project that validates the ability of the organization to make the shift to Agile. In many cases the development team takes the lead: changing the process, moving to unified teams, selecting which Agile practice to adopt, etc.

    In this session I will share how we made the shift, while focusing on the change in our quality process.

    As an R&D group that develops an Agile solution (HP Agile Manager), we wanted to get it right. We changed the way in which we develop software from waterfall to Agile, and built a process to support the teams in a complex and large enterprise. While previously we were accustomed to delivering releases in 1-2 year cycles, we now operate within a SaaS model where we update our production environment on a weekly basis. 

    We have experimented with the same process that our customers are going through and, as a result, we adapted the way our QA engineers work. In accordance with their new role, we gave them a new title – Dev Testers.

    Here are some of the dilemmas we faced:

    -          What are the differences between "Dev Tester" and "QA Engineer"?

    -          How can we measure quality in 2-week sprints?

    -          What needs to change when testing a SaaS solution that is delivered on a weekly basis?

    -          When and how should load testing be performed?

    -          Automated v. manual testing

    -          What testing should be part of the CI process?

    -          How do offshore Dev Testers take part in our Agile practices (e.g. daily meetings)?

    We dealt with all of these questions, and I would like to share the lessons we learned, our conclusions, and some of the challenges that we still face.

  • Martin Fowler
    Martin Fowler
    Chief Scientist
    ThoughtWorks
    schedule 3 years ago
    Sold Out!
    60 mins
    Keynote
    Intermediate

    In the last decade or so we've seen a number of new ideas added to the mix to help us effectively design our software. Patterns help us capture the solutions and rationale for using them. Refactoring allows us to alter the design of a system after the code is written. Agile methods, in particular Extreme Programming, give us a highly iterative and evolutionary approach which is particularly well suited to changing requirements and environments. Martin Fowler has been a leading voice in these techniques and will give a suite of short talks featuring various aspects about his recent thinking about how these and other developments affect our software development.

  • Liked Rae Abileah
    keyboard_arrow_down

    Rae Abileah - Engendering Justice: Women, War and Peace

    45 mins
    Keynote
    Beginner

    One in three women will be raped or beaten in her lifetime. Half of the seven billion global population are women so that means one billion women alive now will, or have been, beaten or raped or beaten. Women and children are disproportionately affected by war and occupation as well. And yet numerous studies illustrate how uplifting women's work and leadership can strengthen the whole society and economy. Women are at the forefront of global campaigns challenging militarism and violence, and working to redirect resources into health care, education, green jobs and other life-affirming activities. What can we learn from these women and their successes thus far? How can the technology sector support this crucial work? How do these social movements stay agile to rapidly respond to breaking news while building a long-term progressive movements for deeper social, economic and environmental justice? As Arundhati Roy said, "Another world is not only possible, she is on her way. On a quiet day, I can hear her breathing." In this talk, Rae Abileah will share visionary examples of women-led work for peace and justice and explore the paradigm shift needed for equality, human rights, and justice for all.

  • Liked Todd Little
    keyboard_arrow_down

    Todd Little - Leveraging Global Talent for Effective Agility

    Todd Little
    Todd Little
    Executive Consultant
    Accelinnova
    schedule 3 years ago
    Sold Out!
    60 mins
    Keynote
    Intermediate

    A major challenge in agile development is the ability of test teams to keep pace with ongoing development while simultaneously ensuring that new development has not created regression failures. This case study from Halliburton shows how together with two globally distributed outsourcing partners they developed a comprehensive test automation strategy for their agile teams that effectively leveraged both in house and outsourced activities. This approach resulted in a significant quality improvement from prior releases.