Software projects that are developed based on agile processes like Scrum or eXtreme Programming are very demanding concerning the skills of the developers in an agile team.
In 2001 Andrew Hunt and David Thomas introduced a benchmark for modern developers with their book „The Pragmatic Programmer “. The focus of their work is on practises, tools and design-paradigms to help programmers produce better code.
In my point of view being a “Pragmatic Programmer” is not enough for the challenges of agile projects. This blog entry takes a closer look at the developer in the team of a Scrum project. I explicitly distinguish between “programmer” and developer” because the word programmer tends to focus more on coding and less on all the other activities needed for implementing an application. (e.g. testing)
According to Ken Schwaber (who formulated the inital version of Scrum together with Jeff Sutherland), Scrum was mainly inspired by an article of the Harvard Business Journal that was published in January 1986: „The New New Product Development Game“. The article analyzed the criterias of successful new product developments of companies like Honda and IBM. One of the main assumptions of this article for successful product development is:
„Stop playing the relay race – play rugby“.
For software development this would mean that the old sequential approach (aka: waterfall) doesn’t work anymore and we should start using a holistic approach.
Scrum has taken the basic characteristics of successful product development teams like self-organizing project team, overlapping development phases and subtle control and integrated them into the Scrum process. Scrum combines them with ideas of iterative, incremental development and lean principles.The Scrum Alliance provides training and certification for Scrum Master and Product Owner – but why not for the developer? Does’t the success of a project mainly depend on the team? Are there any implications on the skills of a developer by changing the work model to self-organization with overlapping development phases or by delivering high-quality software every 2-4 weeks?
My personal opinion is that agile methodologies like Scrum fundamentally change the way developers work. Therefore new skills and attitudes are required.
Let’s start by looking at one of the most important changes in agile projects: self-organizing project teams. Self-organizing means that there is no “command-and-control” paradigm anymore, where (project) managers tell the developers which work in which time sequence should be implemented. Self-organizing often sounds like stress-less freedom for the team – but often turns out to be a very tough job.
The team takes the responsibility for delivering high quality software in time by committing to the Sprint goals. This implies that team members have to discuss, solve conflicts, organize work, estimate effort, pull needed information and commit to team goals. In “classic” projects this is done by defined roles like project managers and in many cases developers have no experience how to deal with these challenges. The success of agile projects depends on good self-organization teams – I’ve seen managers quickly return to “command-and-control” if this doesn’t work out as expected. So in my point of view organizations have to provide developers with training and coaching to get the needed social skills. Today I see that these kind of trainings and coaching are only provided to management and leadership positions. By inverting “command and control” we also have to rethink the training strategy for skills like team building, coaching, training, negotiating, decision making, problem solving, active listening and discussing/debating – our developers will need them to organize themselves in an agile team.
It could be also useful to provide trainings to help team members understand the strengths and weaknesses of their colleagues to support the team building – methodologies like Team Management System and DISC can help teams to improve.
When we started with agility at codecentric we quickly found out that we had to train not only technologies and tools but also these kind of social skills, if we want to improve our customer satisfaction even more. So we hired an external trainer and coach to develop a social skill program for our developers to sustainable improve their skills in that area – the feedback of the participants is great and we see a lot of improvement in the teams.
The second new paradigm you get with Scrum is: overlapping development phases – like self-organizing this requires new ways of thinking for developers. In the classical, sequential process models, all the requirements are documented by writing detailed specs, filling out use-case templates and provide UML diagrams which exactly describe the whole system (ok, I am a little polemic). With these specs in place the developer could start coding and if he was a good developer, he tested his code. But he shouldn’t bother too much with testing as the next team in the process would do this for him: quality assurance.
In agile projects these strict constraints are disposed and the responsibilities of a developer are widened. In my point of view developers will have to deal a lot with defining and talking about the requirements (function and non-functional) and testing if the code fullfills these requirements. This means that Unit-Tests are not enough and functional integration and acceptance tests will be needed – normally these test will be defined and implemented together with the domain experts and experienced testers in the team. But especially for automated testing a developer should be involved from the beginning to code and design for automation – e.g. to provide data-setup and deal with time and dates in the tests. For me, automated regression tests are a must-have if you are developing in short iterations – otherwise the test effort can explode. Especially when Test-Driven Development is introduced, the developers will need training and coaching to get their tasks done. Today test-driven unit tests can be found in some projects but test-driven integration- and acceptance tests are really rare.
The developer will have to communicate a lot with the domain experts to transfer the elements of the user stories into good tests. Good knowledge of the domain will be also more important as the detail level of user stories are much lower than of classical use cases. This means that developers will need very good communication skills and a toolset of practises like Domain Driven Design. Today developers concern more about frameworks like Spring and Hibernate than with the business domain; generators that transfer an Entity-Relationship-Model into a Domain-/Object model are a nice gimmick but more or less useless! The generator will not help to get a good structured domain that can be used as a communication bridge between development and the domain experts. DDD calls a good domain model UBIQUITOUS LANGUAGE – One team, one language! In agile teams, where domain experts, testers and developers are working in one team on the same tasks and stories, it is essential to have one language. So in my opinion we need to sharpen the domain and design skills of the developers, so that they can communicate with the domain experts in a clear and simple manner.
To deliver software every 2-4 weeks a developer should also have good knowledge of common agile practises and tools. Continuous Integration (e.g. Hudson, CruiseControl ), automated build tools (e.g.. Maven , Ant ), code quality analyzers (e.g. Findbugs , PMD , Checkstyle ), test automation frameworks (e.g. JUnit , Robotframework , easyMock , DBUnit , JMeter ), version control systems (e.g. git , Subversion), bug tracking (e.g. Jira , Trac ), documentation tools (Wiki, UML, Javadoc) are just examples of the modern, agile software developers portfolio. These practises and tools have to be trained, adopted and optimized so that they can be used for higher productivity and high quality results. Dave Thomas, Co-Autor of „The Pragmatic Programmer“, defined so called „Code Katas“ to practise what is needed to be a professional developer.
In software we do our practicing on the job, and that’s why we make mistakes on the job. We need to find ways of splitting the practice from the profession. We need practice sessions.
So despite the training, we also have to give our developers time to practise – for example to learn TDD as seen in this Kata by Arne Roock .
In addition to all these skills, the developers have to be trained to understand the overall process and concepts. Today the focus of Scrum trainings is on Scrum Master and Product Owner (Ken Schwaber is changing this with the Scrum Developer ) – as most of the meetings and artifacts are mainly for the “team”, we should sharpen their understanding of Scrum (which is also part of the ScrumMasters job). For example the team should learn that the main idea behind Daily Scrum is not to report to the Scrum Master (who does not even need to attend the Daily Scrum) but to synchronize with the other team members and make impediments transparent. I’ve seen a lot of Daily Scrums where the ScrumMaster moderates and asks each team member the three questions and updates the Scrum board for them! Also the Burndown Chart is an instrument for the team to track the progress of the team – it is not used as a control-instrument for the Scrum Master or Product Owener (or even managers). Anyway: Team members have to be trained and coached to understand Scrum and the agile concepts.
This all shows that organizations that are moving to agile methods like Scrum will have to change. The skill-set of the team and especially developers is changing and the spectrum of required skills will demand for more training, practise and knowledge transfer. „The New New Product Development Game“ claimed that: „Multilearning“ and „Organizational Transfer of Learning“ are two of six critical success factors for good product development teams. Agile organizations will have to accept that training is not an incentive but a duty for all team members of agile projects. The invest in the employees will pay off for sure!
Was this post helpful?
More articles
fromMirko Novakovic
21.2.2014 Your job at codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
More articles in this subject area
Discover exciting further topics and let the codecentric world inspire you.
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog author
Mirko Novakovic
Do you still have questions? Just send me a message.
Do you still have questions? Just send me a message.