Scaling Agile Adoption
Registration - 30 mins
In the last decade or so we've seen a number of new ideas added to the mix to help us effectively design our software. Patterns help us capture the solutions and rationale for using them. Refactoring allows us to alter the design of a system after the code is written. Agile methods, in particular Extreme Programming, give us a highly iterative and evolutionary approach which is particularly well suited to changing requirements and environments. Martin Fowler has been a leading voice in these techniques and will give a suite of short talks featuring various aspects about his recent thinking about how these and other developments affect our software development.
Coffee/Tea Break - 15 mins
It is easy to envision a more Agile enterprise, yet we have found as a community it is quite difficult to accomplish. The transformation process goes on in many dimensions and unless we have a framework that helps us see from each of those perspectives, our efforts are much more likely to fall short. Based on Michael Spayd's upcoming book, Coaching the Agile Enterprise, this session will (literally) walk you through each of the four fundamental perspectives and the power and limitation of each. We will explore together approaches that are suitable to each perspective and how to activate them in your team, division or organization.
Traditional models of management and corporate governance are failing to keep up with the needs of the modern economy. Change, both technological and cultural, is occurring at faster rates than ever before. In this climate, modern enterprises will live or die on their ability to adapt. This is where Agile, and Agile Business Management, come in. Agile is change; changing how you think, changing how you work and changing the way you interact. This is important whether you are a software developer or a CEO.
In this presentation, Evan will provide engaging and enlightening case studies of Agile beyond IT; from lean startups to large enterprises. These will be reinforced with practical approaches for the leadership of teams, divisions and businesses.
Taking the successful concepts and methods from the Agile movement and Evan's new book, Agile Business Management is a framework for the day-to-day management of organisations regardless of industry, size or location. We will discuss processes, techniques, and case studies for the 4 key domains from Agile Business Management;
- You, the Agile Manager - What makes a good manager and how do their responsibilities change?
- Integrated Customer Engagement - Collaboration and communication techniques to build trust and deliver Customer needs efficiently, with minimal waste, and to everyone's satisfaction.
- The Structure of an Agile Organisation - Efficient, transparent and collaborative techniques to manage empowered staff.
- Work, the Agile Way - Managing all types of business functions, from software, HR, finance to legal, by using Just-In-Time planning and Incremental or Continuous Delivery processes.
Ultimately, the goal of this presentation is to make you think about your role as a leader.
4 favorite_border 4forum
Achieving Enterprise Agility with the Scaled Agile Framework...and Have Fun Doing It!
Scrum, XP, Kanban and related methods have been proven to provide step changes in productivity and quality for software teams. However, these methods do not have the native constructs necessary to scale to the enterprise. What the industry desperately needs is a solution that moves from a set of simplistic, disparate, development-centric methods, to a scalable, unified approach that addresses the complex constructs and additional stakeholders in the organization—and enables realization of enterprise-class product or service initiatives via aligned and cooperative solution development.
Ever wondered what it's like to experiment in Agile? Ever thought when you started to scale Agile, you would get it right first time? Ever thought Agile adoption is full of experiments? We did! This session explores real world learning and observations when attempting to mature organisations from single team project based Agile to a Scaled Agile framework.
This will be a fun and interactive session where will be using live experiments that highlight the purpose, result and our observations. Each experiment, as any Agilist would attest to, creates more unanswered questions, additional problems to solve and more opportunities to try out new hypotheses.
Creating a Global Engineering Culture
Lunch - 60 mins
‘One bad apple soils the barrel’ is a very true saying even in an Agile environment. Not identifying and managing poor behavior and performance can completely undermine any Agile transformation effort.
How can Leaders, both within and external to Agile teams, set higher standards of accountability and hold people to it? Is self organization, peer pressure and the wisdom of the crowd enough to handle the wiles of organisational psychopaths?
The fact remains that most teams will have a few difficult personalities and underperforming members.
Agile is seen in many senior management circles as a softer, less accountable, way of working. Is that true?
This talk will delve into how the human psyche works, drawing on latest studies in neuro and psycho analysis, combined with Harvard studies, to outline the best ways to define, identify and deal with ‘bad apples’ in an Agile environment while honouring the values and principles of Agile
Agile processes are the new order of IT implementations. These talk will elaborate on our experience and learnings during agile process implementation at Walmart.
We will touchupon following 3 key areas and our learnings that helped us scale agile in large enterprises.
- Process Visualization - Our learnings related to visualization of existing processes and practices and how it helped us identify signals from noise
- Product Backlog Elaboration - In a complex and large programs product backlog management and role of product owner needs to be revisited.
- Team Working Agreement - This is particulary crucial for scaling agile as dependency management is one of the key aspects of enterpsie agile implementation.
We will conclude with our key learning of how processes needs to be continuously evolved in large scale implementation.
- Process Visualization - Our learnings related to visualization of existing processes and practices and how it helped us identify signals from noise
11 favorite_border 2forum
Scaling XP Practices inside your organization using Train-the-Trainer Model
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.
68 favorite_border 10forum
Nokia Maps Agile Journey.....(Agile Transformation, Scaling and Overcoming Challenges)
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!
The term "cross functional team" has been made popular by the Agile movement. In cross functional team, we put people with different roles to work together for a common goal/purpose.
I have seen this worked really well in many agile teams. People are no longer on silo and everyone have better understanding what each other's role is and consequently, what each other do. This leads to better self organising within the team.
However, I strongly believe we can take this concept to the new level. The concept of cross functional team should be extended to not just the team but also to the individuals within the team. Scott Ambler wrote an essay on "Generalising Specialist". The term T-shaped developer was introduced by Mary and Tom Poppendieck in her famous book "Lean Software Development". By nature, people don't like to get out of their comfort zone, hence the tendency to keep working in area that they are familiar with. When leaders can create an environment where everyone is encouraged to learn, grow and make mistakes, amazing things can happen.
In my experience leading teams, I have witnessed many transformations that enabled individuals to go beyond their traditional role, such as a manual QA assuming Scrum Master role, a BA doing deployment, a developer doing QA for a story, etc. Not only this enablement help develop the individuals to widen their horizon and skillset, it also helped the productivity of the team through better collaboration. When a team reach this stage, we no longer have problems such as "The QA has nothing to do because there are no stories to test", "The developers have nothing to do because the cannot keep up", "The deployment took longer than expected because the Ops person was not aware of the special configuration".
Are you an Agile Practitioner? Or are you responsible for Agile transformation?
Organizations that have begun their Agile journey welcome the guidance of an experienced Agile Coach. But external guidance cannot continue indefinitely as the only way to scale Agile.
If you are in an Agile team, are you prepared to take on the coaching role for other teams once your Agile Coach moves on?
If you are a manager, are you looking at grooming in-house coaches to scale and self-sustain transformation?
The transitioning of practitioners into coaches can be key to your Agile journey. Individuals get to build on their potential, while the organization becomes more self-reliant.
This session explores my personal journey from practitioner to coach. It should help you too in taking that first jump into the role of a coach. I will share real-world examples of dealing with on-the-fly situations, and of preparing upfront where possible. I will recommend resources, and mention handy techniques that should be in a coach's toolkit. The session essentially provides a kick-start for first-time coaches.
Coffee/Tea Break - 15 mins
Introducing the Kanban method through a 3-layered value system - a familiar core that stimulates and drives change, a middle layer that is about direction and alignment, and a protective outer layer of discipline and working agreements.
This humane, values-centric model aligns Kanban with the concept of the Learning Organisation and suggests ways to seek resonances with other methods. It has some practical benefits too: it can help us engage more effectively with the organisation as it currently is; it encourages us to self-reflect on our effectiveness as agents of change; it provides a convenient framework for the capture of stories.
How did one of Australia's leading financial services organisation become the biggest Agile transformation story in the Southern hemisphere and what did we learn?
The Suncorp Group leads in general insurance, banking, life insurance, superannuation and investment brands within Australia and New Zealand. The Group has 16,000 employees and relationships with nine million customers. It is a Top 20 ASX listed company with over $93 billion in assets.
In 2007, we embarked on our Agile journey of cultural change. In this talk we will cover the strategy taken, the roadblocks we came across, the mistakes we made and the achievements along the way.
You will learn how to tackle an Agile transformation, what to do and what NOT to do, where to start and what to expect and most of all what impact it will have, both negative and positive.
Today Suncorp are seen as market leaders in Agile and are known globally for the Agile Academy http://www.agileacademy.com.au/agile/ which was designed for both staff and also the external market.
The role of the Agile PMO, how to get infrastructure to work Agile, what about all those legal challenges, the cultural differences and the resistance to change? These are some of the learning we will share.
There were challenges and successes and in this honest Aussie presentation will share with you both the highs and the lows.
If I say, culture is important to adopting Agile, most people will just agree without even thinking too much about it. But what is meant by "culture"? Why is it important?
Culture is not typical behaviour; it is not what we say we value (but don't actually do). Culture is our basic assumptions of how things work. Culture is the logic we use to think through and respond to any particular situation.
If you imagine a pyramid, Agile practice and any other visible behaviour is on the top, stated or written Agile values and principles are in the middle, fundamental assumptions (aka culture) is at the base.
My session is intended to expose people to the base of that pyramid.
If culture is assumptions, then to understand Agile culture, we need to understand the basic assumptions of Agile. To do this, I have created an approach called "Think Like an Agilist" that both exposes how we think through an "Agile situation" and allows us to deliberately practice "Agile culture".
The general idea is that I won't just talk about Agile culture and values, what I'll call "culture theatre", but rather expose people, who nominally consider themselves part of the Agile culture, to their underlying thought processes and assumptions, given a relatively difficult scenario. Those thought processes and assumptions are the essence of culture (reference Edgar H. Schein). What is interesting is noting when the thought processes and assumptions are different which indicates that there is a different culture at play. What I've noticed is that this difference is common between novice vs expert Agilists.
Note that it isn't even about analyzing vs doing it mechanically but more about exposing what assumptions are being used to respond.
NOTE: I will be updating the attached slides as when I created them, I was framing it more as "doctrine" rather than "culture", defined as fundamental assumptions"
10 years ago I was introduced to Extreme Programming. Since then, I've been an avid practitioner, applying the techniques and values to my life as a software developer. Over that time, I've bounced between many extremes, learning and reflecting on the value that I get when building systems both for myself and for others.
In this talk, I'll share some of those learnings and how my life as a software developer has changed with the times.
2 favorite_border 6forum
Scaling from Project > Program > Portfolio - The Agile Transformation and Journey
The case in point is a journey of Agile transformation when the organization was looking to manage releases through shorter iteration cycles. As the journey began, the organization had to leapfrog into 3x growth in terms of both people and business needs due to a round of substantial investor funding.
The agile transformation started with just 6 teams in the organization and due to the nature of the team structure, the 3-member PMO team did not have the luxury for pilot projects and had to simultaniously roll out at one go across the 6+ component teams.
In a span of 6 months, the number of teams grew to 12+ and the number of releases more than doubled. Also, 80% of the releases cut across more than 3 teams and the challenge was to keep the process pretty lean. PMO team worked closely with key stakeholders from Product, Engineering, Architecture and Operations to forumate and roll-out a simple 3 step process that aided the teams to deliver releases better than before. Here is when the organization leaped from project to portfolio of releases cutting across 10+ themes.
Similar to what is quoted in the "Scaled Agile Framework" which the PMO tripped on much later in the process, there were organization wide prioritization done based on the product strategy, infrastructure and technology needs which eventually got translated into multiple programs within the organization, cutting across various teams. A concept of 3-in-a-box (PM, Architect and Engineering Owner) was formulated to bring in the required vigor in to the planning and execution process.The 3 in the box was further extended to Dev +QA + Ops who worked as a team to deliver the various stories across the contributing stacks.
The challenges across value-driven prioritization from 100+ releases across the portfolio, release planning with engineering and product, the execution framework and scalability in engineering infrastructure commensurate with the agile processes, working with operations teams and all the way till adoption was seamlessly scaled using the initial framework that was set for just 15 releases.
The presentation details how agile helped and is helping the product and technology teams in delivering better results than before. This would also detail the necessary Agile and operational metrics across the project teams, the program and the portfolio levels that aid the mid and senior management to take informed decisions. As always, this would not cover the IP and actual data of the organization but provide a clear framework to substantiate the process.
Scrum, XP, and Kanban have been proven to provide step changes in productivity and quality for software teams. However, these methods do not have the native constructs necessary to scale to challenges of building enterprise class software systems. What the industry desperately needs is a solution that moves from a set of simplistic, disparate, development-centric methods, to a scalable, unified approach that addresses the complex constructs and additional stakeholders in the organization- and enables realization of enterprise-class product or service initiatives via aligned and cooperative solution development.
In this talk, Dean Leffingwell describes how to accomplish this with the Scaled Agile Framework, a publicly - accessible knowledge base of proven Lean and Agile practices for enterprise-class software development. He approaches the problem from the perspectives of Lean thinking and principles of product development flow, illustrating how these core principles help deliver business results at scale, while keeping the development system - and the enterprise - lean and responsive to rapidly changing market needs. And since winning is more fun, he’ll also describe some of the personal benefits that come when teams master the art of delivering better enterprise-class software, at an ever faster pace.
One in three women will be raped or beaten in her lifetime. Half of the seven billion global population are women so that means one billion women alive now will, or have been, beaten or raped or beaten. Women and children are disproportionately affected by war and occupation as well. And yet numerous studies illustrate how uplifting women's work and leadership can strengthen the whole society and economy. Women are at the forefront of global campaigns challenging militarism and violence, and working to redirect resources into health care, education, green jobs and other life-affirming activities. What can we learn from these women and their successes thus far? How can the technology sector support this crucial work? How do these social movements stay agile to rapidly respond to breaking news while building a long-term progressive movements for deeper social, economic and environmental justice? As Arundhati Roy said, "Another world is not only possible, she is on her way. On a quiet day, I can hear her breathing." In this talk, Rae Abileah will share visionary examples of women-led work for peace and justice and explore the paradigm shift needed for equality, human rights, and justice for all.
Dinner, Agile Art and Networking - 180 mins
Registration - 30 mins
A major challenge in agile development is the ability of test teams to keep pace with ongoing development while simultaneously ensuring that new development has not created regression failures. This case study from Halliburton shows how together with two globally distributed outsourcing partners they developed a comprehensive test automation strategy for their agile teams that effectively leveraged both in house and outsourced activities. This approach resulted in a significant quality improvement from prior releases.
Coffee/Tea Break - 15 mins
1 favorite_border 0forum
Adopting Agile via Continuous Improvement - Your First 5 Days and Your Next 2 Years
Do you adopt Agile all at once or one step at a time? What do you do after your adoption finishes (does that question even make sense)? What result should you expect at 30, 90, and 120 days? How do you get that? Is TDD the same on 20 days as at 360 days? Does it differ only in skill, or is it a completely different practice? We answer all these and a lot more. We show what you should expect for the first 2 years.
8 favorite_border 15forum
Meeting the challenges of agile principles: An offshore Scrum Master perspective
The 12 agile principles lay the foundation for a successful agile team and deliver a product that meets customer satisfaction. Every principle is an absolute necessity to build great software and great teams. While these principles have stood the testimony of time over a decade now, much has changed the way we build and deliver software, especially from an offshore perspective. Adoption of agile methods does not simply imply a framework or a process implementation, but it goes beyond that.
In this talk, I share the experience of a Scrum Master, who in hindsight, look at the challenges such as lack of trust, micro management, lack of technical excellence, managing stakeholder’s expectations etc. and the impact on team’s performance. This is the result of ignoring agile values and principles which could have been avoided. Lastly, we look at the actions taken by the team and Scrum Master to turn on the challenges into a win-win situation for both onshore and offshore teams and become one of the successful agile teams.
As the popularity of Agile methods have grown, so have the misconceptions or myths associated with Agile also grown. These myths get even more glorified when we talk about them in the offshore or distributed context. And to make matters worse, you can throw in a fixed-price contract spanner into the engine.
Worry not! In this fun-filled activity, we'll collect facts from the participants that they believe are true and then we'll declare them as confirmed or busted after an interactive (heated) discussion.
13 favorite_border 7forum
Robotic Warehouses, Alien Domain, Offshore developers, Visionary customer : Saved by agile
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
2 favorite_border 6forum
Cross Geo Collaboration and Delivery of Intel's Tablet - Scaled Agile and ALM Tools Story
We all know it takes a group of skilled engineers and developers to deliver any successful product. But what if they are all located in various geos, have different competencies / focus areas (hardware, software), on top of it - they are given a stringent deadline to deliver? In my session I'd like to share how Intel adopted the Scaled Agile framework and a homegrown "Managed Personal Accountability" (MPA) model to deliver the first tablet solution successfully.
It took a combination of good Agile planning and execution (Scrum of Scrums), an integrated ALM Toolset, along with performance management metrics of MPA to deliver this project successfully.
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.
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.
Change is a necessity and fact of organization sustenance and survival. Some changes are quite disruptive while others evolve gradually. Agile when compared to the many of the other models is radical and requires some fundamental shifts both in culture and traditional management practices. The Indian IT Services industry is at the crossroads of change with a heavy influx of agile projects in the recent past. Effective change in the context of agile with a heavy baggage from the past makes it harder. Business still has to continue and projects must be executed; so how do we go about an effective agile adoption/transition.
This talk will try and look into the complexity and inhibitors of successful agile adoption in a typical large IT Services organization and questions the viability of certain agile methods such as Scrum and XP. We will explore why evolutionary methods such as Lean/Kanban are better fit and the necessity for evolutionary software development such as emergent design as a core premise for delivering Professional Software Development Services. Finally we also challenge the current status quo that is detrimental to a meaningful agile adoption and suggest few positive changes with Agile IT Services Manifesto.
Fixed price (and fixed scope) projects dominate the offshore industry. These projects have offshore/onsite teams. They often have large team size (over 100s of people in one team).
Agile thinking uses team velocity/ throughput and uses that to project an end date (Kanban system) or how much scope can be accomplished in a given time duration (number of sprints in SCRUM). They assume a stable team. However, this is not applicable for projects. They experience resource and productivity ramp-up issues. Often, resources keep changing as new projects come in. Projects do not have past velocity or throughput data. Extrapolating historical data from other similar projects, though possible, is inaccurate for multiple reasons.
This talk is based on our experience of working with such project teams. They want to adopt agile methods. We show how they can adopt the Kanban Method and yet do: A) Initial Capacity Planning B) Assess the impact of scope creep to the project end date.
The session assumes a basic understanding of the Kanban method.
Lunch - 60 mins
My talk is centred on doing better for our people; creating opportunities and building communities for a better life.
I explore the actions and impact of a ground-up Agile Transition over the past 18 months, the challenges, what worked well, and how we began on a journey of connecting and growing Agile communities globally.
A key theme discussed is our primary focus of putting the people we work with first while inspiring moments to challenge, learn, and explore new ways of thinking.
- Scaling Agile Engagement is particularly applicable to anyone working with a large organization and/or dist