BT Your opinion matters! Please fill in the InfoQ Survey!
About InfoQ InfoQ Writers Contribute About C4Media Exclusive updates on:
Facilitating the spread of knowledge and innovation in professional software development
Search Login
En
Fr Br 1,263,777 Nov unique visitors Development Java Clojure Scala .Net C# Mobile Android iOS IoT HTML5 JavaScript Functional Programming Web API
Featured in Development Herding Nulls and Other C# Stories From the Future
Mads Torgersen shares future thinking of a fast-moving major programming language, C#. Torgersen discusses pattern matching, type classes, discriminated unions and much more. All in Development Architecture & Design Architecture Enterprise Architecture Scalability/Performance Design Case Studies Microservices Patterns Security
Featured in Architecture & Design The Value of Logging within Cloud Native Applications: A Q&A with Kresten Krab
InfoQ recently sat down with Kresten Krab, CTO at Humio, and discussed the role of logging within the overall topic of system observability. A key takeaway is that aggregating logs from diverse components or services that make up a running system provides an excellent way to monitor, debug and understand (or "observe") modern software systems. All in Architecture & Design Data Science Big Data Machine Learning NoSQL Database Data Analytics Streaming
Featured in Data Science The Practice & Frontiers of AI Panel
The panelists discuss where AI is heading and how it's affecting software today. All in Data Science Culture & Methods Agile Diversity Leadership Lean/Kanban Personal Growth Scrum Sociocracy Software Craftmanship Team Collaboration Testing UX
Featured in Culture & Methods Kent McDonald and Heather Mylan-Mains on Socratic Questioning
In this podcast Shane Hastie, Lead Editor for Culture & Methods, spoke to Kent McDonald and Heather Mylan-Mains on their talk at Agile 2017 about Socratic Questioning All in Culture & Methods DevOps Infrastructure Continuous Delivery Automation Containers Cloud
Featured in DevOps The Value of Logging within Cloud Native Applications: A Q&A with Kresten Krab
InfoQ recently sat down with Kresten Krab, CTO at Humio, and discussed the role of logging within the overall topic of system observability. A key takeaway is that aggregating logs from diverse components or services that make up a running system provides an excellent way to monitor, debug and understand (or "observe") modern software systems. All in DevOps Podcasts
Software Development Conference LondonMar 5-9, 2018 AI & ML SFApr 9-11, 2018 New YorkJun 25-29, 2018 Streaming Machine Learning Reactive Microservices Containers .NET All topics You are here: InfoQ Homepage Articles Skills for Scrum Agile Teams
Call for articles
Skills for Scrum Agile Teams
| Posted by Prasad Prabhakaran on Jul 26, 2010. Estimated reading time: 6 minutes | 16 Discuss Share |
"Read later" "Reading List" A note to our readers: As per your request we have developed a set of features that allow you to reduce the noise, while not losing sight of anything that is important. Get email and web notifications by choosing the topics you are interested in. 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: 1. 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. 2. Automated builds Related Vendor Content
Best practices for using the Vary Header Making the Move to Public Cloud: Best Practices FREE eBook: Implementing High-Performance Caching and Cache Clustering with NGINX All-in-one Monitoring: Introduction to Site24x7 for Cloud, APM, and Server Monitoring Microservices vs Service-Oriented Architecture (SOA) [Free O'Reilly Ebook] Related Sponsor Fastly’s edge cloud platform powers secure, fast and reliable online experiences for the world’s most popular digital businesses. See for yourself. 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. 3. 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. 4. 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. 5. 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.
Communication Collaboration
Unit testing (tools – NUnit, JUnit ) Time Management/ Planning Code coverage concepts and tools Thinking Code review concepts and tools Conflict Management Continuous integration tools Dealing with Change/ Flexibility Refactoring concepts Decision making Code-smell concepts Teamwork/ Teambuilding Scrum process Handling stress Problem Solving Leadership Diplomacy
QA
Definition of done -> acceptance criteria
Same as developer
Test management Automation / scripting Environment setup Database concepts
Scrum Master
Scrum process
Developer skills + facilitation
Templates and usage Project Management tools Continuous integration tools Development environment setup
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
[email protected]
Development Related Topics:
Testing
Culture & Methods
Teamwork
Unit Testing
Agile Techniques
Team Collaboration
Continuous Integration
Collaboration
Agile in the Enterprise Distributed Team
Agile
Productivity
Design
Adopting Agile
Refactoring
Automation
Related Editorial
Q&A on the Book "Create Your Successful Agile Project" Customize Your Agile Approach: Start with Results You Want Mastering Agile Testing Agile is King, But Continuous Integration is an Elusive Goal Lean and Agile Culture at the Finnish Broadcasting Company Yle
Hello stranger! You need to Register an InfoQ account or Login or login to post comments. But there's so much more behind being registered.
Get the most out of the InfoQ experience. Tell us what you think Message Please enter a subject
Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p Email me replies to any of my messages in this thread Post Message Community comments Watch Thread XP for dummies? by Rhys K Posted Jul 26, 2010 11:42 Re: XP for dummies? by Luca Minudel Posted Jul 27, 2010 12:30 Re: XP for dummies? by Prasad Prabhakaran Posted Jul 28, 2010 01:58 Scrum - no commitment, just a buzz-word by no scrum Posted Jul 28, 2010 04:16 Re: Scrum - no commitment, just a buzz-word by Deborah Hartmann Posted Jul 28, 2010 03:37 Re: Scrum - no commitment, just a buzz-word by Roy Donasco Posted Aug 04, 2010 10:38 Re: Scrum - no commitment, just a buzz-word by Roy Donasco Posted Aug 04, 2010 10:35 not in the real world by phloid domino Posted Jul 28, 2010 05:11 Re: not in the real world by Deborah Hartmann Posted Jul 28, 2010 03:38 Re: not in the real world by Rainer Eschen Posted Jul 29, 2010 03:32 Realities of SCRUM by J. Tyson Posted Jul 29, 2010 08:15 What about Individuals development by Arunkumar Dharuman Posted Jul 29, 2010 11:58 Re: What about Individuals development by Hans-Eric Grönlund Posted Jul 30, 2010 01:04 Re: What about Individuals development by Roy Donasco Posted Aug 04, 2010 10:43 Re: What about Individuals development by Harinath Mallepally Posted Aug 08, 2010 06:36 Re: What about Individuals development by majesty name Posted Nov 09, 2010 08:56 XP for dummies? Jul 26, 2010 11:42 by "Rhys K" You can't seriously suggest there are readers of infoq who learnt anything by reading this article. Like Reply Back to top Re: XP for dummies? Jul 27, 2010 12:30 by "Luca Minudel" @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 game Like Reply Back to top Scrum - no commitment, just a buzz-word Jul 28, 2010 04:16 by "no scrum" 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 week Like Reply Back to top not in the real world Jul 28, 2010 05:11 by "phloid domino" 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 reality Like Reply Back to top Re: XP for dummies? Jul 28, 2010 01:58 by "Prasad Prabhakaran" 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. Like Reply Back to top Re: Scrum - no commitment, just a buzz-word Jul 28, 2010 03:37 by "Deborah Hartmann" 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. Like Reply Back to top Re: not in the real world Jul 28, 2010 03:38 by "Deborah Hartmann" Speaking as a coach: What if we focused on the behaviour of those managers who set unrealistic expectations? Could that help? Like Reply Back to top Re: not in the real world Jul 29, 2010 03:32 by "Rainer Eschen" 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. Like Reply Back to top Realities of SCRUM Jul 29, 2010 08:15 by "J. Tyson" Once you learn that SCRUM is an acronym for SCRewed Up Methodology, it all becomes clears. Like Reply Back to top What about Individuals development Jul 29, 2010 11:58 by "Arunkumar Dharuman" 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. Like Reply Back to top Re: What about Individuals development Jul 30, 2010 01:04 by "Hans-Eric Grönlund" Funny, to me agile is all about individuals. And forgetting family? Sustainable pace is an important aspect of being agile. Like Reply Back to top Re: Scrum - no commitment, just a buzz-word Aug 04, 2010 10:35 by "Roy Donasco" 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 reestimate 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. Like Reply Back to top Re: Scrum - no commitment, just a buzz-word Aug 04, 2010 10:38 by "Roy Donasco" I agree, attitude is a BIG factor if you want commitment regardless of methodology used. Like Reply Back to top Re: What about Individuals development Aug 04, 2010 10:43 by "Roy Donasco" 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. Like Reply Back to top Re: What about Individuals development Aug 08, 2010 06:36 by "Harinath Mallepally" Good article. Like Reply Back to top Re: What about Individuals development Nov 09, 2010 08:56 by "majesty name" 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. Like Reply Back to top Close by on View Reply Back to top Close Quote original message Subject
Your Reply
Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p Email me replies to any of my messages in this thread Post Message Cancel Close Subject
Your Reply
Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p Email me replies to any of my messages in this thread Cancel Close OK RELATED CONTENT
Trio of Trouble: Design Thinking, Lean and Agile Nov 19, 2017
Why Isn't Lean/Agile/Scrum/DevOps The Way We All Work and What Comes Next? Nov 18, 2017
Q&A on the Book "Create Your Successful Agile Project" Nov 14, 2017
Customize Your Agile Approach: Start with Results You Want Nov 01, 2017
Q&A on the Book Executive’s Guide to Disciplined Agile Oct 19, 2017
Offshoring Agile When You Are a Startup Oct 03, 2017
Women in Agile and the Confidence Code Jul 10, 2017 Real-Time Collaboration Comes to Atom Nov 16, 2017
The Top Five Secrets to Improving Team Communication Aug 16, 2017 XebiaLabs Announce DevOps Intelligence Engine Nov 29, 2017
Customize Your Agile Approach: What Kinds of Leadership Does Your Project Need? Dec 02, 2017 Sponsored Content
How to build a CI/CD pipeline with Terraform Join Fastly web performance and browser engineer Patrick Hamann — formerly of The Guardian and The Financial Times — as he walks you through creating a continuous deployment pipeline using Travis, Terraform, Fastly, and GitHub.
6 Ways to Enhance your Microservices at the Edge Read this technical brief to learn how you can use logic at the edge of the network — closer to users — to strengthen and support your microservices, ultimately helping you build a more resilient product for your customers.
Sponsored by RELATED CONTENT
Customize Your Agile Approach: What Do You Need for Estimation? Nov 18, 2017
Agile at Red Hat Oct 23, 2017
Customize Your Agile Approach: Select Your Agile Approach That Fits Your Context Oct 22, 2017
Scaling Agile – a Real Story Sep 28, 2017
Six Ways Agile Can Turn Static Sep 01, 2017
Transcend the “Feature Factory” Mindset Using Modern Agile and OKR Aug 27, 2017
Quantitative Analysis of Agile Methods Study (2017): Twelve Major Findings Aug 10, 2017
A View from the Trenches: the C-Suite’s Role in Organizational Transformation Jul 12, 2017
Rethinking Lean Startup at a Big Corporate Jul 07, 2017
Transforming from Projects to Products Jul 01, 2017
The Computest Story: The Transformation to an Agile Enterprise Jun 29, 2017
RELATED CONTENT
GitLab's CEO Sid Sijbrandij on Current Development Practices Jun 19, 2017
Always Available Nov 01, 2017
Refactoring Elixir - Lessons Learned from a Year on Exercism.Io Oct 09, 2017
Automated Journey Testing with Cascade Aug 16, 2017
Addressing Security Regression by Unit Testing Jul 19, 2017
21st Century Change Management: What We Know and Where We Must Do Better Nov 23, 2017
You Can’t Always Get What You Want… Nov 17, 2017 Using Self-Selection to Create Teams Nov 16, 2017 InfoQ Weekly Newsletter Q&A with Ken Schwaber and Jeff Sutherland about Scrum Guide Updates Nov 09, 2017 Join a community of over 250 K senior developers by signing up for our newsletter
Lean Business Agility Oct 20, 2017 Your email here
Subscribe
Development Automating Inventory at Stitch Fix Oct 06, 2017 Herding Nulls and Other C# Stories From the Future SpringOne 2017 Key Announcements SpringOne 2017 Platform Conference - Day 1 Architecture & Design SpringOne 2017 Key Announcements SpringOne 2017 Platform Conference - Day 1 Chef Extends OpsWorks Capabilities in AWS Culture & Methods SpringOne 2017 Key Announcements SpringOne 2017 Platform Conference - Day 1 Kent McDonald and Heather Mylan-Mains on Socratic Questioning Data Science SpringOne 2017 Key Announcements SpringOne 2017 Platform Conference - Day 1 The Practice & Frontiers of AI Panel DevOps SpringOne 2017 Key Announcements SpringOne 2017 Platform Conference - Day 1 Chef Extends OpsWorks Capabilities in AWS Home All topics QCon Conferences About InfoQ InfoQ Writers Contribute About C4Media Create account Login QCons Worldwide London Mar 5-9, 2018 AI & ML QCon, SF Apr 9-11, 2018 Beijing Apr 20-22, 2018 São Paulo May 9-11, 2018 New York Jun 25-29, 2018 Shanghai Oct 18-20, 2018 San Francisco Nov 5-9, 2018
InfoQ Weekly Newsletter Join a community of over 250 K senior developers by signing up for our newsletter
Your email here
Subscribe
RSS feed For daily content and announcements For major community updates For weekly community updates InfoQ.com and all content copyright © 2006-2017 C4Media Inc. InfoQ.com hosted at General Feedback Bugs Advertising Editorial Marketing Contegix, the best ISP we've ever worked with.
[email protected]@
[email protected]@
[email protected] Privacy policy BT
We notice you're using an ad blocker We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.