Scaling Agile Adoption Day 1

Wed, Mar 25
08:30

    Registration - 30 mins

09:00
10:00

    Opening Talk - 15 mins

10:15

    Coffee/Tea Break - 15 mins

10:30
  • Added to My Schedule
    keyboard_arrow_down
    Ashish Parkhi

    Gamifying Agile Adoption - An Experiment

    While having a chat with Naresh Jain, he suggested me to go through the Ted Talk – “Gaming can make a better world” by Jane McGonigal. I found the title very weird and was wondering how is that possible? After going through the talk though, I was amazed. I started wondering if I can use the gamification technique in Agile Adoption, in our Products, in Performance Management Systems, in Employee Engagement Programs?

    Dhaval Dalal introduced me to Prof. Kevin Werbach’s definition of Gamification – “The use of game elements and game design techniques in non-game contexts.

    For our 4th ShipIt Day, organized on 25th/26th Sept 2014 at IDeaS, I decided to explore the idea of using game elements and game design techniques in the context of Agile Adoption. The idea was to create a gaming system which will automatically collect data, i.e. without explicit user intervention,  from multiple sources like Jenkins, Rally and manually from individuals and offer Star’s for positive behavior and deduct Star’s otherwise.

    The aim was to help the team get continuous visual feedback on how they are doing, adopt agile practices, visualize sense of accountability, visualize sense of achievement, drive positive behavior, create healthy competition, create a culture of appreciation, help performance tracking and create transparency.

     

    Landing Page

    User Profile

     

     

     Update - 

    1. Deducting points seems to be bothering the individuals. Now we are experimenting with getting rid of negative points and introducing short lived badeges instead e.g. "Build Breaker". 
    2. We have now added more badges to recognize individual efforts in various categories.
    3. Working on open sourcing the core app at https://github.com/IDeaSCo/rockstar
  • Added to My Schedule
    keyboard_arrow_down
    Francis Kelly

    6 Fixes to UnSAFe Starts

    Scaling Agile is now proven in a multitude of Fortune 500 companies. From the case studies and presentations, it could look easy -- just follow what everyone else is doing, right?

    But just as the anti-patterns of Scrum can maim the team, false starts at scale can paralyze the enterprise. Which six appear most often?  In this session, Francis discusses how to be proactive in these unSAFe situations:

    • Managers not thinking Lean and teams believing in chickens and pigs
    • Alignment as lip service
    • Prioritization as a game
    • Building a portfolio practice without strong program execution
    • Using Agile to build bad code faster
    • Never looking back

    We know that bullets may not be silver and fixes may not be quick... but knowledge is key to enterprise safety!

  • Added to My Schedule
    keyboard_arrow_down
    Debbie Wren

    Training and retaining the basics of Scaling Scrum through the power of play

    How do we provide Product Owners, Scrum Masters, Team Members and others who are applying agile practices with a safe environment in which they can experience and “have a go” with Scrum?

    Scrum simulation with Lego’s is a tried and tested technique that has been successfully applied to help teams build up their understanding of the ceremonies and rigors of Scrum.

    In this highly interactive workshop session we will take participants through how they can customize, build and facilitate an agile lego simulation that addresses their particular learning points. We will also show you how you can use this approach to help distributed Feature teams who share a common backlog understand how they work as one to deliver their Product. Participants in this workshop will leave with the confidence to apply the power of play.

11:30
12:30

    Lunch - 60 mins

01:30
  • Added to My Schedule
    keyboard_arrow_down
    Tathagat Varma

    From Waterfall to Weekly Releases: A Case Study in using Evo and Kanban

    In 2003, we had a major problem to solve - our products had far too many open field defects, and the bug arrival rate was moe than the closure rate. We tried to fix using our process which involved shipping quarterly service packs, but that was not only elongating the lead time, it was also not very amenable to changes. The process for customer specials (specific features, etc.) was not any better, and invariably it led to exec-level escalations just to get some deal-blocking customer escalations into the service packs mid-way in the quarter.

    In 2004-05, we experimented with a pull system that limited the work in progress and created a more smoother flow of value. The result of this system was that we were able to significantly reduce the defect backlog, and were able to bring down cadence of features and bugs to a weekly cadence. The experiment was so successful that in about 6 quarters, we had fixed most of the field defects (brought down individual product's defect backlog to single digit) and we had to disband the team as there was no work left for them!

    We were inspired by Tom Gilb's "Evo" method and experimented with it to create a weekly cadence. However, we found that the nature of field defects and customer specials was stochastic in nature and didn't lend itself very well to a timeboxed framework like scrum. However, there were no off-the-shelf methods available back then that were a viable alternative. Hence, we experimented with various methods and blended-in elements form various methods to create out our very first kanban by limiting work in progress.

    In this talk, I will explain our first kanban experiment, and also compare and contrast with the later-day Lean Kanban by David Anderson.

  • Added to My Schedule
    keyboard_arrow_down
    Seshadri Veeraraghavan

    Agile Transformation: Practical Insights into Behavioral Adjustments and Cultural Changes

    An all-encompassing effort such as a full-scale agile transformation goes to the very roots of an organization and tends to shake things up quite dramatically. Indeed, it’s very much like undergoing heart surgery AND brain surgery – simultaneously.

    Imagine the damage caused from a failed organization-wide change:

    • Loss of credibility
    • Loss of trust
    • Loss of face and reputation
    • Strong demotivation and loss of commitment and faith on the part of employees
    • Clinging even tighter to the old (safe!) ways of doing things
    • Diminished success of future attempts by leaving behind a wary and highly skeptical audience

    After the storm passes, where things have settled often determines how and where the organization goes from that point onwards. Ensure your transformation plan succeeds and the pieces fall into place according to the set goals and plans -- and not according to someone’s whims and fancies; politics; cultural and attitude issues; or naysayers.

  • Core Agile practices establish visibility, remove impediments, and promote collaboration at the team level. Standup meetings, physical task boards, and focus on clearing impediments are well known practices to keep a team focused on the work, and establish a sense of flow towards frequent, tangible, and sustainable results.

    What about an entire program, when a large number of teams are involved? How can a large organization exploit the same core practices when there is highly interdependent work, and when there may be hundreds of people involved? How can Scrum be used to improve delivery times, increase quality, and promote sustainable development at a program level? How the can practices provide executive leadership the visibility they need into program progress?

    This workshop will introduce valuable, proven Scrum practices for large programs. Among the topics that will be discussed are:

    • What program management challenges are ripe for improvement through Agile practices?

    • The Program Impediment Board: Visible impediments, dependencies and milestones at a program level

    • The Program Stand-up: Lightweight activities to promote visibility, clear impediments and collaboration across the program

    • What does it look like when it’s working?: Improve delivery time, increase quality, and establish collaboration across the organization.

02:15

    Coffee/Tea Break - 15 mins

02:30
  • Most Agile teams learn the ceremonies and other Agile jargons sooner than we could imagine.They add few meetings to their project execution and talk in a fancy language that would make us believe in Agile utopia. Everything seems fine and happy, until one day their happy bubble bursts and they realize that they are just 'doing' Agile and not 'being' Agile. One primary culprit here is that the teams often neglect their core technical practices and don't challenge their status quo. Which means they don't change anything about the way they design, code or test but just modify their management processes and await a miracle. There are three primary reason why we observe this Agile smell in most teams. It is believed that there are no immediate results in modifying these practices, its is hard to change the existing practice because of umpteen man-made reasons and finally no one knows where to begin their journey.

    Here in this talk I would like to address the third challenge and explain how a (non-technical) coach could pair with the team members on their day-to-day activities and help them initiate this journey. The focus of this presentation is on the do's and don'ts while pairing with the team members. It will also explain the benefits of this exercise.

  • In my previous role as the leader of the of a products group, leading one-of-its kind agile transformation initiative, we tried to fundamentally change how value is delivered to customers in legacy technologies. In this experience report, I would like to share my insights about the agile transformation journey by unraveling the challenges and the remediation steps that has helped us in keeping this journey alive. To complicate things further, implementing agile in a mainframe technology stack is extremely challenging because people working with legacy technology/code-base, have a mindset that it is not possible to introduce modern tools/technologies or a different way of developing software in this environment. Specifically I would like to touch upon the following areas to drive agility across the organization:

    1. The need for Agile transformation initiative
      1. Time to market - Long release cycles; Impact on release feature relevance;  - Need for reducing release cycle as well as the need to build what is relevant
      2. Rapid changes in Data Center requirements as well change in direction for technology stack – Heterogeneous platforms, On Premise to Cloud, Web and Mobility driving different usage patterns – driving the need for more and faster innovation
      3. Lack of customer involvement in product roadmap and release plans – Need for early feedback and validation
      4. R&D - Lack of understanding of customer environment; Siloed functional groups inhibiting collaboration;  - De-risk knowledge levels within the organization; Improve cross functional team behaviors; improve engineering practices and usage of productivity tools
    2. Challenges faced during the journey – Communication; Expectation Management; Changing culture and behaviors; HR – role of HR, systems, processes, performance management, job titles/description, Rewards and Recognition; Skills – Technology as well as softer skills; Engineering practices and tools;
    3. Organizational changes introduced to make the transformation successful
      1. Communication and expectation Management
      2. Culture and behaviors – soft skills workshops, move from an I to a WE, emphasize on team thru team goals and team success, team based rewards and recognition; changed job description of managers to get effective participation and right behaviors as well as how they can contribute to the team success; Enabled cross functional skills (T skills / Generalists)
      3. HR – Systems/processes, introduction of new job titles and changes to job description, Team based quarterly performance goals and reviews, multi-rater feedback;   Moved from Individual performance reviews to team based quarterly performance reviews
      4. Engineering excellence – enabling skills and tools for continuous integration, build and deployment to provide faster feedback as well as shorter release cycles; improve quality;   Moved from waterfall to a daily integration and build model;  
      5. Value Delivery – Requirements voted to understand high priority needs; reduce release cycle; customer involvement during roadmap and release planning, sprint review feedback;   Release cycle reduce from 18 months to quarterly incremental releases

    Due to the nature and complexity of the change, the impact and touch points involved in this transformation, it is very critical to have an active and deeper participation from the leadership team to effectively plan change management to make the transformation successful.   Since it was a multi-year transformation initiative as well as continuous improvement journey, we had taken a phased approach to implement the overall transformation plan so as to take benefit out of learning coming out from each of the phases.

     

  • Added to My Schedule
    keyboard_arrow_down
    Rathina

    Edward De Bono's Creative Thinking meets with Agile

    Slide Deck used in the conference:  http://www.slideshare.net/RathinaKumar2/edward-de-bono-agile

     

    Building 'happy' teams is one of the cherished goals for Agile Coaches and Scrum Masters. In my coaching experience, all the high-performance agile teams have joy and happiness as the core to their performance. 

    I have taken Edward De Bono as my support and his work on creative thinking as my guide for this purpose. Edward De Bono's crative thinking patterns include several aspects like curiosity, provocation, synergy, fun, hypotheis etc. Edward De Bono's work can be applied in every field where we look for creative outcomes. 

    These creative thinking patterns can be adopted by agile coaches/scrum masters to improve their effectiveness in building high-performance teams.  

    This session has exercises that are derived from Edward De Bono's work on creative thinking patterns. These exercises can be used by agile coaches/scrum masters with appropriate modifications in their real world contexts.

    Join me in building "happy" teams with the help of Edward De Bono.

03:00
03:30
04:30
05:00
  • Added to My Schedule
    keyboard_arrow_down
    Krishnamurty VG Pammi

    6 X 2 Planning Errors in Scaled Agile Delivery Model

    2 major errors across 6 agile planning events give us 12. Learning “what not to do”, can sometimes help us identify risks early in the cycle so that, as a team, we can effectively respond to these risks.

    Agile planning happens at multiple levels. In scaled agile delivery model, effective outcome of one planning event can influence the other significantly either positively or negatively.

    Come and learn top 12 experiential insights. These will help you alert your teams on “what not to do” during Scaled Agile Planning events. I tried capturing top 12 errors across 6 planning events namely Strategy Planning, Portfolio Planning, Product Planning, Release Planning, Iteration Planning and Daily Planning.

  • Added to My Schedule
    keyboard_arrow_down
    vinaya muralidharan

    The Snowball Effect - From Team Kanban to Enterprise Kanban

    About two years ago, we embarked on our journey towards Agility and Kanban was our vehicle.

    But Kanban had people worried.

    How can we not have detailed plans?! How can we limit WIP when we have so many things to work on?!

    We have due dates to meet! And so on.

    We would like to share one of the approaches that we adopted to help move the change along.

    In addition to focusing on the Kanban implementation at the project levels, we adopted another route – to work through the individuals and the teams – a grounds up approach. We encouraged people and teams to use Kanban boards to manage their daily tasks.

    You have difficulty in managing personal stuff? We’ll help you manage better!

    You have issues in managing team level priority? Look what we did within our team- we have a Team Kanban and we are now much better organized!

    One by one we saw people getting interested. The movement gathered steam - we worked directly with a handful of people and they in turn got their peers onboard. And we saw various flavors like Personal Kanban, Team Kanban cropping up all over the place – even in our Travel Office and Corporate Office. What this did was give people a safe, controlled environment to experiment and learn in.

    As they got used to the ideas of limiting WIP, pulling work, visualizing work and “stop starting, start finishing”, it gave them the confidence to work this way at the project level too. And it made our lives as change agents just a wee-bit easier!

    We welcome you to come hear our story about nurturing the change towards Agility by making it a grass roots movement.

    A brief introduction to Amdocs - Amdocs is a leading provider of Customer Experience systems and services in the telecommunications domain, typically doing large scale transformation projects.

05:30
06:30
07:30

Scaling Agile Adoption Day 2

Thu, Mar 26
09:00
  • How organizations are learning to value learning and not just velocity!

    We all hate wasting time and money.  In the pursuit of cutting out waste, we've learned to systemically fool ourselves – to convince ourselves with very little evidence that the activities we're engaged in add value.  And, further, activities that don't result in a product we can deliver are waste.  But, the biggest leap of faith I continue to see most companies make is in believing that people want their new product, feature, or idea.  They likely don't.

    This talk is about the rise of learning as a valuable activity.  I'll give examples of organizations that invest in experiments that take the cooperation of developers, testers, product mangers, infrastructure, sales, and marketing.  At the end of these experiments organizations are left with no deliverable product and only the knowledge that the product they're thinking of should or shouldn't be built at all. 

10:00

    Opening Talk - 15 mins

10:15

    Coffee/Tea Break - 15 mins

10:30
  • Adopting agile development practices and continuous delivery is becoming a norm in the software industry. Time to market and frequent releases have drastically reduced time available for regression testing. Inspection is considered wasteful. Faster feedback cycles during development is crucial. These have created lot of challenges for testing community, which traditionally relies on manual testing assisted by UI based test automation.

    This is an experience report of transforming testing practices across organization, which decided to embrace Agile. Today our testers are not trying to find defects, instead they collaborate with product management and developers to prevent them in the first place. In fact, during the appraisal process, the defects found by them is ignored, instead we focus on how much time they are able to dedicate to collaboration and exploratory testing. The boundaries between developers and testers have faded away and today quality is whole team's responsibility.

    We started with less than 20% of our testers with automation skills (mostly UI automation) and rest of them relying on manual testing. However, today, all our testers practice BDD. They have picked up Java & Groovy programming skills. They are able to contribute Workflow tests, Integration tests and Business Logic Acceptance Tests. Early collaboration and pairing is the norm. By the time developers are done with their tasks, all checks are already automated and hence we are able to deploy software every fortnight to production.

    Are your testers finding it hard to make this transition to an Agile mindset? This session will give you some concrete ideas based on our transition at IDeaS.  

  • You’ve started on Agile project. You've probably got IT management on board. You've read the manifesto. You've got a wall covered in post-its. You’re probably not using pair programming but you’re following most other Scrum and XP practices. But now you have a problem. Operations, HR and finance can’t keep up. Ops is having problems (or just refusing to) deploy each iteration. HR won’t let you form self-organising teams and don't know how to write KPI’s to support collaborative work practices. And finance wants a 3 year budget with fully costed initiatives.

    Like many cultural problems, change comes from understanding. This presentation will explain how non-IT business functions operate and why they have legitimate problems with Agile delivery.

    We won’t stop there however.

    By understanding your business, this presentation will provide you with the tools you need to align your corporate business functions to your agile development approach. From improved communication integrated sales, rolling budgets, agile KPI’s and aligning to revenue drivers. You will learn how to build a truly agile organization.

  • Organizations invest energy, effort and real dollars to stay in trend. Here's one of the trend: Agile is no longer a buzz word, Scaling Agile is. Terms like Enterprise Agile, Scaled Agile, SAFe, LESS, DAD, Agility Path are conveniently thrown around in meetings and speeches as organizations line up to get on the bandwagon of 'Scaling Agile'. Scaling Agile - from the team and product level to the organizational level has it's own benefits and challenges. Is scaling Agile right for you? Are you ready for it? If you've been thinking of scaling, you might be in luck. In this session, we will discuss grounds up approach of how to analyze and evaluate if an organization (or a business unit) is ready for scaling Agile. You'll create your own set of evaluation criteria specific to your organization's situation and learn steps your organization can take to be more prepared for scaling Agile and reap organization-wide benefits. The focus will remain on your context and not on promoting any particular scaling framework.

            "Scaling. Its about the context not the process." - Jeff Sutherland

    PS: This will be a no slides, hands-on workshop. Be prepared to actively participate throughout the session.

11:30

    Break - 15 mins

11:45
  • Kanban is one of the fastest-growing development methodologies today.  Teams increasingly turn to Kanban to simplify and streamline their agile development, but few people know the inside story of how and why Kanban was created.  The Secret History of Kanban pulls back the curtain and gives you a first-hand account of how Kanban went from being a colossal failure to a startling success, presented by one of the original team leaders.  Learn how a team turned theory into practice, what it means for the future of Agile, and how you can apply those lessons in your own organization.

  • Added to My Schedule
    keyboard_arrow_down
    Avinash Rao

    The Double Helix Model for Lean Agile

    We are living through a winter of discontent in the Enterprise IT space serviced by IT services organizations.

    Agile is no longer new; Agile projects which are running effectively are being asked to be efficient; at the same time, cost efficient projects are being asked to be more Agile (with Agile meaning different things to different stakeholders). In the minds of clients, the words Agile and Lean have become synonymous with effective and efficient IT services delivery. Long seen as two parallel ways of work, we are now being asked to do both. Does ‘Lean Agile’ – which is becoming fashionable with some clients - exist, and what does it look like?

    The authors of this session come at the problem from opposite directions. Avinash’s starting point is a tightly managed traditional project burned by a (past) failed Agile implementation, that nonetheless needs to deliver the value Business is demanding; Jay runs a large successful Agile program that the customer is now demanding efficiencies from. We came together to create the Double Helix, a model to implement Lean Agile.

    Before the implementation of Double Helix, our structures existed in traditional forms - a Hierarchy in case of projects that thought themselves efficient. and for agile, a Scrum structure within a deeply entrenched structure based on designations and seniority. By implementing the Double Helix, we overlaid this structure with Planning teams that cut across designations (from the program manager to entry level trainees) and Execution teams that are mainly peer-level (all managers, all leads, for example). Power shifts from a experience and role basis to the basis of contribution to the respective planning and execution teams. As we will show, this is very similar to the Lean organizations that Japanese manfacturers have adopted. 

    Our measurements reflect this change. Our efficiency measures indicate the progress made in reducing waste (57% of the project work was non-value add, in the example presented, reduced to 20%) and effectiveness measures show the RFT (Right First Time) and also use feedback from the end-users (defects / fresh Function Point delivered) to measure how effectively the program is delivering value. 

    We will share how tooling was used to idiot-proof (Poka Yoke) development, especially during steep ramp ups - reducing the time for a new entrant to be productive in a mission critical development project from 45 to 30 days.

  • Added to My Schedule
    keyboard_arrow_down
    Ahmed Sidky

    Value Teams: The Next Evolution of Product Owners

    When people learn about agile they usually learn about Scrum (since it is the most popular flavor of agile). While Scrum is beneficial, it does not have answers to all the challenges of software development. One of the common challenges teams face is that of having an effective Product Owner. From experience, it is not about who is fulfilling the role of the Product owner in your organization but about the definition of the role itself. We have played with many different variations of the PO role, till we ended up with the concept and structure of the Value Team. To keep it simple, the Value Team is responsible for making sure the product is (1) Feasible, (2) Valuable, (3) Useable.  After using Value Teams in many corporations (the session will have many real-life examples of this) they seems to be a practical solution to many problems about how agile can work in complex environments where there is no ONE product owner, but rather multiple organizations and people that have a say in what needs to get build and how. This session will present the idea of Value teams and answer questions on how to create them, how they operate, who is in charge, and why they are so critical to the success of the agile delivery team.

12:30

    Lunch - 60 mins

01:30
  • Added to My Schedule
    keyboard_arrow_down
    Prasad Kunte

    Implementing Agile Engineering Practices in Legacy Codebases

    Afraid of legacy code? Don't be!!!

    Most successful product companies are confronted with the problem of legacy code.

    What is a legacy code?

    • A code which is in production for several years.
    • A super-complex, hard to understand code base, written by different set of developers. 
    • Outdated Technology stack.

    But the most hurting reality is:

    Lack of confidence in the code due to zero or poor test coverage.

    Due to this reality, developers are often scared to touch it. They have very little confidence that "their code change wouldn't break the existing application in production."

    Recently at IDeaS, we came across such situation, where we needed to enhance one of our products containing legacy code. We started looking into the code and soon figured out that it was developed in 2007, hardly ever touched (& still working in production :)). The original team, which has worked on this product, could not be traced anymore.

    As this product has expanded to attract new customers, we had to change it significantly in order to support new customer's specifications. We had to make sure that the product was backward compatible and supported the earlier specifications, while we enhance the new specification.

    One simple option was to COPY PASTE every single method which needs to be modified and use an if-statement to decide which method to call. This certainly seems like an easy method, since the chances of breaking existing code is very little. 

    Today we all know this is a BAD option!!!

    Instead, our team decided to refactor the existing code to support plug-and-play approach for different specification. But before we started refactoring code, we had to build a safety net of tests around the existing code.

    How do we put the safety net? Ideal way would be to implement the Test Pyramid first. But, that would have taken significant time to be ready with the pyramid before we start touching the legacy code. And obvious, we would have missed the business goals.

    What do we do?

    Instead of building the entire test pyramid, we decided to attack different layers of the test pyramid, one at a time. Along the way, we followed the following approach:

    1. Re-structuring the Project code-base
    2. Establishing a baseline database: After taking a dump from the production database, we cleared out surplus data from the DB and setup a seed database with automed scripts
    3. Creating/fixing the build script 
      1. Setting up an auto DB deploy tool and integrating it with build scripts
    4. Set up basic CI pipeline
    5. Write a few work-flow tests to capture the system's flow from user's point of view
      1. Find the inception point in the code from where we can exercise the code
      2. Restify the application at the inception point (one service at a time)
      3. Setup authorization for production and test environment
      4. Build minimal test-data set for different environment 
      5. Create a few work-flow tests via the inception point (Test itself should not be coupled with the underlying database or implementation level components)
    6. Write business logic acceptance test to capture various complicated business rules
    7. Test drive the new enhancement or bug fixes
    8. Every time we touch legacy code, refactor the code and improve test coverage at unit level

    This really helped us test driven the new code and implement all the layers of the test pyramid.

    If you've a similar situation, join us, as we share our experience on how to confront legacy code.

  • Added to My Schedule
    keyboard_arrow_down
    Nanda Lankalapalli

    Happy Teams are key to successful agile transformation– Teams’ self-design

    Agile Teams' self-design is very important (though not very common) exercise in a large-scale agile transformation. In teams’ self design, team members choose their own teams in a collaborative way. This concept here is that the teams will gel quickly and excel when they are self-designed.

    In this session I am going to present my experience with such exercise. I facilitated at least 4 such sessions to help an organization as part of a large-scale transformation. The session is going to explain

    1. Benefits of Feature teams over Component teams
    2. Self-design of feature teams
    3. Pilot exercise of self-design of 2 feature teams.
    4. Large scale self-design of 4 product groups with 30 to 50 members per group.

     

  • This workshop will help participants to understand how the Kanban method really works.

    We will learn how to use the Kanban method to visualize your current process ("start where you are"). Will figure out how to limit work in progress (WiP); define and make process policies explicit; measure and manage flow.

    Also we will figure out what does it mean to search for opportunities for continuous improvement. We will learn how to increase your team speed and at the same time decrease pressure at work.

    All of these we will touch through extremely hands-on step-by-step simulation using LEGO bricks.

     

02:25
03:00
  • Added to My Schedule
    keyboard_arrow_down
    Debbie Wren

    Growing up the Product Management Tree House

    Product Management for agile projects is still in the 1970’s era or is it really?

    Organizations today face tough challenges in overall agile delivery, with the product management teams still catching up and coming to terms with the new agile beast, which churns out functionality every 2 weeks. The product managers do not have a clue as to what exactly they need to do next with these 2 week deliverables! OK at least some do have an idea, but most product management teams struggle to keep pace both with their internal product owner needs on one end and the external customer /market facing demands on the other.

    This talk focuses on our experiences of building product management capabilities at large scale, to overcome these challenges, and provide some insight with practical tips implemented. Join this session to learn from our experience and grow your own product management tree house.

  • Added to My Schedule
    keyboard_arrow_down
    Zaheerabbas Contractor

    Enterprise Agile Adoption: An Organizational Change Management Journey.

    We represent the Agile Center of Excellence at our Organization and are chartered to drive the change management initiative to imbibe Agile adoption across the enterprise.

    We plan to share our experience on the Organization Change Management initiative that we took up to drive Agility across the organization.  Our journey towards the derived vision and strategy to increase Agility in the system to thereby achieve:

    • Nimble simplified processes.
    • Ability to respond faster to change.
    • And most critical: delivering increased customer value.

    This is a continuous improvement journey and we initiated:

    • Structured multilevel communications of CHANGE to the teams.
    • Learning + Unlearning:  Structured Training and Development plans (Behavioral and Technical).
    • Bringing in Gamification as a tool to get millennial team members to learn quicker.
    • Approach to move from “Pyramid” to “Hour Glass” structure to align with the flat team structure.
    • Pilot: Career Development Framework Aligned to Agile structure and roles.
      • Bringing in change of G&O to align with Agile delivery
      • Enabling Talent Fulfilment to align to the Agile roles and structure
    • Pilot: Performance change management- Holistic approach to drive appropriate behavior
    • Brining in systemic changes to ease Agile adoption
03:05
  • Added to My Schedule
    keyboard_arrow_down
    Prasad

    Speed 2 Value.. helping large Enterprise IT to be in the game..

    Technology has blurred the lines between the digital and traditional methods of dealing with a consumer of any Global Enterprises. The Business Process and IT is no more separate, in most of the industry verticals the Business is driven by IT.   Constant Innovation around IT has become the new normal to the Enterprises to meet rapidly changing consumer expectations and behavior dynamics.

    More connected consumers, automated processes, and sophisticated analytics place unprecedented demands on IT functions. Many Enterprises are struggling to cope, and they seek to deliver on new demands by adding piecemeal elements to their existing operations. This is easier said than done. Reinventing the IT function at Global Enterprise requires far-reaching changes, from talent to infrastructure, tools, delivery models, partnership model.

    This experience report  brings strategy of 2 speed IT, through which Infosys helped its Global top 10 clients to 'renew' its IT related to Digital & Mobility space using Agile as a key lever.

    This session gives you experiences, practical on the ground challenges, stakeholder and vendor complexity and approach and journey towards Speed 2 value. Also I am pairing with Alok Uniyal who is senior leader at Infosys and a CIO coach who helped 50 plus clients to transform their IT organization in last 20 years.

03:30
04:00
  • Added to My Schedule
    keyboard_arrow_down
    kavita kapoor

    Hacking the Sales Process with Kanban/Agile

    The sales process is hard. As a business owner, you spend your entire time doing it. Often wishing you were back, cutting code. If you are successful you might have a raft of sales people closing deals under their own process while your product people deliver under Agile. Your worlds are split and often, it breaks.

    Change that. Apply Agile and Kanban to supercharge your sales team. Get your developers and scrum master in on the action. Unify your company.

    Kavita has spent the last two years changing the global process of a leading Ad Agency while based in Delhi. Now at Fifty based in London and Barcelona she has created a unified Product and Sales team from scratch. Turning her work over the last 6 months into a case study, get a fresh of the presss step by step break down of hacking the sales process from both the CEO, developer and copy writer perspective. Kavita will be transparent about mistakes and the open about the recipe for success.

  • Added to My Schedule
    keyboard_arrow_down
    Raja Bavani

    Detect and Eliminate Bureaucracy in Geographically Distributed Large Agile Teams!

    One of the many great things about working in Agile teams is the lack of bureaucracy. Agility and bureaucracy do not and cannot coexist. In general, bureaucracy is a system of government in which most of the important decisions are made by state officials rather than by elected representatives.  

    Management guru Gary Hamel says,

    “Strategy gets set at the top. Power trickles down. Big leaders appoint little leaders. Individuals compete for promotion. Compensation correlates with rank. Tasks are assigned. Managers assess performance. Rules tightly circumscribe discretion. This is the recipe for “bureaucracy,” the 150-year old mashup of military command structures and industrial engineering that constitutes the operating system for virtually every large-scale organization on the planet. It is the unchallenged tenets of bureaucracy that disable our organizations—that make them inertial, incremental and uninspiring.”

    In our context, bureaucracy is with reference to geographically distributed teams working together to run Agile projects. When there is bureaucracy in geographically distributed teams, you will find powerful forces setting the rules, defining practices and mandating criteria. And there will be several followers who are ready succumb to the pressure. When this happens one may witness specialized definitions, measurement criteria, and rituals that define the software lifecycle to be followed by distributed teams. Decision making will move up in the hierarchy. Teams will practice practices just for the sake of practicing. Many of the team members will eventually forget the purpose, essence and sprit of processes. That is a slippery slope! In geographically distributed teams – especially when multiple organizations and powerful leaders come together, it is very difficult and challenging to guard against bureaucracy.   When that happens, we cannot have true Agile enablement.

    This session will present the ground realities seen in distributed Agile projects and techniques to overcome bureaucracy in geographically distributed teams.

05:00
  • Added to My Schedule
    keyboard_arrow_down
    Ahmed Sidky

    The Secret, yet Obvious, Ingredient to Achieving Sustainable Organizational Agility

    Education is a critical component in a sustainable agile transformation. Sustainable agile is realized when people have truly change the way they think – that needs education. If we truly understand that we need to change the mindset of everyone in the organization, including its leaders, then we need a combination of education, coaching and mentoring to successfully equip people with the knowledge and skills they need to develop and execute agile habits. If we think of agile as a process, not a mindset, then we default to training instead of education.

    Training is about the mechanics of how practices are done, such as a template for writing a user story, education will focus on changing the thought process to focus on value and enable the educated to think and decide what works for them and for their team in a given context. That is true agility.

    While we acknowledge our bias towards the learning roadmap published by the International Consortium of Agile (ICAgile.com), we truly believe that it is the most comprehensive roadmap in the agile community that focuses on a common education roadmap for agile and agility and not training on a particular agile methodology. ICAgile has gathered experts from around the world and they have collaborated to define an education roadmap for every discipline needed to change how the organization as a whole works, and provides education as a foundation for sustainable organizational agility. (Focus on people not process, education not training)

    Certifications are a way to give people confidence in the learning and competency of others. Agile certifications should be no different. ICAgile has developed a set of competency based certifications to ensure we keep the focus on Education. 

06:15

    Panel Discussion : Agile Adoption Trends in the near future - 45 mins

07:00

Agile Lifecycle Day 1

Fri, Mar 27
08:30

    Registration - 30 mins

09:00
  • In order to successful scale any method or practice, it has to have some basis in theory. This presentation will use insights from complex adaptive systems theory and the cognitive sciences to lay a foundation for that theory. Seeing software development as a problem of knowledge management, the theory will elaborate a understanding of applications as the emergent property of a co-evolutionary interactions between technology capability and unarticulated user requirements.

    Having established a basic theory a range of methods and tools will be elaborated. These include:

    - Narrative based approaches to requirements capture (not to be confused with Story telling or story boarding) which gather thousands of fragmented self-signified anecdotes relating to real and imagined needs within a user community and allow interpretation and integration into project planning.

    - Approaches to project planning and implementation that focus on the creation of self-organising teams of specialists and users to create novel approaches, supported by evidence to previously intractable problems. This is particularly relevant to the 5-10% of any major project which creates 95-90% of the grief.

    - The integration of tools such as blogs, wiki's etc into the development environment. Too often corporate environments over-constrain those tools into over rigid structures which destroy their utility.

10:00

    Opening Talk - 15 mins

10:15

    Coffee/Tea Break - 15 mins

10:30
11:30

    Break - 15 mins

11:45
12:10
  • Added to My Schedule
    keyboard_arrow_down
    DEBASHIS BANERJEE

    Agilists - Detect, Protect and Celebrate IP Created During Sprints

    In the context of continuous and periodic delivery of same day, monthly and agile incremental delivery in both established and startup contexts there is a possibility of teams missing key elements of protecting their IP. Some simple elements such as making your work public prior to protecting it can cause loss of business. Additionally in short sprints filing IP may not be the most important focus within teams (especially in startups or smaller companies where budgets might also be a constraint). In this session it will demonstrate (a) Some key elements of how to keep IP in mind in Agile sprints (b) Some general best practices of how IP can be used as a bond/glue for teaming (c) Some process changes possible to ensure IP becomes a key element of agile delivery. These is based on experience of over 6 years submitting IP self and also having 6 people having approved IP, 20+ people encouraged to submit and 75+ submissions. (d) As a influencer will provide some best practices to Leaders and Product owners to encourage IP. (e) Additionally IP can be a great occassion for team building and bonding and a retention tool.  Note: The session will be generic and will not cover any specific IP process of any company but a general set of practices via experiences

12:30

    Lunch - 60 mins

01:30
03:00

    Coffee/Tea Break - 15 mins

03:15
  • Added to My Schedule
    keyboard_arrow_down
    Todd Little

    Mythbusting Software Estimation

    Estimating software projects has proven to be particularly challenging.  Over-running schedules happens frequently in our industry.  As a result software estimation is often viewed as a black art.  In this session Todd will look into some of the reasons for these challenges by exploring a number of myths of software estimation and then setting out to validate or bust these myths.

    Some of the myths that will be explored include:

    • Historical Estimation Accuracy
    • Relative Estimation
    • The Cone of Uncertainty
    • Velocity
    • Scope Creep
    • Estimation Tools
    • Wisdom of Crowds
  • Added to My Schedule
    keyboard_arrow_down
    Yuval Yeret

    Kanban - A Way Towards DevOps in the Legacy Enterprise

    DevOps is a higher form of agility. It is a blueprint for a great culture and and process between the different groups involved in the delivery pipeline. The big question is how to achieve it. If you are founding a startup today, it can be quite easy to take that blueprint and use it to create your process, hire the right versatile flexible people, and start delivering without any technical/automation debt or friction. But most of us are not founding new startups. Most of us already have a running operation with people, culture, process that matured over the years and despite its flaws is currently the way we do things. Changing that is non-trivial. For things to change people need to understand WHY change, what we are changing, and we need an effective process for managing the change itself (HOW to change). So what ARE we changing to? DevOps is highly focused on looking at the whole value stream from idea to value and ensuring effective flow through this pipeline. Kanban is ONE way of HOW to change. It starts by visualizing all the work flowing in the pipeline, then managing the flow focusing on finishing things end to end rather than starting in order to stay busy. It continues to what we call the “Work in process Diet” – Straining the flow more and more in order to identify obstacles to tighter and tighter DevOps culture/operation and faster feedback cycles. You can expect to come out of this session with ideas how to take your current operation and DevOpsify it in a safe evolutionary way using the Kanban method.

  • Over the past ten years, software development teams using Agile approaches to work have adopted retrospective meetings as a critical practice for learning and continuous improvement. To the extent that practitioners say, “If you’re not holding iteration retrospectives, you’re not doing Agile.”

     Agile retrospectives at the end of each iteration or work increment set aside time for the team to examine feedback from current conditions and develop targeted tactics to keep the project on track. Many practitioners experience retrospectives as great means for detecting good, poor, and missing practices; as a handle to make tacit knowledge about effective practices explicit; and to define improvement actions in order to deal with ineffective or inefficient technical, process, and teamwork practices.

    However, too many teams and practitioners don’t reap the benefits that effective retrospective meetings can provide. Too many retrospective meetings receive cursory or inadequate facilitation. Too many retrospective meetings are held to  “check the box” on the project management template, rather than to focus on real improvements. For too many teams, the action plans coming out of retrospectives are never implemented or revisited. Too many teams seek to shift blame and responsibility for action through the retrospective.

    In too many organizations, retrospective meetings don’t deliver the promised return on time invested (ROTI).

    In this session, you’ll learn how to get the most from your retrospective practices. Diana Larsen, co-author of Agile Retrospectives: Making Good Teams Great, will introduce you to a simple framework for getting better outcomes from retrospective meetings, suggest ways to maintain the relevance of improvement to the work of your team, and provide tips and pointers to get great returns from the time your teams devote to every meeting. 

04:15
  • Added to My Schedule
    keyboard_arrow_down
    Ravi Kumar

    Attaining Agile Fluency: Coaching Techniques - Focus on Goals Over Process

    What is coaching?

    “It is helping to identify the skills and capabilities that are within the person, and enabling them to use them to the best of their ability” — wikipedia

    "Individuals and Interactions over Process and Tools"

    The above is first of the 4 values espoused in the manifesto but yet it is common to see many agile coaches engage with teams and organisations advocating more and more processes. This is a common sight with new teams and also with teams on the path of agile transition from few months to few years irrespective of the competency, skills and maturity of the teams. Agile Fluency model created by Diana Larse and James Shore highlights the focus on value over compliance and practices at any given level

    “ Team fluency depends on more than just the capability of the individuals on the team. It also depends on management structures, relationships, organizational culture, and more. Don’t make the mistake of blaming individuals for low team fluency, or assuming that one highly-skilled individual will guarantee high team fluency ”

    An agile coach responsible for building high performing teams will need right set of powerful tools and techniques to leverage while working with teams and also to set the right expectations to both management and teams. This talk will draw from experience using few such powerful tools mentioned below while coaching teams attain fluency.

    1. Deliberate Practice
    2. Driving Empowerment & Self Organisation: Working Agreements
    3. Scaling Agile Transformation: Creating a Learning Org 
    4. Driving Commitment: Key Measures Highlighting Self Organisation

    This is not a beginner level talk and assumes participants having experience in leading agile teams and transformation initiatives in your respective organisations.

  • Added to My Schedule
    keyboard_arrow_down
    Sean Dunn

    Agile Architecture: A Contradiction in Terms? Our Journey in Discovering the Role

    The role of "Architect" is sometimes frowned upon in the Agile community as a central command-and-control authority who bottlenecks decisions and limits team empowerment. Or at least, that is what we thought. Follow the real-life journey of our teams as we discovered how the role of an architect is compatible with Agile principles. We will explore our failures, and eventual discovery on how the role brings can bring an immense amount of value to the organization and the teams, especially on large, multi-team projects. 

04:50
05:15
  • What could be more important for leaders than increasing their teams’ productivity? Conventional thinking would rank “increased motivation” as one of the most important tools for increasing productivity of teams.

       Motivation --> increases Progress --> increases Productivity

    This interactive session will disrupt and challenge the above notion, and will provide an alternative view:

       Progress --> increases Motivation --> increases Productivity

    Dipesh will be drawing upon more than a decade of research including 26 project teams, 7 companies and a deep analysis of nearly 12,000 daily diaries kept by team members, and use real case studies and examples to illustrate the following key elements:

       Catalysts – events and actions that help a team move forward

       Inhibitors – events and actions that can induce setbacks

       Nourishers – interpersonal interactions that lift team’s spirits

       Toxins – interpersonal interactions that undermine team’s spirits

    Awareness of the above principle is important and may sound simple; however turning the awareness of these elements into the inner workings of our daily routine takes discipline. With that in mind, all attendees will be given 'The Progress Enablement Checklist' that will assist them in making such behaviours habitual.

    If you are a leader or an aspiring leader of an Agile team, this session will provide clear implications for where to focus your efforts so that you do not worry about the wrong things. You will be inspired by knowing what serves to catalyse and nourish progress – and what does the opposite.

  • Added to My Schedule
    keyboard_arrow_down
    Mikael Lundquist

    10 times better quality with agile transformation. How we did it!!!

    Abstract

    In 2011 the Ladok section at ITS had serious quality issues, resulting in dissatisfied customers. At the beginning of 2012 the section started an agile transformation, in steps, throughout the whole section. One year later the whole section had transformed and currently the section now eats, sleeps and breathes Agile. The quality has improved remarkably and our customers are understandably much more satisfied. Besides satisfied customers, our employees are happier.

    The ideas to try agile came from the people working in the project and we think that was an important factor for the success.

    We are going to talk about our experiences of this transformation and how the transformation contributed to the remarkable increase of the quality. The talk will cover the background, our roadmap, the result of the transformation and the factors of success.

    We have identified two key factors of our success that we will promote a little extra during our talk.

     

    Presentation technique

    We are going to perform this presentation in an agile way, in the way we interpret scrum. This means that we are going to interact with the audience and we expect them to influence our presentation.

    The point is to not just talk of how we did, but also show it on stage. We also think that this is a good way for the audience to really get the most out of the presentation.

     

    We want you to prioritize the presentation parts

    We consider the different parts of the presentation as the presentation backlog. We want the audience to prioritize the parts of our presentation, in advance. Prioritize here.

     

  • Added to My Schedule
    keyboard_arrow_down
    Madhavi Ledalla

    Deep dive into RETROSPECTIVES- how do we break the usual norms so that these reflections could be made thought-provoking ones!

             Retrospectives are the primary learning, reflection and readjustment techniques on agile projects. A good Agile team is always striving to become better than before. And an effective retrospective enables the team to sieze its opportunity to improve! 

    Retrospectives enable whole-team learning, act as catalysts for change, and generate action.

    R-> Realize where you are and where you want to be

    E-> Engage the teams in fruitful discussions

    T-> Team work to build “We over I” attitude

    R-> Relish the power of Inspect and Adapt cycles

    O->Openness and Transparency to make retrospectives efficient and effective

    In my view, this is not any new concept or a jargon the team needs to really master, but yes in reality sometimes it becomes challenging to keep the momentum lively all times! Over a period of time, we see these symptoms in a retrospective. 

    R-> Repeated issues pop-up

    E-> Engrossing & Engaging discussions are missing

    T-> Team present virtually, loses trust.

    R-> Routine stuff, nothing interests the teams.

    O->Observably gets boring over time.

    To catalyse conversations among team members, retrospectives need to be viewed from a different perspective. This presentaion talks about why the retrospectives efficacy fades off over a period of time and then talks about some very interesting techniques that I used with the teams to make these meetings lively!  Teams need to do out-of-box thinking and appreciate that these short gatherings need not  be done only by using the techniques or methods prescribed in the book but could be done by quoting some situational specific examples that would make the teams really think and speak!

     

07:30

Agile Lifecycle Day 2

Sat, Mar 28
09:00
10:00

    Opening Talk - 15 mins

10:15

    Coffee/Tea Break - 15 mins

10:30
  • Added to My Schedule
    keyboard_arrow_down
    Evan Leybourn

    How much will this cost?

    "How much will this cost?" 
    "How long will it take?" 
    "What am I going to get?" 

    These are the questions that every Agile project gets asked at some point. And while "as much as your willing to spend", "as long as necessary" and "whatever you ask for" are perfectly acceptable, many customers are uncomfortable with these answers. This may reflect more on the customer then the team, but can lead to the misconception that the development team is writing themselves a blank cheque. How then does an Agile team define and scope a project where the customer requires fixed time, cost or scope? 

    This presentation will provide guidance and direction on how to quote for and budget Agile projects, as well as how to change the questions in the first place.
  • Added to My Schedule
    keyboard_arrow_down
    Sophie Freiermuth

    Integrating UX into the Agile Development Cycle - A case study over 3 projects

    User Experience design is a product design discipline which sits throughout a product's lifecycle, from inception to development to maintenance and all the way to retirement. Waterfall enabled the discipline to have ample time and produce extensive design, in a "big design upfront" approach which rarely involved technical capabilities, and resulted in difficulties in build. The adoption of agile by product development team has offered UX a unique opportunity to work in a much more joined-up manner, and expend the design into the development, enabling the entire team to react to change.

    As a UX designer, I have over the last 7 years developped a solid appreciation of working embedded in an agile development team, and would like to share my experiences through 3 specific projects, sharing my learnings to help development team on-board the UX practitioner, their tools, practices and skills.

    This session will be a case study over 3 projects, highlighting the learnings and steps of the integration of UX into the development cycle. I'm taking Alistair Cockburn's sequence of SHU-HA-RI to detail the progress of my practice and will pay great attention to sharing sufficient context that my experiences and outcomes can be translated to your own projects and team setups.

  • Added to My Schedule
    keyboard_arrow_down
    Zee

    Rolling Your Own Platform as a Service (PaaS) with Docker

    We’ve all been there. We’ve had this lovely, monolithic application purring happily away on some platform-as-a-service. However, the application and team are growing and we need to separate out functionality into independent services to keep moving forward without stepping on one anothers’ toes.

    This talk deconstructs the “perceived simplicity” of platform-as-a-services and answers some critical questions:

    • What are the essential components of a Platform as a Service?
    • When is building our own PaaS worthwhile?
    • How and where should we leverage docker in the provision/build/release/deploy/un-provision application life-cycle?

    This talk stems from a 6 month engagement building a platform as a service for a micro-service based architecture.

11:15

    Break - 15 mins

11:30
12:30

    Lunch - 60 mins

01:30
  • Added to My Schedule
    keyboard_arrow_down
    Ashish Parkhi

    Techniques to Speed Up your Build Pipeline for Faster Feedback.

    We would like to share our experience and journey on how we brought down our Jenkins build pipeline time down from over 90 minutes to under 12 minutes. In the process, we would share specific techniques which helped and also some, which logically made sense, but actually did not help. If your team is trying to optimize their build times, then this session might give you some ideas on how to approach the problem.

    Development Impact - For one of our build job, below graph shows how the number of builds in a day have increased over a period of time as the build time has reduced. Frequency of code check-in has increased; Wait time has reduced; failed test case faster to isolate and fix.

    Business Impact - More builds leading to quicker feedback and faster story acceptance and less story spill over.

  • Added to My Schedule
    keyboard_arrow_down
    Lance Kind

    Using Fiction to Motivate Change

    Since the late nineties, the Agile books in the non-fiction aisle have steadily increased in number. It's common to see a book or three about Agile on a colleague's desk. It's also common to see such a book look practically new, the book spin showing no sign of having been opened. Non-fiction books are great at providing bullet points of things to do and reasons why. But non-fiction books are poor at:

    • inspiring,
    • creating emotional attachement (so the reader finishes the book), 
    • creating a full sensory environment for the reader,
    • describing a holostic environment, or
    • 'intriguing' a reader who is un-interested in the topic. 

    (This bullet list above is a good example of how non-fiction can excite thoughts who already know the story behind the bullets, but doesn't inspire much if the reader hasn't any context or background.)

    Fiction is well positioned to do the above because its number one job is to give pleasure and entertainment.  It can't be successful if it can't do this. The oral tradition of fiction has been part of human culture for millions of years, since a Cro-Magnon passed on a story to another, and upon re-telling some details were forgotten and the storyteller had to make them up.  Fiction is in fact is the most successful format for culture change as this is the format of the world's religious works and is responsible for guiding or changing the behaviors of billions of people.  The CIA and the Pentagon use fiction to develop scenarios which are used to create simulations to test preparedness.

    What force could be stronger than fiction for giving an individual the courage to initiate an organizational change in the face of uncertain co-workers and often antagonistic corporate environment?  What tester, developer, PM, director could not use the courage of knowing a "David verses the Goliath," "Legend of the IpMan," or "V for Vendetta" to not only understand the bullet points, but to have the stedfast to sustain in the face of resistance because they believe in the change as if they've lived that life, due to reading stories which placed them in one or many virtual versions of that world.

  • Added to My Schedule
    keyboard_arrow_down
    Vivek Ganesan

    Congratulations! You are our startup's first Scrum Master! What's next?

    Do you fancy playing the first Scrum Master of a startup?

    Do you want to live the challenges faced by the first Scrum Master of a startup?  Do you feel that your organization is dramatically different from the 'ideal' organizations, which the Agile workshops project as a basic requirement for doing Agile development?  Do you wish to deliver predictable results while your management is on-the-way to make your organization 'Agile-ready'?  This tutorial is just what you want.

    In this tutorial, you will experience the life of a first Scrum Master of a twenty member startup, which has expansion plans.  Each of the audience will put themselves in the Scrum Master's shoes and try to solve the challenges posed by the ever-changing environment, while the company's management is putting its best efforts to make the organization 'Agile-ready'.  In this interactive tutorial, a gripping story-line will drag you into the world of uncertainties where you would be challenged to take life-changing decisions regarding your product team's daily work.

    Even if you are not in a startup, this tutorial would benefit you because everyone still comes across ad-hoc situations which go against the ideal expectations of Agile world.

02:30
  • Welcome to the crazy world of Dev-Ops, where the tales span the spectrum from gruesome, grizzly to the heavenly and flowery bliss!

    The silo’d structures, the agonizing buy v/s build debates, the departmental handoffs, tooling and of course the cultural barriers, which all add fuel to the story unfolding in our brave new dev-ops world. But sometimes there are silver linings and the heavens part way for the shining stars to reveal their true glory.

    Join our session to listen to the tales of our (not so) successful dev-ops, and learn the lessons from our experiences.

  • Added to My Schedule
    keyboard_arrow_down
    Niranjan N V

    Mr.Agile Leader - “ Develop People or Solutions”

    Based on my experience of coaching/ training agile teams for 5 years, one of the important reasons for agile teams are impacted, is the personal leadership style of Agile Leaders(Scrum Master, Senior Managers etc) . I have summarized following, factors or impediments for creating effective agile teams

    • The agile teams effectiveness depends on personal leadership style of agile leaders(Scrum Masters, Senior Management etc)
    • Often Agile leaders focus more on “delivering solutions” than “developing people”.
    • Agile leader need not specify work requirements, all that team needs is - empowerment, autonomy to work.
    • The agile team needs more support through mentoring, coaching from agile leaders to exhibit the culture “Being Agile” than “Doing Agile”.
    • Agile leaders need not be an Expert to coach agile teams.
    • Agile teams needs to be taught on Identifying Problem, Problem solving skills and corrective actions and demonstrate steady, small and continuous improvement.

     

    My inspiration to write here, is derived from the book “ Managing Excellence” by David Bradford and Allan Cohen, and reading blogs, articles along with my own experience.

     

    The entire presentation will be done in “Pecha Kucha Style” with less words and more background pictures, in each slide. The most of the message is conveyed through pictures. The presenter will talk maximum 30 secs on each slide. The slides keep changing automatically after 30 secs, so that presenter continues the discussion in the next slide automatically

02:35
03:00
  • Added to My Schedule
    keyboard_arrow_down
    Gautam Rege

    Don't test your code!

    Testing is overated. Let's correct that statement - "Manual Testing is overrated". In this this talk, I plan to take you on whirlwind tour of why an Agile outfit does not need manual testing at all and how to get fantastic Quality Assurance without manual testing.

    In this talk - I outline a agile process with a difference - everyone is a developer and a tester. However, there is no dedicated QA people. In fact, this process does not require anyone other than the developers and one process/product owner.

    Development using a central repository like Github that is integrated with a Continuous Integration service (like Travis, CircleCI or Semaphore) and further integrated with a Code Quality checker like Code Climate or Pull Review is part of the automation trick. Then comes the development processes like pull request between branches (enabling peer code review) and Automated Deployment to a staging server.

    Finally, the pixel perfection or meeting product specificaiton via Project Management tools (which are integrated with the Code repository) gives the product owner (or the client) complete confidence in not just the functionality but also the quality of the code. 

    This approach can be applied to evolving products too and I discuss how to work in short sprints that always keep changing and guarantee that "The product owner gets the money's worth and the development team gets their works worth!".

     

  • Added to My Schedule
    keyboard_arrow_down
    Vijay Bandaru

    Scrum Master Experience Report

    This presentation brings a different perspective for the Scrum Masters and helps them to become more powerful Scrum Masters through their enhanced soft skills. I am going to cover how the teams evaolve, how the change is resisted, how the teams behave, how Scrum Master can handle all these effective to make the teams deliver working software every sprint continuously.

    The information explained below is from my experience as Scrum Master and Coach. Below are the points that will be covered in the presentation:

    Primarily I am planning to cover the anti patterns that will push the teams back and where the Scrum Master can support the teams with his knowledge, experience and interpersonal skills. For example please find below some scenarios:

    1. In effective sprint planning: Team might miss some of the tasks while doing the sprint planning part 2 so they will anyway identify them during the development of the stories so these tasks take additional time which is not budgeted. So they will have to miss some stories which will impact the sprint goal. So I encourage the scrum masters to collect all such unidentified tasks on a separate colr sticky notes and during retrospective discuss with the team to see how much % of the capacity is gone for that tasks. At the same time are there any tasks in that list can be repeatable tasks (Eg: Code review) so this will help the team to come up with a tasks checklist which will help the teams to do effective sprint planning part 2 

    2. Partially ready stories pushed into the sprint: Sometimes product owners push the stories that are not fully ready and the team cannot say "No" in this case either the story gets changes during the sprint or it cannot be finished due to unknown factors. So Scrum Master to encourage the team to have a proper DOR (Definition of Ready) and get a working agreement between the PO and team so that they will work around it whilst they understand "Responding to change over following a plan"

    3. Cross functional behavior: Team generally does not want to become cross functional because they are fine with what they are. Scrum Master has to bring a change in their thought process and get them agreed to become cross functional. For this it takes time so SM has to also manage the management expectations with respect to set the expectation in the dip in productivity

    4. Pale retrospectives: This is another area where Scrum Master has to provide support to teams and get the liveliness and make the teams high performance teams

    5. Timeboxing: Most of the teams do not respect this important guideline. Again SM has to get the importance of this characterstic in to the teams and get them aligned towards this. So there are some examples which I can quote such as if different people arrive at different timings, how much time is wasted and how many times we need to recap on the points already discussed, how much gap created etc

    6. Stop starting and start finishing: This will cover to complete the stories/tasks that you are working before you pick up something. In general the teams pick up many items at a time and complete them close to 100% but not 100% so this will impact the sprint goal. In such case the SM has to provide inputs to the team to pick as few as possible but close them as soon as possible so this way the value delivery at the end of sprint is guaranteed

    7. Lack of importance for quality: In the hurry of completing the stories the team at times give less or no importance to the quality. So the probability of escaped defects or getting rejection for the stories is high. So the Scrum Master has to educate the teams to strictly define/refine/follow the Definition of Done for each story. I saw many teams having their DOD in the tools like VersionOne but not infront of their eyes. 

    8. I know when I see it: Information radiators. This will be the key for the teams to adjust their pace as per the principle #8. So creating big visible information radiators and updating the underlysing details frequently will bring attention in the team and they naturally tend to adjust their delivery mode as per the requirement 

     

  • Added to My Schedule
    keyboard_arrow_down
    Ankur Sambhar

    Promiscuous Pairing - More the merrier !!!

    Being Agile developer, have tried & tested various flavors of pair programming over the years while working in highly motivated self-managed team. Some experiments worked while some worked better :)

    This talk is about sharing the personal experience of practicing promiscuous pairing which allowed the team to be always in the beginner's mind state and being able to push the boundaries consistently.

    This experience sharing talk is based on our successful adoption of the promiscuous pairing technique based on very famous research paper by Arlo Belshee "Promiscuous Pairing and Beginner’s Mind: Embrace Inexperience".

03:30
  • Added to My Schedule
    keyboard_arrow_down
    Vinod Kumaar R

    Build it like sports teams

    Is it easy to get a crash course in football by Pele or Maradona for a week and produce a world cup winning football team?

    Answer is NO. Then why do lots of people in the corporate world think of hiring scrum trainers & expert developers to train their team for a week and then expect their team to undergo a transformation at a magical scale?

    German football team made it a point to transform their team and it took them a lots of years before they were able to reach the pinnacle. A quick side by side comparison of what is causing agile transformation to fail.

    Vision

    Football: Someone was there owning this entire transformation, the German football association spent a lot of time identifying talent in their teens and groomed them.

    Office: In the corporate world switching jobs every few years have become common, but there is no passing on of the context, resulting in the new person taking charge, starting from all over again, as well as frustrating existing good performers who have to rebuild the perception.

    Infrastructure

    Football: Players expecting state of the art training facilities, fitness programs and new shoes are not a luxury, it is a necessity.

    Office: Computers have become so cheap compared to the salaries, yet the policy of providing the best tools and good work environment are archaic.

    Coach vs Management

    Football: Coaches are given their due powers to help the team achieve the goal. It is very easy for anyone to comment on how professionals should play their game, there would be no use adhering to the metrics if the team cannot win. Winning is the only measure for management.

    Office: Often coaches are seen as part of the management or management tries to heavily influence coaching which results in a team which will work either for metrics or to please higher ups without the actual result that it had aimed for.

    Training

    Football: Just the ability to kick the ball does not make a footballer. Training will be introduced to increase physical strength & stamina, better mental wellness, injury prevention, tactics and strategy.  A heavy investment is made in the training facilities.

    Office: In the software industry a generation is about 2-3 years. Computer science degrees are nowhere near what is state of the art in the industry. At many places the on boarding process is either very shallow or not up to date with the recent developments, leaving people to learn most of the things hard way. Given too many things to learn and the information overload, this results in inefficient learning and application of knowledge on the job. We need to prepare people to find answers that are not available on Google.

    Team composition

    Football: Rookies don’t learn by watching greats from the bench, instead they play along with the veterans. Every sports team makes sure to have the right composition with a mix of rookies, emerging players and veterans. That is how they sustain a winning team.

    Office: Architects and Leads often do not code or are not part of the team every day, this means that most of the time the team just looks up to for advice or waits for reviews. There should be a good mix of people at all experience level so that there are enough people to try new things, enough people who have mastered few things and enough people who challenge change.

    Above all – Persistence

  • Added to My Schedule
    keyboard_arrow_down
    Karthik Kamal Balasubramaniam

    It's not an Agile story

    Having worked with multiple Agile teams, I realize that most problems the teams have to deal with are often related to issues that are beyond the scope of any Agile framework. These issues are often related to people and the surrounding eco-system. The success of any Agile implementation is largely dependent on this H(uman)-factor which is intrinsic to any team/organization. This H-factor has always been a pandora's box, that we would like to avoid owing to  the amount of complexity and the uncertainty involved.

    Here is my humble effort to try and identify few common traits that I have observed with people across Agile teams and organizations. The idea here is not to stereotype people, but to present an approach/strategy to accommodate different kinds of people in an Agile eco-system.

    In this talk, I would like to present 5 characters in a fictional story and the various strategies I have adopted to coach them.

    After all one size doesn't fit all!

03:45
  • In this highly engaging workshop attendees will experience estimating, planning and delivering a new product and product features.  The uncertainty in value and costs will be resolved through rolling dice based on the stories that the team selects and prioritizes.   The teams will run through 3 iterations of story cost, value estimation, and product feature delivery.  Points will be scored for delivering product features and meeting release and iteration commitments. 

    Dealing with uncertainty is one of the largest challenges that teams face.  The simulation aims to have levels of uncertainty in value and delivery that are commensurate with those found in software development.  Some of the key tools for dealing with uncertainty are integrated into the simulation.  In particular, the simulation covers these 4 areas:

    • Value of Information
    • Value of Flexibility
    • Cost of Delay
    • Value of Uncertainty

    Attendees will come away with a better understanding of the challenges of working with uncertainty in software projects, and will learn some of the tools that are at their disposal for managing this uncertainty.

04:30
  • We've come far in our journey of Agile as a software development methodology. From stand-ups to showcases to sprint planning meetings to burn-ups (or downs), we've got it down pat when it comes to processes to follow to be considered Agile. However this heads-down, process defined agile, often hinders real agility required to meet business needs. Is doing a three hour sprint planning meeting every week the most important thing to do when you have to get a minimal-viable-product out in the market? How much of automated functional testing should you do when you know that your product's beta version is only going to validate assumptions of your business idea? Should you write tests at all? There is no formulaic answer.

    In this talk, KK and Krishnan will talk about their experience of how much Agile is too much Agile. We look at how to find the right balance between following agile practices and being responsive to your business. How much agile is too much and how less is too less?

    We will do this by looking at:

    • A couple of successful agile adoption stories
    • Look at why agile was successful in the contexts above
    • Discuss why this success will limit us if we are not careful
    • Talk about a start-up and how the things that led to success in the first 2 stories limited us in the start-up context
    • Look at approaches to understand what agile practices/processes to follow to be business agile
    • Close by summarizing the challenges facing agile (as we see it) and how success in process agility will limit us in business agility
04:40
  • As more and more companies are moving to the Cloud, they want their latest, greatest software features to be available to their users as quickly as they are built. However there are several issues blocking them from moving ahead.

    One key issue is the massive amount of time it takes for someone to certify that the new feature is indeed working as expected and also to assure that the rest of the features will continuing to work. In spite of this long waiting cycle, we still cannot assure that our software will not have any issues. In fact, many times our assumptions about the user's needs or behavior might itself be wrong. But this long testing cycle only helps us validate that our assumptions works as assumed.

    How can we break out of this rut & get thin slices of our features in front of our users to validate our assumptions early?

    Most software organizations today suffer from what I call, the "Inverted Testing Pyramid" problem. They spend maximum time and effort manually checking software. Some invest in automation, but mostly building slow, complex, fragile end-to-end GUI test. Very little effort is spent on building a solid foundation of unit & acceptance tests.

    This over-investment in end-to-end tests is a slippery slope. Once you start on this path, you end up investing even more time & effort on testing which gives you diminishing returns.

    In this session Naresh Jain will explain the key misconceptions that has lead to the inverted testing pyramid approach being massively adopted, main drawbacks of this approach and how to turn your organization around to get the right testing pyramid.

05:30

    Fishbowl - 60 mins