Making the Agile Extra Lean by Adopting New Practices

[article]
Summary:
Prakash Pujar writes about his team's experience adopting some of the best agile practices to make their process extra lean and increase efficiency by increasing throughput—all without any change to the agile framework his team was following before and after. Here, he talks about some of the lean practices that worked for them.

The core idea of lean is to eliminate or at least reduce activities that don’t add value (waste) and thus increase the customer value. You can think of agile as a form of lean methodology for software.

My team follows an agile methodology that serves the needs at an enterprise level, producing frequent interim releases at every four sprints. At the end of an interim release the product is ready to be shipped. On adopting some of the best agile practices, our process became extra lean and increased efficiency by increasing the throughput.

There is no change in the agile framework that my team was following before and after. We simply adopted some of the generally accepted agile practices that made our existing agile software development approach leaner. Here are some of those practices.

1. Backlog Grooming

Backlog grooming is one of the agile practices my team adopted and practices religiously. My Scrum team meets regularly to keep the product backlog items clean and up to date. Like other agile events, the grooming meeting is a timeboxed event.

Grooming of Stories

The grooming meeting for stories generally happens once per sprint. The Scrum team does the following activities:

  • Creates new stories for prioritized epics so they can be considered in the next sprints
  • Adds or updates the acceptance criteria for each story from the backlog list
  • Estimates the story based on the acceptance criteria. Yes, we do estimate some of the stories, but not more than we can complete in this interim release. The reason for estimating is to attain a state called definition of ready for the next sprint planning meeting.

The meeting is timeboxed to two hours for a sprint with two weeks. The team creates stories that would be worked for next sprints. We create the stories well in advance to solve any impediments we might encounter in addressing the stories. We have time to resolve those impediments from grooming to sprint planning meetings by talking to the product owner, architect, or any member who would help the team to clarify queries. As this activity happens in the background, there is no waiting time involved to remove any impediments identified in grooming meetings. By the time the team meets for the sprint planning meeting, members are clear about the sprint’s goal.

Along with creating the stories for the next sprint, we also update acceptance criteria for stories and estimate the stories. Considering the timeboxed event, we may not do this for all the stories for the next sprint. Any remaining stories would be updated with acceptance criteria and estimated during the sprint planning. 

Grooming of Epics

The grooming meeting of epics and features happens once per interim release. An interim release spans for four sprints. The product owner prioritizes the list of features he would like to see in the product based on the customer requirements and business priorities. The team spends time in grooming the epics and features as prioritized. The epic grooming meeting is also a timeboxed activity, with eight hours per interim release. These meetings are conducted on separate days and take half a day each. We go back to the product owner after the first part of the meeting for any clarifications.

Pages

User Comments

2 comments
Philip Heath's picture

Nice post.  We are currently in the process of defining our enterprise agile process, and I am spending a lot of time looking at things related to item #2 in your list.  One thought we have is to combine ATDD with TDD to have both unit and acceptance tests automated.  Are your acceptance tests in addition to or in place of unit tests?

August 15, 2014 - 3:48pm
Prakash Pujar's picture

Thanks for your comments Philip.

We are following acceptance criteria driven development along with automated unit tests execution. As I have mentioned in the article, every story has acceptance criteria and we claim the story is done only if the developer satisfies all acceptance criteria.

We also do write unit tests which is integrated as part of our continuous integration framework and these unit tests are executed every day along with daily builds.

August 18, 2014 - 12:23am

About the author

Prakash Pujar's picture Prakash Pujar

Prakash is a CSM, SAFe practitioner and Lean six sigma expert.

 Holding a Bachelor’s degree in Computer Engineering from MIT, Manipal, he is Scrum Master and Agile Coach in an MNC in Bangalore, India He has over twelve years of professional development experience after which he is transitioned into agile world. He has five years of practical experience in Scrum and other agile methodologies and practices.

He is practicing SAFe (Scaled Agile Framework) over two years and coaching agile teams in his organizations to drive SAFe. Being an agile geek, he has hands on experience on how Scrum, Lean and generally accepted agile practices bring more value to the team as well as stakeholders and increase productivity.

 He is active member on Scrum Alliance forums and has published four articles as on today. One of his articles featured in the monthly newsletter of Scrum Alliance for the month of July 2014.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!