Changing our Rhythm: Our Ongoing Journey towards Continuous Delivery

schedule Feb 28th 01:55 PM - Jan 1st 12:00 AM place Esquire

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.

 
12 favorite thumb_down thumb_up 32 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/structure of the Session

- Introduction: The product we build and the distributed team we have

- The goals for continuous delivery

- Our development process

- Automation

- Our Release Process

Learning Outcome

Agile newbies will get some ideas around moving to continuous delivery,practising agile methodologies. Agile practitioners would benefir from the best practices we follow to ensure a continuous delivery with quality.

Target Audience

Agile implementors, people wanting to move to agile development

schedule Submitted 4 years ago

Comments Subscribe to Comments

comment Comment on this Proposal
  • Joel Tosi
    By Joel Tosi  ~  4 years ago
    reply Reply

    Hi Sreerupa,

       Congrats on having your presentation accepted.  How can I best serve you with your presentation?  Is there anything I can help you review or walk through with you?  Please let me know.

     

    Best,

    Tosi

    • Sreerupa Sen
      By Sreerupa Sen  ~  4 years ago
      reply Reply

      Hi Tosi,

          Thanks for reaching out. I don't have a draft ready yet for the experience report, but I'm hoping to have that by the end of the month. I'll share it with you - it'd be great if you give me some feedback.

      Cheers

      --Rupa

      • Joel Tosi
        By Joel Tosi  ~  4 years ago
        reply Reply

        Great, looking forward to it.

         

        Best,

        Joel

        • Sreerupa Sen
          By Sreerupa Sen  ~  4 years ago
          reply Reply

          Hi Joel,

              I have the first draft of the report ready - it's somewhat long though, about 7 pages long in MS word, 10 pts. I will get it blessed by IBM and then share it with you by early next week. I had a couple of questions: what format do you want the report in, and how long is it expected to be typically?

          Cheers

          --Rupa

          • Joel Tosi
            By Joel Tosi  ~  4 years ago
            reply Reply

            Hi Rupa,

               I would be more than happy to review it in whatever format you have - pdf, word, powerpoint, etc.  Whatever is easiest for you.

            You will be presenting your report, no?  I believe it is a 20 minute presentation.  So I would be less concerned with the overall length of the written report (less is usually better) - so much as the write-up has the highest value and is consumable.  Once we get your report, we can work maybe over skype on the presentation of it?  What would help you most?

             

            Best,

            Joel

            • Sreerupa Sen
              By Sreerupa Sen  ~  4 years ago
              reply Reply

              Here goes: https://docs.google.com/document/d/1GGmNZAW4Fr_bRh_xjAq2G4ewIkJaPvfsc4Mb2NWULl4/

              You should have access, please let me know if you have trouble getting to it.

              Cheers

              --Rupa

  • Sachin goel
    By Sachin goel  ~  4 years ago
    reply Reply

    Hi Sreerupa,

    Can you pls share your presentation maetrial or any reference to you taking this session in earlier conferences or any other audio / video reference of your participation in other conferences?

    Thanks
    Sachin

    • Sreerupa Sen
      By Sreerupa Sen  ~  4 years ago
      reply Reply

      Hi Sachin,

          http://www-01.ibm.com/software/rational/innovate/ has the presentations but only for registered attendees. In the Innovate one I did talk about RTC though, and even if you do get access to it, it won't be the same as the one I'm planning on presenting here - I don't have a ready-made one that I present in all conferences - it's usually tailored carefully to suit the audience. I don't have any recordings of sessions at other conferences - I've done presentations on agile within the last 12 months,   at Techgig, Silicon India, customer conferences - don't know if there are any recordings anywhere.

          I'm not comfortable sharing my presentation material before the presentation gets accepted - that seems to me to be an unusual request? Is that the usual selection procedure for this conference? Typically an abstract is what's needed.

          I'll need a clearance from IBM communications anyway in the event it does get accepted.

      Cheers

      --Rupa

      • Sachin goel
        By Sachin goel  ~  4 years ago
        reply Reply

        Thanks Rupa - as  part of review process we do seek inputs on  ppt and previous delivery. But thats not a mandatory step to say. More information you can provide it helps the review team to evaluate the proposal against others. 

        • Sreerupa Sen
          By Sreerupa Sen  ~  4 years ago
          reply Reply

          Okay thanks for the clarification.

          I'm not sure if you're looking at the credentials of the speaker or subject matter expertise? I've been practising agile and talking about it at conferences for the last 5 years. I've spoken at IBM conferences, customer conferences, conferences like the one hosted by Silicon India. I've also done webinars, internal and external like the Techgig one.

          Not sure that helps any, one way or the other :-)!

          Cheers

          --Rupa

           

           

          • Naresh Jain
            By Naresh Jain  ~  4 years ago
            reply Reply

            Dear Sreerupa,

            I like your topic and would like to accept it as part of the conference. However we really need to see a quick video of you presenting any topic. It can be a simple video recorded using a smart phone. Sharing your slides will be an added advantage. Hope you understand and respect our selection process.

            Thanks
            Naresh Jain

            • Sreerupa Sen
              By Sreerupa Sen  ~  4 years ago
              reply Reply

              Hi Naresh,

                  The audio files that may be available are from IBM conferences and I can't share them without legal approval. I don't think I have any video clips. Here's a youtube video (doesn't show me speaking but you can hear me) I'd done a year ago on one of our product features - https://www.youtube.com/watch?v=0f8LrTeENSw. Would this work? Otherwise I can ask for legal approval but that's going to take time.

                  Also, I don't have any ready made slides for this session, I have attached a few slides from a related session I'd presented at an IBM conference earlier this year.  Here's an overview of what I plan on presenting:

              I’m going to talk about the fundamentals of agile development and how it led to continuous delivery for us; what we needed to take care of, as team leads or team members, in agile development and continuous delivery: how we plan, how we track, what we automate, how we share information across distributed teams; how we organize our teams; how we involve stakeholders; how we set and meet quality guidelines in continuous delivery; what type of tooling makes it easier; what we mean by DONE DONE; how continuous delivery can mean different depending on what kind of software you build, what kind of release mechanisms you have and so on.

              Cheers

              --Rupa

              • Sreerupa Sen
                By Sreerupa Sen  ~  4 years ago
                reply Reply

                Hi again,

                   How do you attach files here?

                Cheers

                --Rupa

                Material from slides I was planning to add, they're not in any particular order though and the last few I've just mentioned the topic headers. If you need the full presentation, I'll have to create it, get IBM media/legal division to clear it and so on. I'm hoping this will help you make up yur collective minds one way or the other. I do understand and appreciate your selection process, and I'm hoping you'll understand the restrictions I have as well.

                 

                Why did we need continuous delivery?

                ----------------------------------------------

                §Annual release cycle causes unbearable pain
                – a year or more to delivery of customer requests
                –endless renegotiation of release content
                –unfinished work, broken flows
                –wasted efforts
                –worn down development and test teams since the last agreed upon release content is late
                §Customers have a hard time understanding what comes and what doesn’t

                 

                §Milestone builds received feedback but not to the amount we need: too much work for customers for non-production use
                 
                What were our goals?
                -------------------------
                §Ship the product
                –Defect fixes, customer pain points, technical debt, usability improvements…
                §Ship customer value
                –Cool new features, enhancement requests, differentiators…
                 
                Our prioritized Product Backlog
                ------------------------------------
                §No more than 8 weeks of work when in the clarity section.
                §One concrete issue or a theme of related issues.
                §Broken down into stories for execution
                §We call them Plan Items.
                §Items in the Clarity section are ready to be worked on.
                §Plan item moves to the release plan only when staffed and execution starts.
                §Enhancement Requests make it to the PPB through their linked plan item.
                §If not linked, they are in the  “No Understanding” section.
                 
                Organizing our teams: run teams and feature teams
                -------------------------------------------------------------
                 
                How did we know when we were done
                --------------------------------------------
                 
                ...
                 
                 
                • Pramod Sadalage
                  By Pramod Sadalage  ~  4 years ago
                  reply Reply

                  Sreerupa,

                   

                  You upload the file somewhere else. Dropbox, youtube etc and provide a link here. Best is to update you proposal with the link.

                   

                  Pramod

                  • Sreerupa Sen
                    By Sreerupa Sen  ~  4 years ago
                    reply Reply

                    Hi Pramod,

                        Both would be public URLs and I would once again need IBM to clear it for me. I'm not sure what other folks are doing - surely most companies would have some confidentiality restrictions that would need clearances, if Agile India organizers need presentation uploads before the selecton is made?

                        I guess under the circumstances, the link/slide information I've provided is the best I can do. I would have loved to speak at Agile India - some of the speakers listed seem to have ivery nteresting topics. And in my rather biased opinion, my topic/session would have been of interest too to agile developers. However, if your selection criterion is more stringent than most, I totally understand that.

                     

                    Cheers

                    --Rupa

                    • Naresh Jain
                      By Naresh Jain  ~  4 years ago
                      reply Reply

                      Rupa, would you be willing to convert this into a 20 mins experience report? In that case we won't insist on the slides and video. However for 20 mins experience report, you will be required to write a 2-3 page experience report sharing your learnings. This report will be need to be public. And the report is due by Nov 15th.

                      If yes, then please update the proposal to reflect the same.

                      • Sreerupa Sen
                        By Sreerupa Sen  ~  4 years ago
                        reply Reply

                        Yes I would be interested, thanks Naresh. 20 minutes is a bit short, but I really like the idea of publishing the experience report sharing our learnings. I have updated the proposal.

                        Cheers

                        --Rupa

          • Sachin goel
            By Sachin goel  ~  4 years ago
            reply Reply

            It was both : speaker as well as proposal - part of reviewer's job:)

            thanks a ton anyways.

  • steve ropa
    By steve ropa  ~  4 years ago
    reply Reply

    Hi Sreerupa,

    I really like the idea of your experience report.  I wonder if, in order to bring more people in, it might be worth taking out the reference to RTC.  You are rightfully proud of your product, but there is a hesitation that people might think you are trying to sell RTC.  I don't believe you are, and would love for people to want to come to a talk like this with no preconcieved notions.

     

    Just a thought,

    Steve

    • Sreerupa Sen
      By Sreerupa Sen  ~  4 years ago
      reply Reply

      Hi Steve,

          Thanks for the suggestion. I totally agree that it should not be an RTC session :-). However, RTC is also the product we develop - so as a part of my experience report, I'd like to talk about the team, it's distributed nature, how we oriented ourselves for CD (we used to follow 'Architecture follows Organization' and people in one geography focused on one or more specific components, now it's much more distributed ) and so on. Also, typically, in other sessions where I've talked where we had the same philosophy of not touting your own product, I'v shown sceen shots (often without a product name) to demonstrate what I'm talking about - for example a development process or team structure, a plan snippet and so on. 

          So I'll consciously not talk about RTC as a product - I have a whole lot to talk about anyway just from a CD perspective. But I've found that leaving screenshots out completely, sort of kills the experience part of the experience report.

          Your thoughts?

      Cheers

      --Rupa

  • Sonik Chopra
    By Sonik Chopra  ~  4 years ago
    reply Reply

    Hi Sreerupa

    Are you planning to cover any tools along with this presentation?

    • Sreerupa Sen
      By Sreerupa Sen  ~  4 years ago
      reply Reply

      I'm not planning to cover the features of any tool. But I will talk about how Rational Team Concert helped in certain aspects of continuous delivery - that's the tool we've used. The focus though will be more on what we did for continuous delivery - the tool will be more of an example.

      Some conferences I've spoken at have restrictions on talking about tools - is this one of them?

      Cheers

      --Rupa

      • Sonik Chopra
        By Sonik Chopra  ~  4 years ago
        reply Reply

        Hi Sreerupa,

        How will you relate RTC to continuous delivery? ANd my main questions towards tool is to ensure that you are covering the methodologies used to achieve CD. 

        • Sreerupa Sen
          By Sreerupa Sen  ~  4 years ago
          reply Reply

          Sonik,

              I've talked about agile and continuous delivery quite extensively, within IBM and to customers, with and without RTC. I'm not sure I understand the question 'How will you relate RTC to CD'. RTC is a team collaboration tool with agile planning, dynamic process and automation built in, apart from change and configuration management. So when I talk about my experiences with CD, I could talk about how we did it in my team using the tool. But the focus of the discussion isn't the tool, it's the how's and why's of CD. 

              Does that answer your question?

          Cheers

          --Rupa

          • Sonik Chopra
            By Sonik Chopra  ~  4 years ago
            reply Reply

            Thanks for your update Sreerupa. 

            When we talk about CD, then it also means that there are some processes and tools in place to ensure that we are delivering fast to our customers. I understand that your implementation is not true CD as you were delivering around once a quarter or so. So my main question is towards the tools/processes(e.g. Build pipelines, nexus, Continuous deployment tools etc) you adapted to ensure that you are delivering fast to the customers. Hope that helps now. 

             

            • Sreerupa Sen
              By Sreerupa Sen  ~  4 years ago
              reply Reply

              Thanks. The tool we use (self-host on) and develop, Rational Team Concert, actually has an in-built dynamic process (out of the box Scrum, Lean, OpenUp, or customizable), build pipeline, agile planning (scrum, kan-ban, Lean - out of the box or customizable), deployment on the cloud and automated testing. So all of these are concepts we've embraced for continuous delivery, and I plan to talk about all of this. We have continuous integration and deployment (daily, sometimes more than once a day). Delivery to customers though follows a 3 month schedule - to add non-trivial and meaningful features to agile planning or soure control or the oher capabilities we have in our product, that's how long we take at the moment. Maybe it'll improve with practice, but I don't see it becoming a weekly or a twice-a-week delivery in the foreseeable future. IMO that's just the nature of the software-tools-for-developers domain - it's not so much instant gratification as some of the other domains. We have customers using the same RTC doing a CD in much shorter cycles because of the nature of their business domains. So what we practice can be applied to CD with much shorter turnaround time, it's just that we have 3-month cycles.

              And I'm not sure what you mean when you say we don't practice true CD? Do you mean only interms of the shortness of delivery?

               

              In casse you are interested, we have a series of blog posts on CD at https://jazz.net/.

               

              Cheers

              --Rupa

              • Sonik Chopra
                By Sonik Chopra  ~  4 years ago
                reply Reply

                Thanks for detailed description. It really helps...

                • Sreerupa Sen
                  By Sreerupa Sen  ~  4 years ago
                  reply Reply

                  Sure!

                  Cheers

                  --Rupa

  • Sachin goel
    By Sachin goel  ~  4 years ago
    reply Reply

    Hi

    thanks for your submission. Can you pls clarify if you see Continuous Delivery and Agile through same lense? If they are same, what are the key learnings from this session? If not, how do you differentiate?

    thanks - sachin

    • Sreerupa Sen
      By Sreerupa Sen  ~  4 years ago
      reply Reply

      Agile is a methodology. For continuous delivery we follow a set of agile practices that help in delivering quality releases throughout the year.  In our team, continuous delivery goes somewhat beyond agile practices - we needed a change in team organization and culture for example, to move to continuous delivery, although we'd been following the agile methodology for several years already when we took the continuous delivery plunge. So this talk is not just about the tools and practices, it's also about how one orients oneself for continuous delivery for a complex product, that's not just web-based, not free, and not open source, and consequently has higher quality and feature expectations from it's user base.

      Cheers

      --Rupa

  • Joel Tosi
    By Joel Tosi  ~  4 years ago
    reply Reply

    Hi Sreerupa,

      Thanks for the submission.  Could you help me understand how releases once quarterly is continuous?  I completely agree you are doing better, I am just missing the connect between what you are doing and continuous delivery.  Perhaps if you expanded your release process and automation more that would help me connect the dots.

     

    Thanks much,

    Joel

    • Sreerupa Sen
      By Sreerupa Sen  ~  4 years ago
      reply Reply

      Yeah you're right, releasing every quarter isn't truly continuous, but for a product that's not just hosted, that spans several technologies (in web, rich clients and server side), databases, operating systems, delivering non-trivial features that would make a difference to customers, this is the best we've been able to do so far. RTC spans change management, configuration management, agile planning and automation, our customer base is wide and diverse - from embedded to enterprise. So we're proud of the fact that from having 8 milestones to a release we now have 2, and we do continuously deliver features that deliver customer value, whether it's to app developers or for regulated environments. 

      I guess every successful project that follows agile today has continuous integration in terms of automated builds, hosted deployment and test beds. In this session, I'll talk about those. I'll also talk about the development process that we follow, the team organization changes that we implemented for continuous delivery, the sprint planning and release planning, working on technical debt and new features at the same time.

      Could we do better than releasing once a quarter? Possibly yes. Would it make sense in non-hosted deployments to release every couple of weeks? would customers adopt that culture? how would we make moving from one release to another so smooth that it's completely transparent to users? - these are some of the questions we're asking ourselves.

      Reading my response, I'm not sure I really answered your question. I guess what I was trying to point out is that continuous delivery goes beyong agile practices, automation and release - there are a lot of behavioral and cultural aspects to it to make it work successfullly in a complex product.

       

      Cheers

      --Rupa


  • Liked Giovanni Asproni
    keyboard_arrow_down

    Giovanni Asproni - Methodology Patterns: a Different Approach to Create a Methodology for Your Project

    Giovanni Asproni
    Giovanni Asproni
    Consultant
    Asprotunity Limited
    schedule 4 years ago
    Sold Out!
    90 Mins
    Tutorial
    Advanced

    In the software world we have been looking for “The Methodology” to solve our software development sorrows for quite a while. We started with Waterfall, then Spiral, Evo, RUP and, more recently with XP, Scrum, Kanban, DAD, SAFe (there are many others, but, their impact, so far, has been limited).

    In this tutorial, I'll show why this search for the holy grail is bound to fail--each methodology has strenghts and weaknesses that make it suitable only in some contexts--and I'll describe a different approach based on patterns and pattern languages, that teams can use to create their own methodologies to suit their specific needs, which, in my experience, has a higher chance of success. 

    The approach is based on the observation that all the practices used in all modern methodologies--e.g., user stories, use cases, team self organization, TDD, unit testing, acceptance testing, continuous integration, iterative and incremental development, etc.--come from the same set. Different methodologies just mix and match them differently. All those practices can (and many have already been) described as patterns whose relationships with each other form a set of pattern languages.

  • 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.

  • 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.

  • 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 Sudipta Lahiri
    keyboard_arrow_down

    Sudipta Lahiri - Capacity Planning for Dynamic Teams

    Sudipta Lahiri
    Sudipta Lahiri
    Head of Products
    Digite Infotech
    schedule 4 years ago
    Sold Out!
    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 Vinodhini
    keyboard_arrow_down

    Vinodhini / Thushara Wijewardena - Robotic Warehouses, Alien Domain, Offshore developers, Visionary customer : Saved by agile

    20 Mins
    Experience Report
    Intermediate

    Here is a case study of how agile outsourcing can be practically applied even when the business domain is very complex and alien to offshore teams.
    The example is a project in which Exilesoft provided for a leading Norwegian producer of Robotic warehousing solutions. The project involved transforming their legacy application, produced using multiple suppliers and methods, into a newly cast application solution. This project also had its own share of typical challenges.

    • Lacked definitive and reliable documentation,
    • Domain knowledge was limited to a few very busy individuals,
    • Development and redeployment could not interrupt attention to current customers,
    • Complexity was high and design was fragmented, and
    • Focus heavily invested on current product and customer support

    These limitations along with the lack of understanding of agile methods strongly suggested the use of a method adaptive in nature, and not heavily vested in large inflexible legacy elements.
    We commenced the engagement with two pivotal elements; client awareness (agile orientation) and a roadmap of committed involvement. To lay credibility this had to be backed up with proven result delivery in the very early stages. It allowed for flexible adaption, and the creation of an atmosphere that fostered client interest.

    During this session, we will take the audience through a small video clipping of such a warehouse. We will elaborate how the customer and offshore developers worked together using agile in a highly integrated team collaboration model to achieve success within a very short time frame.

    The session will cover the following key areas:

    How such projects can be initiated

    - What type of team model and contract type we used

    - How we did the agile transformation with the customer

    - How the roles were assigned between offshore and onshore team members

    - To improve remote collaboration the tools and techniques we used

    - Techniues learned to get teams up to speed with the new domain

    - As we go along, the process changes we identified and implemented to make things work better.

    - Agile engineering practices and team dynamics that helps in such situations

  • 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 Neil Killick
    keyboard_arrow_down

    Neil Killick - The Guessing Game - Alternatives to Agile Estimation

    Neil Killick
    Neil Killick
    Lead Agile Coach
    MYOB
    schedule 4 years ago
    Sold Out!
    45 Mins
    Talk
    Intermediate

    Agile promotes empiricism and change, yet many practitioners continue to scope out and estimate delivery times and costs for software products and projects.

    Defenders of the art of estimation claim that we need to estimate software projects in order to answer common business and customer questions such as:

    • Should we go ahead with this project? (go/no-go)
    • How much will it cost? (bottom line)
    • When will it be done? (predictability)
    • Should we do project B instead of A? (prioritisation)

    This session challenges participants to flip these questions on their heads and seek alternatives to estimation rituals. It covers the many risks inherent with an estimation culture and demonstrates real, practical alternatives, both at the portfolio and the sprint level.

  • Liked Ravi Krishnan
    keyboard_arrow_down

    Ravi Krishnan - Agile Transformation Maturity Model

    45 Mins
    Experience Report
    Advanced

    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.