Lean Agile Process

Making the Agile process still more lean

19 June 2014


The core idea of lean is to eliminate/reduce non-value-added activities (termed "wastes") and thus increase customer value. The Agile process itself is a lean method for the software development life cycle, and I am sharing a couple of Agile best practices adopted by many teams to make the Agile process extra lean.

My team follows an Agile method that serves the needs at the enterprise level, producing frequent IRs (interim releases). (An IR consists of four sprints. Each sprint has two weeks in the sprint cycle.) At the end of an IR, the product is ready to ship if required. On adopting some of the best Agile practices, our process became more lean, to the point that it increased the process efficiency by increasing the productivity gain.

There was no change in the Agile framework that my team followed before and after. Few GAAPs (generally accepted Agile practices) are practiced religiously, which made our Agile software development approach a still more lean process. I summarize them here within the context of how these practices help make Agile even more lean.

1. Backlog grooming

Backlog grooming is one of the GAAPs in which the Scrum team meets regularly to keep the product backlog items clean and up to date. Like other Agile events, the grooming meeting can be a timeboxed event.

Grooming of stories

The grooming meeting of stories generally happens once per sprint. The Scrum team meets to carry out the following activities:
  • Creating new stories for prioritized epics so they can be completed in the current interim release
  • Moving the prioritized stories to the top of the backlog
  • Adding/updating the acceptance criteria for each story from the backlog list
  • Estimating the story based on the accepting criteria
The meeting is timeboxed to two hours for a sprint of two weeks.

Grooming epics

The grooming meeting of epics/features happens once per interim release (which consists of four sprints). The PO will prioritize the list of the features that he would like to see for the product based on customer requirements and business priorities. The team spends time in grooming the epics/features as prioritized by the PO. The epic grooming meeting can be a timeboxed activity of eight hours per IR.

Following are the activities performed by the Scrum team during the epic grooming meeting:
  • Identifying the activities to develop a feature and divide them so that they are completed in one IR by splitting the feature vertically
  • Creating the stories for the identified activities of a feature/epic for the next IR
  • Adding the high-level acceptance criteria to the stories so that they can be estimated
  • Estimating the epic

2. Acceptance Criteria-Driven Development

Acceptance Criteria-Driven Development (ACDD) is an Agile approach practiced by integrating TDD with acceptance criteria. It reduces the defect rates as all the test scenarios would have been covered as part of acceptance criteria, and thus it increases the quality and value of the product by making the Agile process more lean. This approach of practicing Agile is influenced by Test-Driven Development.

3. Code refactoring

Refactoring is the technical approach in restructuring the internal logic of the code without affecting its behavior and external identity. Usually refactoring is performed to improve the NFRs (nonfunctional requirements) or to provide the extendability to the code. Refactoring is a technical debt and becomes a non-value-added activity if it is not addressed at the right time as per lean principles. Hence code refactoring becomes important and needs to be performed regularly. During the following development events, think of reaching a state of "continuous refactoring":
  • Add/update a feature: The code is updated while adding a new feature. After completing the implementation of a feature, think of refactoring. Think of refactoring every time a feature is added or updated. This brings the rigor of continuous refactoring.
  • Fixing a defect: Follow three steps in fixing the defects: red, green, and refactor. When the issue is present, it's in a red state. Fix the defect first, which makes the status green, as the feature has no defect. Then think of refactoring around the code that was updated as part of fixing the defect.
  • Code review: When experienced professionals review the code, they will have plenty of opinions about its design based on their experience in the domain and technology. Such reviews help experienced senior developers pass their knowledge to junior developers. While the developers incorporate the code review comments, think of refactoring. Based on the guidelines of experienced developers' suggestions, the developer does the refactoring. Keep doing the refactoring; it becomes a habit that leads to continuous refactoring.

Conclusion

The main purpose of this article is to share how GAAPs could help move Agile into a more lean process.

Backlog grooming

On conducting regular backlog grooming sessions, the team is well prepared for the sprint planning meetings attaining "Definition of Ready" for sprint/IR planning meetings. Having groomed the stories in the previous sprints, it helps to address the required dependencies and design discussions/decisions before planning meetings, thus reducing any waiting time.

Acceptance Criteria-Driven Development

Having the acceptance criteria for every story, it ensures that the developer implements the feature to satisfy the requirements of the PO. The acceptance criteria has multiple sections with all possible scenarios, which reduces the probability of defects, which contributes in making the process still more lean. Addressing defects is a non-value-added activity.

Code refactoring

If refactoring is not addressed at the right time, then it becomes a technical debt. Today's technical debt will become tomorrow's waste, as it requires effort to address it. Technical debts need to be addressed immediately before the product is shipped as part of next incremental release. Such refactoring efforts will trigger a reach for a state called continuous refactoring.

References
  1. http://sourcemaking.com/refactoring



Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 3.2 (5 ratings)

Comments

David Grant, CSP,CSM, 6/19/2014 2:09:59 AM
What's the difference between Acceptance Criteria-Driven Development and Behaviour Driven Development?
Saravana Bharathi, CSP,CSM, 6/19/2014 9:03:22 AM
Hello Prakash,

You have sprinkled some interesting thoughts.
For example Story and Epic grooming has to happen every sprint in rhythmic way. That way you'll have couple of sprint worth stories always ready (Not more, thinking about too much detail down the road also not good). Also I agree that re-factoring has to happen every sprint, mostly within the stories. It should become people's habit. When they see something not good, if there is an opportunity to refactor they should do it. Depend upon the current state of the code team could add 10 - 20 % of the story time to refactoring. Again I would strongly discourage the teams to add separate 'technical dept' story just for refactoring. It has to be inbuilt with the stories.

The leanest of lean approach is to release the software into production every sprint (Sprint could be even 1 day!) , yes every single sprint! Nothing can get leaner than this. You might want to think how to make 'every 4 sprint' release to 'every' sprint release, if at all possible. Certainly there are practical difficulties associated with it. Like cost involved to make it happen or bad customer experience etc will outweigh sprintly releases. Good article, All the best.
Zach Bonaker, CSP,CSM,CSPO, 6/19/2014 9:41:52 AM
Neither "Agile" nor "Lean" should be considered a process. Both philosophies, or set of values/principles, are directed towards a goal and share some synergies that compliment one another nicely. But I think there is an underlying misunderstanding in this article that we should try to "make Agile more Lean" or vice-versa.
Saravana Bharathi, CSP,CSM, 6/19/2014 11:24:22 AM
Zach,

I think you expressed it correctly. Even 'GAAP' generally accepted practice is very dangerous. If something is working for one team may not work in another team.

'Agile' is neither a process nor a methodology. There are guiding principles for you to produce high quality software, faster to the market, without burning out people.
Prakash Mallappa Pujar, CSM, 6/19/2014 10:55:29 PM
Thanks Saravana for your inputs.

We are following SAFe framework and hence we have PSIs which is consisting of four sprints.

you are correct that the refactoring has to happen within the sprint for every Story. To achieve this state which I am calling as "Continuous Refactoring" we need to have a mature team. To achieve this state of maturity the team has to start at one point. Addressing them as tech debt is not the end point but the beginning for "Continuous Refactoring"
Prakash Mallappa Pujar, CSM, 6/19/2014 10:57:48 PM
Hi David,

This is how I cam summarize TDD, ACDD and BDD.

Test Driven Development (TDD)
1. TDD focuses on the Developer’s opinion on how software should behave and feature should work
2. Following is the TDD cycle
a. Unit Test cases are written first
b. Run the test cases. They will fail
c. Developer codes to get pass all these unit test cases
d. Refactor the code
e. Repeat the cycle

Behavior Driven Development (BDD)
1. BDD focuses on user’s opinion on how our application to behave
2. The test scenarios captured are called as Acceptance Criteria. If system fulfills all the acceptance criteria then system is working as expected
3. BDD uses a template to create test scenarios. The scenarios are created in “Given-When-then” format
4. BDD borrows Domain-Driven Design’s focus on establishing and evolving a shared language (ubiquitous language in DDD terminology)
5. The test scenarios written in “Given-When-then” format can be directly translated to unit test cases using JBehave. JBehave defines an object model that enables us to directly map the test scenarios written in “Given-When-then” format to Java classes
6. At the end it’s TDD!

Acceptance Criteria Driven Development (ACDD)
1. ACDD focuses on user’s opinion on how a user expects a feature to behave
2. The user expectations are captured as acceptance criteria for every User Story. The user Stories are created against an epic which is the representation of a feature/functionality
3. Acceptance criteria are written to capture all possible scenarios like positive/ negative, NFRs etc.
4. Acceptance criteria steps will start with phrase “Verify that” to ensure that the particular scenario is verified after implementation
5. We write the acceptance criteria in present tense, to indicate how the system behaves after coding
6. If the system fulfills all the steps in acceptance criteria then the feature is said to be complete
7. Based on the acceptance criteria steps, you can write unit test cases
8. Acceptance Test Driven Development is synonym to ACDD


I can say that all these are influenced by TDD.
Prakash Mallappa Pujar, CSM, 6/19/2014 11:31:44 PM
Thanks Zach for your thoughts. thanks Saravana in replying to Zach query.

Zach you are correct that Agile/Lean are not the processes. Let me clarify the intent of the article. The intent is to make more lean in the the existing process by adopting GAAPs. As Saravana pointed out that, not all GAAPs will work for every scrum team. the individual scrum teams may have to customize these practices according to them. Such things can never happen if we are following a process.

Thanks for your thoughts.
SenthilVel Marimuthu, CSP,CSM, 6/20/2014 5:44:02 AM
Prakash,

Good one!

it will be very nice to see if you can also incorporate the Reductions in CYCLE TIME, in each of the Practices which u have described! meaning on how much lean are we in the above mentioned Agile Practices....How different

Lean = Less Wastage and the Least CYCLE Time and Adding Business Value with TIME...

Also mention of KANBAN will be best here on the Top most level of prioritization of the Requirements!

Thanks
Senthil

You must Login or Signup to comment.


The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.