Agile software development is inheriting the space in which traditional processes for software development have been at work. The big differentiator between these two approaches is that what was functional before, becomes cross-functional.
Besides that we still have a process, in which we define different statuses, we have a logistical chain on which information and pieces of work flow along, etc.
Here is a picture on how it can look like:
The crucial part in agile sofware development is its hardest part: collaboration / common interaction on specific parts of the process. Following I will go through the mini-drawings and elaborate how each is entangled in the cross-functional theme.
The Business Landscape can be graphed as a map, on which different requirement areas – such as user interaction, performance or different functionalities – give a first understanding of the business at hand.
Most parts of these areas we understand in an implicit way.
A quick example: User interaction involves logging in and out. But the interaction involves also, that the user sees the interface, that he may have other buttons to choose from or that he responds to coloring and geometrics of the page.
By writing a User Story/Task, about logging in and out, we also capture an approximate understanding of the things that relate to this feature. (The empty area around the dots signals that there is more to the requirement as we describe in only one user Story/Task.) Later on we rely on the diverse expertise of the Development Team to take care of these implicit requirements.
The Product Backlog is prioritized by the Product Owner, but additionally it is supposed to be detailed appropriately. The appropriate details play an important part in the refinement process of the product backlog items (User Stories/Tasks):
The whole of the Development Team needs not only the job instruction, but it needs a specific understanding of the requirements area around.
We get there by iterative & collaborative refinement of the individual items. The goal of the refinement is that the understanding of the Development Team(DT) is complete when it is about to select items for a next iteration. There might be several refinement sessions. Example refinements:
1) The Product Owner asks the Stakeholder about the Context
2) the Product Owner get together with the DT and defines the Goal
3) the DT inquires further details from the Stakeholders to set up Acceptance Criteria
(In a scaled environment:
4) The DT comes together with another DT to discuss dependencies / shared work.)
Now the Definition of Done tells about additional work, from a technical perspective, that is necessary for each item in the product backlog to (actually) get done. It gives information about the team’s competencies, infrastructure or specific collaboration needed. It hereby tells a lot about the whole production environment, the team composition, existing emphasizes on quality and engagement of the team (comparing a DoD of an engaged team with the DoD of a team that doesn’t really want it is like Star Wars versus StoneAge).
It is thus a truly cross-functional artifact, additionally, it is an agreement. This reflects that in agile software development we said goodbye to Taylor’s scientific management, and instead give power to the people to decide on how they want to get the work done. (Obviously this makes people more willing to participate at work with their full potential. Which is a necessity if we want to allow true team building to happen.)
Incremental Design is one of Agiles approaches to risk management, it is a design concept that fits together with the short feedback loops we want. We deliver the smallest functionality viable, but let it include all necessary technical design, agreed criteria from the DoD and as if we’re about to deploy it to production at the end of the iteration.
If the whole structure is good enough, we can get this right in the first iteration.
This refers to
1) mapping out the User Stories / Tasks in small and precise pieces
2) collaborate heavily on their refinement to know exactly what work is included
3) having a functional development process owned by the DT.
If one of these things is dysfunctional, then the DT will never have had the chance to deliver satisfyingly.
Of course there is DevOps and the technical ability to create a so called potentially shippable product.
DevOps is a conglomerat of a service oriented philosophy, envisionings of software development infrastructure and relates software architectures to team composition. All in all it is not exclusive to agile, but rather is its technical brother. With its focus on reducing maintenance costs, by including an operations point of view in the development process, it fits to the main driver of Agile: a greatly reduced Time-to-Market. Additionally; Teams without stable technical processes will very likely not adapt any stable processes which involve human interaction. (It is simply very annoying(!) – to have failing pipelines, missing test coverage/lengthy debugging, crowded branches/falthy continuous integration – to focus on Working Agreements or Definitions of Done.)
Some of DevOps tools: Continuous Integration/Deployment, Testing Frameworks, Systems for sustaining a teams development process. Without these the whole execution on short feedback loops, incremental design or a Definition of Done would get close to impossible.
Before we enter the Business Landscape again we’ll have a Review/Feedback.
In the ideal Agile world everyone who relates to the software production cycle would gather and be amazed upon the potentially shippable product. Everyone would be the Business Analysts, various Stakeholder (external/internal), Product Owner, Developers, Testers, etc. Thus it can be the most cross-functional event.
In the ideal Agile world everyone would have dialogs about the last iterations work, and how the work included got done, they would use the functionality and explain each other – based on their indvidual expertise – the pros and con of the emerged graphical/business/technical design.