Skills for Scrum Agile Teams
InfoQ Live August 17th: Learn how to Deploy Service Mesh in Production
REGISTER
Facilitating The Spread Of Knowledge And Innovation In Professional Software Development
English Edition
Search
SIGN UP / LOGIN
NOTIFICATIONS
1
1,659,640 Jun unique visitors
QCon Plus Hybrid Software Conference
Learn from world-class domain experts. Attend online on Nov 1-5.
Resilience Engineering in the Age of COVID
Learn how leading software companies are designing & managing for resilience
InfoQ Homepage Articles Skills For Scrum Agile Teams
Skills for Scrum Agile Teams
LIKE16PRINT
JUL 26, 2010 6 MIN READ
by
- FOLLOW
This paper brings out the uniqueness involved in Agile Scrum projects, and identifies the traits required for a successful team. The paper concludes with recommendation of interventions required for effective scrum team.
Engineering uniqueness of agile projects
There are several things which cause an agile project to be different from projects based upon more traditional approaches, including:
- Setting up the development environment
In a traditional project, the team can spend sufficient time in setting up the environment; in case of agile teams, they need to be productive form the first hour. From our experience, we have realized that lack of documentation on setting up the development environment is a key reason why the setup time is large. The second key reason is the number of manual steps involved in the setup process. In sprint 0, we must document every little thing that a developer needs to do in order to start writing code and integrating with the rest of the team’s work.
- Automated builds
RELATED SPONSORED CONTENT
Git Branching Strategies vs. Trunk-Based Development
Getting Started with Canary Testing
What I Wish I Knew About U2F and Other Hardware MFA Protocols
[eBook] The NGINX Real-Time API Handbook
Develop Resilient Applications with Event-Driven Microservices
RELATED SPONSOR
Ship Fast. Rest Easy. LaunchDarkly. It's scary until it's not. Get total control of your code to ship fast, reduce risk, and reclaim your nights and weekends. Sign up for a Demo.
Let us fail early! We have learned that manual builds are liable to be both fragile and specific to a single machine, and time lost to making those builds work is time lost to development and testing. On anything but the smallest projects, having an automated build process is essential. We realized that, even if you have to take time out to create an automated build environment, it's time you'll get back later. It also makes it simpler to ensure that we have a standardized build that everyone on a project can share. Key tools we’ve used include Ant, Maven and Nant.
- Continuous integration
Form our past experience we have learned that waiting for weeks on end before we integrate code from different team members is a recipe for disaster. If you've got an automated build in place, the next thing is to go for continuous integration. Of course an automated build and continuous integration environment pre-supposes version control (or Software Configuration Management to give it a more formal and impressive name). A key lesson learned is, the sooner that you identify integration errors the sooner you can fix them. Key tools we’ve used include CruiseControl, CruiseControl.Net and Bamboo.
- Unit testing
In a highly fluid environment with multiple developers, shifting requirements and changing priorities it's essential to ensure that what worked yesterday works today. We also had challenges with integration errors. A practice (which we learned the hard way) is to use unit tests so that code changes do not break existing functionality. We also started writing unit test cases before coding. Key tools we’ve used include JUnit (and other xUnit tools such as NUnit, HTTPUnit, etc) and MockObjects.
- Refactoring
In a traditional environment, normally an individual protects their codebase until integration, but in agile we practice code ownership - in this view all code belongs to all developers, who are free to improve the code when they feel it's necessary. Over a period of time, our code base started behaving strangely - the solution to this was refactoring (thanks to Martin Fowler who popularized the term refactoring in his book of the same name). Refactoring essentially boils down to code changes which improve the structure and clarity of the code without necessarily changing the functionality. A key lesson learned was to have unit tests as a safety net before refactoring the code, and some key tools used include Eclipse, NetBeans, IntelliJ IDEA and Visual Studio.NET.
As it is clearly evident there are certain unique things in agile projects engineering practices, so the teams need to be prepared for and oriented towards these practices.
Behavioral traits required to work in agile teams
As agile teams work differently from normal teams and depends a lot on effective and efficient communication and fast execution, there is an increased need to use soft skills. If we are aware of this and actively encourage the use of some of these traits and skills, we can make agile teams more meaningful and productive.
Self-organization usually relies on basic ingredients like Positive feedback, Negative feedback, Balance of exploitation and exploration, and multiple interactions. From our experience, a team may fail to give the right kind of feedback and shy away from interaction because of many cultural and social issues.
From my experience, this remains a ‘myth’. Always we tend to have ‘predictability syndrome’ - the more planning we do the more predictable we will be.
The team needs to have good discipline, the ability to take responsibility, be committed, and take accountability and ownership.
One of the key skills that the team needs to have is the ability to ask for help and to seek out review. In certain cases we had seen the ‘ego’ factoring out as a major impediment.
Taking responsibility, being committed, and a spirit of collaboration are sometimes taken for granted; however from our experience we sometimes need external interventions to make these happen.
Certain key skills which we normally tend ignore are the ability to take initiative, enjoying working in an intense environment and adapting to new situations and frameworks easily.
Most of our projects are distributed, meaning there will be a co-development scrum between client and the service provider. In these contexts, skills like managing diversity, time management, diplomacy and leadership are very essential.
Success ‘Mantra’ for agile teams
For any agile projects to be successful and hyper-productive, the team needs to show more enthusiasm and the right attitude towards ,learning from peers in spite of seniority and expertise. A safety net for fearless expression needs to be ensured so that real camaraderie can be exhibited, which in turn will increase focus on the goals of the team rather than ‘what is in it for me’?
Conclusion
From my experience and observations, the skills required to be hyper-productive in an agile project are different from those required by a traditional one. We have identified behavioral and technical skills required for a team to have that edge. Anyone who acquires these ‘delta’ traits will be equipped with the right set of behavioral and technical skills, which enable them to work effectively in an agile project. The summary of the skills are represented in the table below.
Skill table
Role
Technical skills ( in respective platforms)
Behavioral skills
Developer
CRUD operations, interfacing with different layers of the development frame work.
Unit testing (tools – NUnit, JUnit )
Code coverage concepts and tools
Code review concepts and tools
Continuous integration tools
Refactoring concepts
Code-smell concepts
Scrum process
Communication
Collaboration
Time Management/ Planning
Thinking
Conflict Management
Dealing with Change/ Flexibility
Decision making
Teamwork/ Teambuilding
Handling stress
Problem Solving
Leadership
Diplomacy
QA
Definition of done -> acceptance criteria
Test management
Automation / scripting
Environment setup
Database concepts
Same as developer
Scrum Master
Scrum process
Templates and usage
Project Management tools
Continuous integration tools
Development environment setup
Developer skills + facilitation
About the Author
Prasad, has 10 years of experience in the IT services industry, His first exposure towards agile was from a Microsoft project in 2005; from then onwards he did solutions development, coaching, consulting, and teaching on agile and its flavors for many companies like GE, Cisco, Coke etc. Currently he is working as a Manager in Agile Labs at Symphony Services. 40% of projects at Symphony are in some form of Agile and its flavors, and started providing business critical value for the customer through Agile since 2004. He can be reached at pprabhak@symphonsysv.com
This content is in the Architecture topic
FOLLOW TOPIC
Related Topics:
- DEVELOPMENT
- CULTURE & METHODS
- AGILE TECHNIQUES
- TEAM COLLABORATION
- AGILE IN THE ENTERPRISE
- AGILE
- PRODUCTIVITY
- DESIGN
- ADOPTING AGILE
- REFACTORING
- TESTING
- TEAMWORK
- UNIT TESTING
- COLLABORATION
- CONTINUOUS INTEGRATION
- ARCHITECTURE
- DISTRIBUTED TEAM
- AUTOMATION
RELATED EDITORIAL
POPULAR ACROSS INFOQ
DevOps and Cloud InfoQ Trends Report - July 2021
Java News Roundup: MicroProfile 4.1, Spring Boot Updates, Kotlin, Scala, OpenJDK, Liberica JDK
Microsoft Has Now Its Own Linux Distribution Builder, CBL-Mariner
WhatsApp Adopts the Signal Protocol for Secure Multi-Device Communication
Java News Roundup: Hazelcast Introduces New Platform, JDK 17, JDK 18 and Spring
Fran Méndez on AsyncAPI
RELATED CONTENT
Building Your Own Agile Team Maturity Assessment
JUN 25, 2021
‘Debt’ as a Guide on the Agile Journey: Technical Debt
JUN 18, 2021
Agile Transformation: an Integral Approach
MAY 28, 2021
‘Debt’ as a Guide on the Agile Journey: Organizational Debt
MAY 26, 2021
Key Metrics to Track and Drive Your Agile Devops Maturity
MAY 07, 2021
Zuzana Šochová on Becoming an Agile Leader
APR 23, 2021
Agile Development Applied to Machine Learning Projects
FEB 25, 2021
- Icon
The SRE as a Diplomat
JUL 14, 2021
Augmenting Organizational Agility Through Learnability Quotient (LQ) - an Architect’s Perspective
JUL 08, 2021
Evolutionary Architecture from an Organizational Perspective
MAY 28, 2021
Sociotechnical Implications of Using Machines as Teammates
MAR 03, 2021
RELATED SPONSORED CONTENT
The State of Continuous Delivery in 2021: Hype vs. Reality (On-demand webinar) -- Watch Now
Watch this on-demand webinar to learn about some of the most common deployment challenges facing organizations today, along with the tools, tactics, and best practices being used to address them.
An Introduction to Trunk-Based Development
Trunk-based development (tbd) is a method of version control branch management that removes complexity by eliminating long-lived software feature branches in favor of a single branch called the “trunk.” Learn about the benefits of tbd and strategies for implementing tbd with feature flags.
SPONSORED BY
RELATED CONTENT
Who is on the Team?
FEB 12, 2021
Culture & Methods Trends Report March 2021
MAR 05, 2021
InfoQ Live July 20th: Software Supply Chain for DevOps & Reducing Feature Flag Debt
JUL 15, 2021
GitLab 14 Introduces Epic Boards, Improves Pipeline Editor and Kubernetes Agent, and More
JUL 05, 2021
Preventing Transformational Burnout through Collaboration, Transparency, Feedback, and Coaching
JUN 29, 2021
Danske Bank’s 360° DevSecOps Evolution at a Glance
JUN 24, 2021
Leveraging Small Teams to Scale Agility - a Red Hat Case Study
JUN 21, 2021
Reawakening Agile with OKRs?
JUN 10, 2021
The Game Master's Framework for Software Development
MAY 19, 2021
Why DevOps Culture Matters: Leaders Talk About the Keys to Making Change Successful and Sustainable
APR 30, 2021
Which Industries Would Benefit the Most from Agile Innovation
APR 09, 2021
RELATED SPONSORED CONTENT
The State of Continuous Delivery in 2021: Hype vs. Reality (On-demand webinar) -- Watch Now
LaunchDarkly
[Webinar] Fundamentals of Microservices
NGINX
RELATED CONTENT
The Evolution of Distributed Systems on Kubernetes
MAR 24, 2021
Cloud-Native Is about Culture, Not Containers
MAR 17, 2021
Surviving Zombie Scrum
MAR 15, 2021
Improving Organizational Agility with Self-Management
FEB 10, 2021
Nine Trends That Are Influencing the Adoption of Devops and Devsecops in 2021
APR 15, 2021
Becoming More Efficient and Productive in a Distracted World
MAR 11, 2021
Moving into "Modern Test Leadership"
JUL 20, 2021
Paving the Road to Production
JUL 06, 2021
How Outsourcing Practices Are Changing in 2021: an Industry Insight
JUL 02, 2021
Distributed DevOps Teams: Supporting Digitally Connected Teams
JUL 01, 2021
How Workplace Culture Affects Workplace Performance
JUN 17, 2021
The InfoQ Newsletter
A round-up of last week’s content on InfoQ sent out every Tuesday. Join a community of over 250,000 senior developers. View an example
Enter your e-mail address
Select your country Select a country AfghanistanÅlandAlbaniaAlgeriaAmerican SamoaAndorraAngolaAnguillaAntarcticaAntigua and BarbudaArgentinaArmeniaArubaAustraliaAustriaAzerbaijanBahamasBahrainBangladeshBarbadosBelarusBelgiumBelizeBeninBermudaBhutanBoliviaBonaire, Sint Eustatius, and SabaBosnia and HerzegovinaBotswanaBouvet IslandBrazilBritish Indian Ocean TerritoryBrunei DarussalamBulgariaBurkina FasoBurundiCambodiaCameroonCanadaCape VerdeCayman IslandsCentral African RepublicChadChileChinaChristmas IslandCocos (Keeling) IslandsColombiaComorosCongo (Democratic Republic)Congo (People's Republic)Cook IslandsCosta RicaCote D'IvoireCroatiaCubaCuraçaoCyprusCzech RepublicDenmarkDjiboutiDominicaDominican RepublicEast TimorEcuadorEgyptEl SalvadorEquatorial GuineaEritreaEstoniaEthiopiaFalkland Islands (Malvinas)Faroe IslandsFijiFinlandFranceFrench GuianaFrench PolynesiaFrench Southern TerritoriesGabonGambiaGeorgiaGermanyGhanaGibraltarGreeceGreenlandGrenadaGuadeloupeGuamGuatemalaGuernseyGuineaGuinea-BissauGuyanaHaitiHeard Island and McDonald IslandsHondurasHong KongHungaryIcelandIndiaIndonesiaIranIraqIrelandIsle of ManIsraelItalyJamaicaJapanJerseyJordanKazakhstanKenyaKiribatiKosovoKuwaitKyrgyzstanLaosLatviaLebanonLesothoLiberiaLibyaLiechtensteinLithuaniaLuxembourgMacauMacedoniaMadagascarMalawiMalaysiaMaldivesMaliMaltaMarshall IslandsMartiniqueMauritaniaMauritiusMayotteMexicoMicronesiaMoldovaMonacoMongoliaMontenegroMontserratMoroccoMozambiqueMyanmarNamibiaNauruNepalNetherlandsNetherlands AntillesNew CaledoniaNew ZealandNicaraguaNigerNigeriaNiueNorfolk IslandNorth KoreaNorthern Mariana IslandsNorwayOmanPakistanPalauPalestinian TerritoryPanamaPapua New GuineaParaguayPeruPhilippinesPitcairnPolandPortugalPuerto RicoQatarReunionRomaniaRussian FederationRwandaSaint HelenaSaint Kitts and NevisSaint LuciaSaint MartinSaint Pierre and MiquelonSaint Vincent and the GrenadinesSaint-BarthélemySamoaSan MarinoSao Tome and PrincipeSaudi ArabiaSenegalSerbiaSeychellesSierra LeoneSingaporeSint MaartenSlovakiaSloveniaSolomon IslandsSomaliaSouth AfricaSouth Georgia and the South Sandwich IslandsSouth KoreaSouth SudanSpainSri LankaSudanSurinameSvalbard and Jan MayenSwazilandSwedenSwitzerlandSyriaTaiwanTajikistanTanzaniaThailandTogoTokelauTongaTrinidad and TobagoTunisiaTurkeyTurkmenistanTurks and Caicos IslandsTuvaluUgandaUkraineUnited Arab EmiratesUnited KingdomUnited States Minor Outlying IslandsUruguayUSAUzbekistanVanuatuVatican City (Holy See)VenezuelaVietnamVirgin Islands (British)Virgin Islands (U.S.)Wallis and FutunaWestern SaharaYemenZaireZambiaZimbabwe
Tell us what you think
Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p
Email me replies to any of my messages in this thread
Community comments
WATCH THREAD
XP for dummies?
by Rhys K, Jul 26, 2010 09:42
Re: XP for dummies?
by Luca Minudel, Jul 26, 2010 10:30
Re: XP for dummies?
by Prasad Prabhakaran, Jul 27, 2010 11:58
Scrum - no commitment, just a buzz-word
by no scrum, Jul 27, 2010 02:16
Re: Scrum - no commitment, just a buzz-word
by Deborah (Hartmann) Preuss, Jul 28, 2010 01:37
Re: Scrum - no commitment, just a buzz-word
by Roy Donasco, Aug 03, 2010 08:38
Re: Scrum - no commitment, just a buzz-word
by Roy Donasco, Aug 03, 2010 08:35
not in the real world
by phloid domino, Jul 27, 2010 03:11
Re: not in the real world
by Deborah (Hartmann) Preuss, Jul 28, 2010 01:38
Re: not in the real world
by Rainer Eschen, Jul 28, 2010 01:32
Realities of SCRUM
by J. Tyson, Jul 28, 2010 06:15
What about Individuals development
by Arunkumar Dharuman, Jul 28, 2010 09:58
Re: What about Individuals development
by Hans-Eric Grönlund, Jul 29, 2010 11:04
Re: What about Individuals development
by Roy Donasco, Aug 03, 2010 08:43
Re: What about Individuals development
by Harinath Mallepally, Aug 08, 2010 04:36
Re: What about Individuals development
by majesty name, Nov 09, 2010 05:56
XP for dummies?
by Rhys K, Jul 26, 2010 09:42
You can't seriously suggest there are readers of infoq who learnt anything by reading this article.
LIKEREPLY
Re: XP for dummies?
by Luca Minudel, Jul 26, 2010 10:30
@Rhys K
for sure this article could suggest to you a way to improve: how to provide feedback in a constructive way.
under the column "Behavioral skills" indeed you find Collaboration and Conflict Management. The same for Developers, QA and SM.
if you need more help, I can suggest an ever green, the perfection gameLIKEREPLY
Scrum - no commitment, just a buzz-word
by no scrum, Jul 27, 2010 02:16
You wrote: "The team needs to ... be committed ...". What you mean by commitment here?
1. Commitment - is to do one's best in a sprint?
This may not be sufficient to complete the sprint successfully, because of some wrong assumptions during the planning, some unexpected problems like side effects of code changes from other teams.
2. Or commitment - is to really complete all the planned user stories, no matter what it costs? Even if it means overtime?
If you mean the 1st one, then it just means to be honest to the colleagues, to the employer, to the customers who will use your product. From the company management perspective, this is what every employee is expected to do and is paid for. No matter if you work by scrum or not. In this case only the one's best efforts are guarantied. There is no guarantee, that the plan will be completed till the sprint end.
If there's no guarantee, then what's the difference from the non-scrum projects?
If there's no guarantee, then such a "commitment" is worth nothing, "commitment" becomes just a buzz-word. Nothing more.
If you mean the 2nd one, then "commitment" means guarantied result. It is a real difference from many classical projects. It's kind of a small "fixed price" contract. But for the team it means some risks, mainly the risk to work overtime. To mitigate the risks:
- the team can explicitly reserve some time and commit to do less than one would expect
- the team can prefer quick and bad solutions for some user stories, if other stories took more time than planned. Reworking/refactoring this means additional efforts in future, which is not planned in the project budget.
So, with fixed week hours there is no real "commitment".
Either there is no guarantee that the work will be 100% completed till the end of the sprint.
Or the work will be 100% completed, but it will cost some reserved (and may be not used) time and/or worse quality, and thus make the work more expensive.
Neither is good.
So, real "commitment" is not compatible with the fixed working week, which most employees have. Thus:
- "commitment" in scrum is just a buzz-word
- scrum is not compatible with the fixed working weekLIKEREPLY
not in the real world
by phloid domino, Jul 27, 2010 03:11
first, the 5 engineering aspects (unit testing, automated builds, etc) are absolutely the right thing to do, and still a hard sell in many organizations
promoters of 'agile' methods should focus on these practices and de-emphasize the 'behavioral' aspects
in the real world, that is, 90% of business environments where software is developed, the impediment to the behavioral recommendations is the same source of all software problems: management
the average manager's understanding of scrum or xp or any 'agile' method is limited to one thing: short deadlines
that's all managers care about; all they know how to do is look at a calendar
everything else will be subgrogated to the calendar
most agile methods have some element of adjusting based on feedback, but in the business environment it's still every man for himself, and nobody gets rewarded for telling the truth
so any process or method where developers are encourage to be honest will fail
i wish it were otherwise but that's the realityLIKEREPLY
Re: XP for dummies?
by Prasad Prabhakaran, Jul 27, 2010 11:58
May be not for you! I come from a world of IT services, where teams claims following agile may not follow 20% of what is said above.
LIKEREPLY
Re: Scrum - no commitment, just a buzz-word
by Deborah (Hartmann) Preuss, Jul 28, 2010 01:37
Good question. It is important that we be clear on how we use words.
When I teach, this is what commitment means:
"We commit to achieve these stories, or to communicate with you (the SM, the PO) ASAP when we discover things that threaten our ability to achieve them."
This combines the reality that software development is usually a research activity (we have never done exactly this thing before) with the fact that a promise has been made, upon which others have made their own commitments.
Experience shows me that it is important that teams actually make promises to their POs and then talk about having achieved them or not. This is what motivates learning and process innovation. Making promises and never talking about your success rate communicates "we don't really care", which erodes true communication and collaboration. The team that delivers 60% of what they commit, iteration after iteration, is not doing Scrum - they are not learning and improving.
Software development as a business activity requires accountability: in Scrum we make scope variable but highly value predictability of estimates. These two balance each other out and can create teams that learn to estimate well and deliver reliably on their promises.
Or not ... no process or method can compensate for people with bad attitude.LIKEREPLY
Re: not in the real world
by Deborah (Hartmann) Preuss, Jul 28, 2010 01:38
Speaking as a coach: What if we focused on the behaviour of those managers who set unrealistic expectations? Could that help?
LIKEREPLY
Re: not in the real world
by Rainer Eschen, Jul 28, 2010 01:32
Deborah, which ones do you mean - inhouse or those on the customer-side ;-).
Most important to me is that those "inhouse" managers have the responsibility to create environments that development teams need to be efficient. They don't have to understand what all the Scrum details are. But, they have to understand that there's a relation between efficiency and the quality of the environment they offer. The article above mentions parts of it (hardware, software, soft-skills, processes, ...).
My experience shows me that you can persuade those managers a bit easier to change from their old behavior to a more team-friendly one if they are in trouble with, for example, the team, with customers or with the upper management, or if they loose money or have an escalation management on a daily basis. But, maybe this is already the point of no return for the team (frustration, mentally resigning, resignation).
I still wonder if it would be better for the team members to leave the company immediately. What kind of upper management do we have in such situations that allows those managers to waste time, money, or motivation. You can't expect that the upper management will help here. On the other hand you will never have a team structure that allows to solve this through a 100% boycott or a revolution.LIKEREPLY
Realities of SCRUM
by J. Tyson, Jul 28, 2010 06:15
Once you learn that SCRUM is an acronym for SCRewed Up Methodology, it all becomes clears.
LIKEREPLY
What about Individuals development
by Arunkumar Dharuman, Jul 28, 2010 09:58
AGILE is such a worst thing that it focus only on the project and forgets totally on individuals. Individual would become a machine doing the same work again and again and forgets his personal development and totally forgets the family.
LIKEREPLY
Re: What about Individuals development
by Hans-Eric Grönlund, Jul 29, 2010 11:04
Funny, to me agile is all about individuals. And forgetting family? Sustainable pace is an important aspect of being agile.
LIKEREPLY
Re: Scrum - no commitment, just a buzz-word
by Roy Donasco, Aug 03, 2010 08:35
Commitment in a SCRUM and Agile framework is all about commitment to quality. At the start of the sprint, SCRUM team plans the user stories to be worked on. On a daily basis we re-estimate on how much more time we need to work to deliver quality working software. In some cases, we realize in the middle of the sprint that not all we initially planned can be delivered, so we scope them out and focus on the more prioritized user stories.
We do not commit quantity in SCRUM but we commit on quality.
We do not commit on a fixed number of backlogs, but we can commit based on previous sprints on the number of story points we can deliver.LIKEREPLY
Re: Scrum - no commitment, just a buzz-word
by Roy Donasco, Aug 03, 2010 08:38
I agree, attitude is a BIG factor if you want commitment regardless of methodology used.
LIKEREPLY
Re: What about Individuals development
by Roy Donasco, Aug 03, 2010 08:43
On the contrary, when we practice AGILE, one consideration is to ensure that our software engineers and Q.A. will have personal time. We respect deadlines but our customers needs to be oriented that we don't deliver fixed number of features, but we can deliver working piece of software. Gone are the days that we work ourselves to death just to meet the deadline. Stakeholders need to realize and learn to compromise quality vs quantity.
LIKEREPLY
Re: What about Individuals development
by Harinath Mallepally, Aug 08, 2010 04:36
Good article.
LIKEREPLY
Re: What about Individuals development
by majesty name, Nov 09, 2010 05:56
I think "There are several things which cause an agile project to be different from projects based upon more traditional approaches, including..." is in same in every project whether or not the project used AGILE. This is a basis of a project. not only AGILE.
LIKEREPLY
The InfoQ Newsletter
A round-up of last week’s content on InfoQ sent out every Tuesday. Join a community of over 250,000 senior developers. View an example
- Get a quick overview of content published on a variety of innovator and early adopter technologies
- Learn what you don’t know that you don’t know
- Stay up to date with the latest information from the topics you are interested in
Enter your e-mail address
Select your country Select a country AfghanistanÅlandAlbaniaAlgeriaAmerican SamoaAndorraAngolaAnguillaAntarcticaAntigua and BarbudaArgentinaArmeniaArubaAustraliaAustriaAzerbaijanBahamasBahrainBangladeshBarbadosBelarusBelgiumBelizeBeninBermudaBhutanBoliviaBonaire, Sint Eustatius, and SabaBosnia and HerzegovinaBotswanaBouvet IslandBrazilBritish Indian Ocean TerritoryBrunei DarussalamBulgariaBurkina FasoBurundiCambodiaCameroonCanadaCape VerdeCayman IslandsCentral African RepublicChadChileChinaChristmas IslandCocos (Keeling) IslandsColombiaComorosCongo (Democratic Republic)Congo (People's Republic)Cook IslandsCosta RicaCote D'IvoireCroatiaCubaCuraçaoCyprusCzech RepublicDenmarkDjiboutiDominicaDominican RepublicEast TimorEcuadorEgyptEl SalvadorEquatorial GuineaEritreaEstoniaEthiopiaFalkland Islands (Malvinas)Faroe IslandsFijiFinlandFranceFrench GuianaFrench PolynesiaFrench Southern TerritoriesGabonGambiaGeorgiaGermanyGhanaGibraltarGreeceGreenlandGrenadaGuadeloupeGuamGuatemalaGuernseyGuineaGuinea-BissauGuyanaHaitiHeard Island and McDonald IslandsHondurasHong KongHungaryIcelandIndiaIndonesiaIranIraqIrelandIsle of ManIsraelItalyJamaicaJapanJerseyJordanKazakhstanKenyaKiribatiKosovoKuwaitKyrgyzstanLaosLatviaLebanonLesothoLiberiaLibyaLiechtensteinLithuaniaLuxembourgMacauMacedoniaMadagascarMalawiMalaysiaMaldivesMaliMaltaMarshall IslandsMartiniqueMauritaniaMauritiusMayotteMexicoMicronesiaMoldovaMonacoMongoliaMontenegroMontserratMoroccoMozambiqueMyanmarNamibiaNauruNepalNetherlandsNetherlands AntillesNew CaledoniaNew ZealandNicaraguaNigerNigeriaNiueNorfolk IslandNorth KoreaNorthern Mariana IslandsNorwayOmanPakistanPalauPalestinian TerritoryPanamaPapua New GuineaParaguayPeruPhilippinesPitcairnPolandPortugalPuerto RicoQatarReunionRomaniaRussian FederationRwandaSaint HelenaSaint Kitts and NevisSaint LuciaSaint MartinSaint Pierre and MiquelonSaint Vincent and the GrenadinesSaint-BarthélemySamoaSan MarinoSao Tome and PrincipeSaudi ArabiaSenegalSerbiaSeychellesSierra LeoneSingaporeSint MaartenSlovakiaSloveniaSolomon IslandsSomaliaSouth AfricaSouth Georgia and the South Sandwich IslandsSouth KoreaSouth SudanSpainSri LankaSudanSurinameSvalbard and Jan MayenSwazilandSwedenSwitzerlandSyriaTaiwanTajikistanTanzaniaThailandTogoTokelauTongaTrinidad and TobagoTunisiaTurkeyTurkmenistanTurks and Caicos IslandsTuvaluUgandaUkraineUnited Arab EmiratesUnited KingdomUnited States Minor Outlying IslandsUruguayUSAUzbekistanVanuatuVatican City (Holy See)VenezuelaVietnamVirgin Islands (British)Virgin Islands (U.S.)Wallis and FutunaWestern SaharaYemenZaireZambiaZimbabwe
QCon Software Development Conferences
HomeCreate AccountLoginQCon ConferencesEventsContributeInfoQ EditorsAbout InfoQAbout C4MediaMedia KitDiversity
Events
InfoQ Live
SEPTEMBER 21ST, 2021InfoQ Live
AUGUST 17TH, 2021QCon Plus Hybrid Software Conference
NOV 1-5, 2021
Follow us on
Stay in the know
The InfoQ PodcastEngineering Culture PodcastThe Software Architects' Newsletter
General Feedbackfeedback@infoq.comAdvertisingsales@infoq.comEditorialeditors@infoq.comMarketingmarketing@infoq.com
InfoQ.com and all content copyright © 2006-2021 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy Notice, Terms And Conditions, Cookie Policy