Final Schedule is now available...   |   Attend the World's First Agile Job Fair   |   Join us for Agile Art!
Nokia Maps Agile Journey.....(Agile Transformation, Scaling and Overcoming Challenges)
66
Allen Rutzen
Allen Rutzen

We (at Nokia Maps Division) began our Agile Journey in 2009, with a Top Down approach for Agile Transformation. The formation of an Agile Working Group (with members having Agile experience behind them) at two major sites was instrumental in shaping the transformation and scaling and also overcoming the challenges from time to time.

The challenges were huge, but our spirit was bigger, and the high level strategy was decided. Interestingly, the Agile Working Group itself ran the whole Transformation and Scaling program using Agile values and Scrum frame work. Scrum was also used as the preferred framework for the agile projects (after success in our pilots), except where Scrum would not work. Kanban or hybrid methods were used in those few teams.

What were the challenges faced, and how did we overcome them? What values helped us in our transformation journey?

How did we migrate to the Scaling phase? What helped us in scaling and stabilizing?

Can we rest easy now? Of course not!

What are the next steps? And of course, the challenges ahead?

Let us share our Nokia Agile journey with you, and help you all be successful too, in your Agile journey!

Duration:45 mins
Type: Talk
Level:Intermediate
8 months ago by Allen Rutzen

Travelogue - To LeanVille
24
Harish Krishnaswamy
Harish Krishnaswamy

The webMethods R&D division of Software AG (wM) produces industry-leading enterprise products focused on application integration, business process integration and B2B partner integration. This division with more than 450 engineers across 7 locations in the world embarked on the journey of adopting Agile and Lean Software Development practices in 2010.

The Pain

The wM business line consists of about 40 Scrum teams delivering more than 30 enterprise products that constitute the webMethods suite across 7 locations in the world. Circa 2007, the suite was a loose collection of multiple products individually developed by teams, many of which were brought together by M&As. It was a hard, painful challenge to integrate and test these products as a single suite and synchronizing major releases. The teams embraced Scrum as the development model - a useful first step but still far from guaranteeing predictability, high standards of quality and productivity at the suite level.

The Challenge

  • Align multiple, small scrum teams distributed over many locations to one Suite Backlog. Focus them on delivering an integrated Suite by modeling an assembly line from a Lean Manufacturing system. The teams develop and contribute to a single value stream with continuous flow and deliver potentially shippable Suite Build Sets in predictable intervals (4-6weeks).

  • Retain the simplicity of the ‘Agile model’. Allow teams to grow at their pace. The teams work off their individual team backlogs, the suite complexities and priority conflicts largely hidden from them. They experiment with their processes, drive their own local changes and share the learning with the other teams.

 Success:

Since embracing Lean and Agile practices, we have delivered three successful major Suite releases on time with measured quality. The customer situation has dramatically improved with steadily decreasing customer incidents, response times and hot escalations. More than a 100,000 automated regression tests  verify the suite and we have a potentially shippable Suite build set every 4-6 weeks guaranteeing the highest standards of quality. For faster value delivery, we are now transitioning to 6-monthly releases – the first of which is due to roll out in Q4 2013.

In this Experience report, I focus on how we aligned scrum teams operating from Germany, U.S, Bulgaria and India to a single backlog, a continuously integrated Suite and a potentially shippable single build set delivered every 4-6 weeks. We will look at the challenges we faced, custom solutions and processes that we designed to realize the Single Suite Vision.

Duration:20 mins
Level:Intermediate

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

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.

Duration:20 mins
Level:Beginner

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

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

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

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

Why did we did this?

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

Let’s complicate this further.

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

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

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

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

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

My experience

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

Duration:20 mins
Level:Intermediate

Remote Pair Programming
15
Johannes Brodwall
Johannes Brodwall

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.

Duration:45 mins
Level:Beginner

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

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

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

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

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

Here are some of the dilemmas we faced:

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

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

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

-          When and how should load testing be performed?

-          Automated v. manual testing

-          What testing should be part of the CI process?

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

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

Duration:45 mins
Type: Case Study
Level:Intermediate
»
beyond-agile  
×
»
45_mins  
×
case-study  
×
intermediate  
×

qa  
×
7 months ago by Roy Nuriel

Continuous Deployment for iOS Game Development
14
Naresh Jain
Naresh Jain

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

Duration:45 mins
Level:Intermediate
8 months ago by Naresh Jain

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

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.

Duration:20 mins
Level:Beginner
» »
20_mins  
×
beginner  
×

7 months ago by Sreerupa Sen

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

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.

Duration:90 mins
Type: Workshop
Level:Advanced
8 months ago by Naresh Jain

Robotic Warehouses, Alien Domain, Offshore developers, Visionary customer : Saved by agile
13
Vinodhini
Vinodhini

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

Duration:20 mins
Level:Intermediate
8 months ago by Vinodhini

Revving up Scrum with Blitz – Collaborative workshop to organize the Epic backlog
46
Karthik V
Karthik V

Most features have a lead time before Requirements, Architecture and Epic Backlog is available to the scrum team. There is a misconception that these Sprint zero, or planning Sprints are the way of Scrum but are actually waterfall methods. Also this approach doesn’t essentially lead to team empowerment of the product backlog during sprint execution.

Blitz – brings in a time boxed intense collaborative approach with involved stakeholders and scrum team agreeing on requirements, architecture, acceptance criteria and product backlog priorities. This is part of the Scrum execution cycle rather than a Sprint 0/Planning exercise.This brings in a parallel and lean approach to expedite a refined development ready product backlog.

This is an approach executed at various projects to reduce the feature delivery timeline and understand/minimize the unknowns.

Duration:45 mins
Type: Case Study
Level:Beginner
» »
45_mins  
×
case-study  
×
beginner  
×

7 months ago by Karthik V

SAMPLE PROPOSAL - Product Discovery Workshop
36
Naresh Jain
Naresh Jain

Many product companies struggle with a big challenge: how to identify a Minimal Viable Product that will let them quickly validate their product hypothesis?

Teams that share the product vision and agree on priorities for features are able to move faster and more effectively.

During this workshop, we’ll take a hypothetical product and coach you on how to effectively come up with an evolutionary roadmap for your product.

This 90 mins workshop teaches you how to collaborate on the vision of the product and create a Product Backlog, a User Story map and a pragmatic Release Plan.

This is a sample proposal to demonstrate how your proposal can look on this submission system.

Duration:90 mins
Type: Tutorial
Level:Beginner
» »
90_mins  
×
tutorial  
×
beginner  
×

product-owner  
×
agileux  
×
workshop  
×
8 months ago by Naresh Jain

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

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

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

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

Why did we did this?

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

Let’s complicate this further.

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

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

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

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

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

My experience

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

Duration:20 mins
Level:Intermediate

Applying Agile Practices in the Refurbishment/Modernization of my housing society
15
Zaheerabbas Contractor
Zaheerabbas Contractor

In the rush to be a proud owner of a large independent penthouse apartment in a huge housing society I did not realize (or did not want to) the actual reason behind this good bargain!

I ended up being party to the following list (product backlog) of pain areas (or business needs) of the society members:

  • 1.Need of Generator backup to cater to the frequent power cuts at least for the common areas and lifts (I had bought my condominium on the top floor and could realize the pain!) – Must have and High Cost
  • 2.Modernization of the ageing lifts across 18 buildings (thanks to the substandard quality lifts which I realized when I started staying there L ) – Must have due to high risk however huge Cost
  • 3.Need for the CCTV Camera – Must have considering the frequent untoward incidents
  • 4.Seepage and septic tank upgrade
  • 5.Pavements, speed breakers
  • 6. And the list goes on….

This resulted into the society being least valued in that area and no ROI for the members who had invested in the society.

The society committee members were clueless on where to start (prioritizing with business value) with the given evolving budget and how to manage the timeline.

 Through this report, I intend to share how I utilized following Agile practices to overcome the challenges faced by the society members for its refurbishment and converted the society into one of the most sought out society over the period of few milestones (releases)!

  • 1.Prioritization(MoSCoW) of the backlog by agreeing up urgent need of the society in the given budget
  • 2.Continuous planning and re-prioritization of product backlog
  • 3.Outcome(Value) based agreement with various vendors
  • 4.Managing discipline in the acceptance criteria and retrospection (i.e. PWD lift inspection and approval for lifts functioning with the given municipality specifications and taking learning to replicate the same for future enhancements)
  • 5.Delivering end to end(INVEST) in the production in short releases ( i.e. one lift modernization end to end and commissioning of Diesel Genset end to end through incremental approach)
Duration:45 mins
Type: Case Study
Level:Intermediate
» »
45_mins  
×
case-study  
×
intermediate  
×

dod  
×
invest  
×
moscow  
×
8 months ago by Zaheerabbas Contractor

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

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

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

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

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

Here are some of the dilemmas we faced:

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

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

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

-          When and how should load testing be performed?

-          Automated v. manual testing

-          What testing should be part of the CI process?

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

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

Duration:45 mins
Type: Case Study
Level:Intermediate
»
beyond-agile  
×
»
45_mins  
×
case-study  
×
intermediate  
×

qa  
×
7 months ago by Roy Nuriel

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

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.

Duration:20 mins
Level:Beginner
» »
20_mins  
×
beginner  
×

7 months ago by Sreerupa Sen

The Bollywood tale of an Agile team
13
Joe Zachariah
Joe Zachariah

Often times, as an organization matures into its Agile adoption space, many people begin to start looking at Agile as just another process, and forget that the one of the main tenets for Agile is 'People over Processes'. Ultimately we are all here to build exciting, quality assured, on time and within scope products and along the way also have some fun. But what if the team does not gel well together, to such an extent that it begins to affect the quality of the deliverables?

That's the time when we need to look within our bucket of Agile best practices to understand which of those we can employ to even build a stronger team. Practices such as pair programming, continuous builds, retrospectives, etc. are all best practices which when employed at the right moment and at the right time, can help a team get together. 

In this presentation, I am putting together a few songs from Bollywood movies, to describe in a fun way a team's transition through the four stages of team building - forming, storming, norming and performing. And how using some Agile best practices, the team could tide over the storming phase and move over to the performing phase. 

This will be a 20 minute presentation, in which the first 5 minutes I will be talking, followed by about 15 minutes of a fun video which would be a mish mash of Bollywood songs highlighting all that my team went through in their Agile journey

Duration:20 mins
Type: Others
Level:Beginner
» »
20_mins  
×
others  
×
beginner  
×

teams  
×
scrum  
×
scrum-teams  
×
bollywood  
×
laughs  
×
fun  
×
7 months ago by Joe Zachariah

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

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.

Duration:90 mins
Type: Tutorial
Level:Advanced
»
beyond-agile  
×
»
90_mins  
×
tutorial  
×
advanced  
×

8 months ago by Giovanni Asproni

The different engagement models, processes, challenges and solutions for a distributed Scrum Team in an outsourced product development (OPD)
9
Pooja Wandile
Pooja Wandile

A distributed Scrum team is a necessity than a choice in many cases. Often customers and their suppliers struggle to put up a team model that will work effectively and provide maximum value. The customer wants to be absolutely sure how the entire engagement will be executed so that there are no surprises later.

So, what are the different ways of forming teams in a distributed environment, what is the impact on the execution, how do you execute different engagement models, what challenges do you see and so on? These are the questions the customers are interested in.

This talk will focus on answering the above questions. We have defined 3 types of distributed team models and implemented in few of the projects in an onshore-offshore scenario. We have also tailored scrum meetings like planning, DSM, etc. so that these meetings are more effective in distributed model. While some of the changes have worked, some still needs to be enhanced further.

 

Duration:45 mins
Type: Talk
Level:Beginner
» »
45_mins  
×
talk  
×
beginner  
×

8 months ago by Pooja Wandile

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

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

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

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

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

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

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

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

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

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

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

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

Duration:45 mins
Type: Talk
Level:Beginner
»
beyond-agile  
×
»
45_mins  
×
talk  
×
beginner  
×

coaching  
×
learning  
×
inspire  
×
reflection  
×
7 months ago by Victoria Schiffer

Nokia Maps Agile Journey.....(Agile Transformation, Scaling and Overcoming Challenges)
66
Allen Rutzen
Allen Rutzen

We (at Nokia Maps Division) began our Agile Journey in 2009, with a Top Down approach for Agile Transformation. The formation of an Agile Working Group (with members having Agile experience behind them) at two major sites was instrumental in shaping the transformation and scaling and also overcoming the challenges from time to time.

The challenges were huge, but our spirit was bigger, and the high level strategy was decided. Interestingly, the Agile Working Group itself ran the whole Transformation and Scaling program using Agile values and Scrum frame work. Scrum was also used as the preferred framework for the agile projects (after success in our pilots), except where Scrum would not work. Kanban or hybrid methods were used in those few teams.

What were the challenges faced, and how did we overcome them? What values helped us in our transformation journey?

How did we migrate to the Scaling phase? What helped us in scaling and stabilizing?

Can we rest easy now? Of course not!

What are the next steps? And of course, the challenges ahead?

Let us share our Nokia Agile journey with you, and help you all be successful too, in your Agile journey!

Duration:45 mins
Type: Talk
Level:Intermediate
8 months ago by Allen Rutzen

WORKSHOP- Defining Behaviors as a team
43
Pradeepa Narayanaswamy
Pradeepa Narayanaswamy

In lot of agile teams, often times, all the team members will be doing the grooming and planning exercise as a team. Often times, defining the behaviors is either ignored, overlooked, skimped or done by individuals on their own without a common understanding as a team.

To solve this problem, I have used this hands-on time-boxed activity for all of my teams to define behaviors as they move along in the sprint. This will help all the team members to have a shared understanding on their users and their behaviors as it relates to their user story. This is an activity that any agile team member can take and implement the next day at work.

 

 

Duration:45 mins
Type: Workshop
Level:Intermediate
» »
45_mins  
×
workshop  
×
intermediate  
×

agile  
×
beginner  
×
benefits  
×
team-activity  
×
8 months ago by Pradeepa Narayanaswamy

We're Moving to Agile: What Do I Do with My testers?
42
Pradeepa Narayanaswamy
Pradeepa Narayanaswamy

As more and more organizations are transitioning to Agile, there still exist a lack of understanding on how testing fits in the Agile teams. Is it just about placing a tester in every team? How can we realign the team members including testers from being on silos to an effective cross-functional team? Pradeepa Narayanaswamy shares her insight on the key basics of Agile testing along with understanding the Agile testing mindset and testing goals. Pradeepa also shares her ideas on how to manage defects, what to measure as metrics and what to document. Learn what you need to know as a tester who are new to Agile. If you are an experienced Agile tester, review these important basics and realign the concepts that may have been overlooked or forgotten in your teams.

 

 

 

Duration:45 mins
Type: Talk
Level:Beginner
» »
45_mins  
×
talk  
×
beginner  
×

8 months ago by Pradeepa Narayanaswamy

Agile Testing- What is my success mantra??
40
Pradeepa Narayanaswamy
Pradeepa Narayanaswamy

As more and more organizations are transitioning to agile, it’s inevitable that Agile testing is not just a concept any more. It is also not just about placing a tester in every team. What is so radically different now? How to be successful at agile testing? How to be an effective cross-functional team that embeds and honors all specialties including testing?

In this presentation, I am going to share my teams’ success with Agile testing and how we incorporated these 3 aspects – people, process and tools/techniques. This talk will benefit any members in an organization who has a stake in the product quality. It is also highly beneficial for those agile testers (from aspiring to veteran) to understand the 3 main aspects as it relates to testing and why we need to embrace- not just one, not two, but all these 3 aspects to be successful in Agile testing. 

 

 

Duration:45 mins
Type: Talk
Level:Beginner
» »
45_mins  
×
talk  
×
beginner  
×

agile-testing  
×
testing  
×
qa  
×
8 months ago by Pradeepa Narayanaswamy

Come! Take a plunge with us into the world of Self Organization!
36
Kanchan
Kanchan

In agile teams there is a belief that the teams self organize. But do we really understand what this really means? The scrum guide simply says three things autonomous, self transcendent, cross functional.

In this interative workshop we will experience what self organization is all about via a fun filled game. You will go back with key learnings through your own experience. 

This session will be a combination of audience participation in activities, discussions combined with presentations and loads of fun!

This interactive game session is for anyone who wants to learn more about  being self organized and what makes the self organized teams tick.

Duration:90 mins
Type: Workshop
Level:Intermediate
» »
90_mins  
×
workshop  
×
intermediate  
×

8 months ago by Kanchan

Step-by-Step Process for Release Planning and Release Level Retrospectives
31
Ankush Sabharwal
Ankush Sabharwal

In the session two processes will be explained viz. Release Planning and the Release Level Retro. Step by Step approach will be discussed so that the same can be readily used in your Agile Projects.

I have created these approaches of conducting effective Release Planning and Release Retrospectives in Agile projects. I have used these processes in various successful Agile projects.

 

Note: Please refer to the Links section below to see the steps invoved in both of these processes.

Duration:45 mins
Type: Tutorial
Level:Intermediate
8 months ago by Ankush Sabharwal

Can India be truly Agile?
30
Joe Zachariah
Joe Zachariah

It's Indian Independence day today as I work on this proposal. As I read newspapers today, I understand the importance of the IT and ITES Offshore business, which has almost single handedly provided employment to millions of technically suave and English speaking folks. One question that repeatedly comes to surface is whether the Indian IT industry will be able to up its game from the servicing mentality which started the boom of IT in India. As Agile and Scrum began to become the flavour of the worldwide IT industry, many firms in India also went out on the Agile path, many of them out of pressure from their Western clients. Some of them were successful, but there are also numerous examples of failures of the Agile model and also half hearted adoptions, which have led Western businesses to believe that maybe India is not adept enough to take its game to the next level where teams can follow the Agile framework.

My talk would be driven by my experiences of following Agile in different ways in my different teams over the last 6-7 years. My forays into the Agile ways of software delivery in India have been largely successful and I cannot see a reason why Agile will not work in India.

In my talk, I would focus on the reasons on why Agile would work in India. Right from the way we approach diversity and inclusivity, to the way we approach our post election coalition party governance model, the Indian way of living is rife with finding innovative ways to quickly adapt to change, which essentially is the Agile mantra.

I plan to start with a simple example. Of the Western way of cooking & dining as compared to the Indian way of cooking & dining. A traditional Indian kitchen is a sacred space. It is decorated with auspicious signs. Sometimes, it doubles up as a puja room. In many households, you are not allowed to enter the kitchen with footwear, you are expected to bathe before lighting the kitchen fire, you are not allowed to eat unless you have taken a bath - these can be metaphorically compared with the Ceremonies that an Agile team practising Scrum follows - the daily standups, sprint planning and reviews, etc. However the core delivery is the food. And no matter what ceremonies you follow and what your menu for the day is, the food comes out daily at the same time and is served everyday with the same set of stakeholders. There aren't as many tools and supporting equipment that you might see as in a Western kitchen, but at the end of the day the practices followed in a typical Indian kitchen are very Agile at heart.

There are many other examples from Indian culture and mythology that one can refer to understand that Indians are essentially Agile at heart. Open source product groups, many of which are largely Agile, can also find a reference point in Indian culture and mythology. That which is timeless is referred to in the Indian context as Sanatan. It refers to wisdom that has no founder and is best described as collaborative and open source freeware. Every idea is accepted but only that which survives the test of time, space and situation eventually matters.

There are many myths circulating in the IT industry that Agile cannot survive in India, since Indians cannot be trusted to be self governed and always require direction. Also Indians don't know how to have fun at work. Through my presentation I seek to dispel those myths drawing from Indian mythology and culture and essentially try to make folks understand that reasons for Agile not working in India is the same as Agile not working elsewhere. What you need to make Agile work at the end of the day, is just the belief that it will work.

Duration:45 mins
Type: Talk
Level:Beginner
» »
45_mins  
×
talk  
×
beginner  
×

8 months ago by Joe Zachariah

Learn from Mistakes, Retain Your Strong Holds: Sprint Retro: Do As WE Do at John Deere
28
Shrawan Gaur
Shrawan Gaur

As the 12th Agile Principle states : "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.", it is quite easy to understand the importance of continuous evolvement which involves retaining learning and corrective actions.

John Deere has started its Agile journey in year 2010 and since then has gone through various phases of transformation. Scrum teams has learnt alot and are continuously learning. Retrospection is one of very important scrum ceremony which paves path for team to advance in right direction.

Here, I will demonstrate some retro techinques and its applications according to sprint work.

Duration:45 mins
Type: Talk
Level:Beginner
» »
45_mins  
×
talk  
×
beginner  
×

scrum_masters  
×
retro  
×
8 months ago by Shrawan Gaur

Agile doesn't improve quality. Can we release a world class product?
27
Jayaprakash P
Jayaprakash P

There is a common concern by management that Agile doesn’t make a difference to the product quality. How do we release a product of world class quality?

 Problem is two folded:

  1. 'Definition of Done' is not created with Quality in mind, nor is it measured against the quality set at the beginning of the project.
  2. Quality Goals and subsequent adherence ensures quality is met and not just meeting 'Definition of Done' (DOD) criteria. For example DOD may be met, but quality may still be poor if not managed appropriately. How – lets discuss this through the session.

 Once the quality goals are defined for a project, Definition of Done should align with these quality goals.

At McAfee, we have released world class quality products through Agile Methodology and Quality Best Practices together. One exceptional method we practice is by defining and tracking "Effective Quality Goals" for each sprint, and at every release.

By driving agile projects through quality goals, we have products with ZERO defects deferred / logged by customers, 90+% code covered through automated test, 70% defects found early through development practices. This magic was not in just one project, but close to a dozen projects in the last 3-4 quarters.

In this presentation, we will explain about how we changed the paradigm in the last 2 years and released world class quality products in a short span of time.

Duration:45 mins
Type: Tutorial
Level:Intermediate
» »
45_mins  
×
tutorial  
×
intermediate  
×

qa  
×
8 months ago by Jayaprakash P

Travelogue - To LeanVille
24
Harish Krishnaswamy
Harish Krishnaswamy

The webMethods R&D division of Software AG (wM) produces industry-leading enterprise products focused on application integration, business process integration and B2B partner integration. This division with more than 450 engineers across 7 locations in the world embarked on the journey of adopting Agile and Lean Software Development practices in 2010.

The Pain

The wM business line consists of about 40 Scrum teams delivering more than 30 enterprise products that constitute the webMethods suite across 7 locations in the world. Circa 2007, the suite was a loose collection of multiple products individually developed by teams, many of which were brought together by M&As. It was a hard, painful challenge to integrate and test these products as a single suite and synchronizing major releases. The teams embraced Scrum as the development model - a useful first step but still far from guaranteeing predictability, high standards of quality and productivity at the suite level.

The Challenge

  • Align multiple, small scrum teams distributed over many locations to one Suite Backlog. Focus them on delivering an integrated Suite by modeling an assembly line from a Lean Manufacturing system. The teams develop and contribute to a single value stream with continuous flow and deliver potentially shippable Suite Build Sets in predictable intervals (4-6weeks).

  • Retain the simplicity of the ‘Agile model’. Allow teams to grow at their pace. The teams work off their individual team backlogs, the suite complexities and priority conflicts largely hidden from them. They experiment with their processes, drive their own local changes and share the learning with the other teams.

 Success:

Since embracing Lean and Agile practices, we have delivered three successful major Suite releases on time with measured quality. The customer situation has dramatically improved with steadily decreasing customer incidents, response times and hot escalations. More than a 100,000 automated regression tests  verify the suite and we have a potentially shippable Suite build set every 4-6 weeks guaranteeing the highest standards of quality. For faster value delivery, we are now transitioning to 6-monthly releases – the first of which is due to roll out in Q4 2013.

In this Experience report, I focus on how we aligned scrum teams operating from Germany, U.S, Bulgaria and India to a single backlog, a continuously integrated Suite and a potentially shippable single build set delivered every 4-6 weeks. We will look at the challenges we faced, custom solutions and processes that we designed to realize the Single Suite Vision.

Duration:20 mins
Level:Intermediate