The role of an Agile Developer is not well-understood and many developers may have difficulty making this transition.
In a traditional plan-driven environment (aka “Waterfall”), a developer might be able to sit in his/her cube with their headset on listening to some cool tunes and isolated from the rest of the world and simply write code. That isn’t possible in a true Agile environment.
The role of a developer in an Agile environment is significantly broader than that and includes:
- Taking responsibility for estimating, planning, and managing all of his/her own tasks and reporting on progress. This role is essentially what a project manager might do on a very small scale.
- Collaborating closely with all the other members of the team to take shared responsibility for the overall efforts that the team has committed to. This role is also similar to what a project manager might do but rather than being done by a single person with the title of “Project Manager”, the responsibility is distributed among all members of the team.
- Taking responsibility for the quality of the software the developer produces. Instead of turning over some code to a separate and independent group for testing, the team, as a whole, takes responsibility for the quality of the work they produce. A developer may or may not do the testing himself/herself but the key point is that the quality of the code is not someone else’s responsibility.
- Interacting with users as necessary to clarify requirements. Developers will typically not be given a well-defined set of requirements. More often, the developer will get some general user stories that are intended to be a “placeholder for conversation” and the developer will be expected to interact with the Product Owner and users as necessary to better define what is needed. This is essentially equivalent to a Business Analyst role on a very small scale.
The role of a developer in an Agile environment is significantly different and some developers may have difficulty making this transition.
There is a lot of confusion and some fairly polarized opinions about scaling Agile and Scrum for large, complex projects involving multiple teams.
- Some people think that it can be done simply by adding a Scrum-of-Scrums approach to provide a mechanism to coordinate the efforts of multiple teams.
- A more comprehensive approach for integrating the efforts of multiple development teams is Large-Scale Scrum (LeSS). A Scrum-of-Scrums approach is a loosely-coupled approach that only provides for basic coordination of the work between teams – each team still operates fairly independently. LeSS is a much more tightly-coupled approach that goes beyond the very basic level of coordination of work that the Scrum-of-Scrums approach provides.
The table below shows a comparison of the two approaches:
|Coordination of Work
||Formal Scrum-of Scrum’s Meeting
||Informal, “Just Talk”
|Product Backlog Management
(Single or Multiple Backlogs)
||Single Product Backlog
(Separate or Joint)
(Separate or Joint)
|Allocation of Work
(Component or Feature)
The right approach will depend on the project and the need for a more loosely-coupled or tightly-coupled approach for integrating the development efforts. However, both of these approaches only address integration of the teams from a technical, development perspective and do not explicitly provide any mechanism for integration of the efforts from a business perspective. It is assumed that the normal Product Owner role provides that level of integration but that may not be very realistic for very large, complex projects. This is really a multi-dimensional problem as shown in the diagram below:
The Scaled Agile Framework (SAFe) and other enterprise-level Agile frameworks recognize the need to provide this level of business integration with an appropriate level of program management and/or product/project portfolio management to ensure that the development efforts are well-integrated and well-aligned with the company’s business strategy.
There is a lot of confusion and conflict in this area:
- A number of people who see this from a development perspective tend to think that SAFe and other enterprise-level frameworks that address the problem of business integration are just unnecessary overhead and bureaucracy
- Many people who see this from a business strategy perspective don’t understand the need for integrating development efforts from a technology perspective
There are three major challenges that need to be considered:
- Integrating the efforts of multiple teams from a development perspective
- Aligning the efforts of all teams with the organization’s business objectives
- Coordination with other related efforts outside of the project team and providing tracking and progress reporting to management
Both the development integration perspective and the business integration perspective have merit and need to be considered when scaling Agile/Scrum to large, complex projects and all of the above challenges may need to be addressed to make a large, complex, multi-team Agile project successful.
What does it take to become an Agile developer? I recently was in a situation where the development team was completing tasks required for a sprint, but the overall stories were not being completed. The team allocated development tasks to individual developers and also allocated overall responsibility for each story to individual developers. However, for several sprints, the development tasks were completed but a number of the stories were not.
I don’t think the developers on the team clearly understood what it meant to be responsible for a story. I think most saw their primary responsibility as completing development tasks. Completing stories was seen as kind of an administrative coordination function. It’s more than that, in my opinion – a developer who takes responsibility for stories in a sprint needs to be responsible for:
- Understanding the business purpose of the story and defining and analyzing possible alternative ways of satisfying the business purpose of the story
- Planning and estimating development tasks with other developers that are required to fulfill the story
- Working directly with the Product Owner to clarify and further define the details of how the story should be implemented
- Providing guidance to other developers as necessary who are engaged in development tasks associated with the story
- Taking overall responsibility for “shepherding” the story through the process all the way to (and including) UAT. The developer responsible for the story should lead the presentation of the completed story to the Product Owner in UAT (or Sprint Review)
I think it’s sometimes taken for granted that any developer can easily move into an Agile project – I don’t believe it’s that simple and my experience is that some developers have a hard time making that transition. Some developers just want to write code and are not even interested in taking on these additional responsibilities.