As agile developers, who are part of a team, we tend to think that our job is to finish the technical task that we have been assigned. This is true in part.
By doing TDD, among other benefits, we are eliminating the anxiety of having to face a big problem.
DISCIPLINED AGILE DELIVERY
There are, however, other less implicit but equally important responsibilities, such as delivering software that gives value to the user. In the book “Disciplined Agile Delivery” explained in detail by Scott Ambler and Mark Lines:
Disciplined agile delivery (DAD) is a process framework that guides through team decisions, focusing on continuous delivery of software on iterative and incremental loops.
This disciplined agile delivery approach is seen as a step further in improving the development process. It can be an addition to Scrum, Kanban, XP or any other methodology.
The discipline of agile delivery in practice
Due to our experience, we based the principle DAD in precise level of management actions:
CONTINUOUS CONTROL OF SPRINT
Working software that really “works” … pay attention to the times to manage scope as you go along. In a sprint of two weeks, every day advance in relation to the product to be delivered is controlled.
TECHNICAL RESPONSABILITY FOR THE TASKS
The scope is important. The developer must know what the user is going to get into detail … and deliver just that!
CONTINUOUS REVIEWS
It is highly recommended that the workflow of projects, in our case Jira, has a column of review before moving to done. Any developer that is available to complete a task, should review what has made a partner. Not a very thorough review … rather diagonally but 80% of problems (see Chapter 17 Clean Code) may be founded and solved going this way.
FUNCTIONAL TEST MADE BY DEVELOPERS
Until there is explicit that a user at the end of the chain seems like the developer has a tendency to end “homework” and ready. We must educate the developer of the importance of internal functional test. In all user stories when we draft technical tasks there is always the end of “Functional Test”, usually with minimal time, about 2 hours. Ideally, when the story comes to QA, find little or nothing.
TIME CONTROL
The developer needs to understand that when he gives an estimation, is accountable for delivery within a given time. The estimate may not be perfect but it “should” be. It’s okay to not arrive in time and fail to estimate. As a developer, if I’m not on time I should notify. And this must be understood by the team. If a task is estimated to 8 hours and after 2 hours of work I notice that will take me 16 hours, notify immediately.
STRIVING FOR EXCELLENCE, CONTINUOUS LEARNING
One of the most important pillars for all this work is a motivated and extreme desire to learn and grow every day. We must motivate and channel it properly so that developers do not disperse. Buy books, promote pair programming, Work hard to focus their careers in a personalized way …
In conclusion, what is important to deliver is “value” meaning features for the real user not a piece of code.
