Hi there!
Often, I encounter situations where I am asked to give a quick run-down on how Agile framework works. And when I say quick, I mean in under 10 minutes. This could be a quick discussion with an executive or a team member, that I am mentoring. In this post, I decided to jot down my take on attempting to explain the Agile framework, specifically the Scrum model in under 10 minutes – by means of a drawing (see above).
I typically do this using the Scrum methodology, but you can do this using any methodology within the Agile framework. The idea is to draw this picture as you explain for better understanding of the person, you are trying to explain this to. Keep in mind, you will need to practice this a couple of times to be good at it.
Here it goes……
There is one or more stakeholder(s) who have an idea or a vision of a product, that can possibly be built and sold to a customer for profit. So the whole process revolves around a “Journey“. The journey of taking that idea or vision of the product to an actual product.
In order to complete this journey you will need a Product Owner or a PO. The PO takes the ownership of the vision that needs to be taken all the way to a product.
The idea is build this product in little chunks (features), so that those chunks (features) can be delivered to the customer as they get built and receive constant feedback from the customer and stakeholders as we go. This constant feedback is the key to success, as it gives us several opportunities to take in that feedback and adapt for improvements, as we go. Therefore the PO will need to maintain a list of these features – called the Product Backlog. As feedback comes in and business needs change, the PO will need to constantly reorder the list these features, keeping the important ones on top. This process is called Product Backlog Grooming.
Now, we need a Team (some developers, testers etc) to actually build and test this product. The team needs to work in 2-4 weeks long cycles – called Sprints or Iterations. At the beginning of each cycle the team meets (Sprint or Iteration planning sessions) to decide what items from the product backlog will be pulled into the current cycle to be delivered to the customer at the end of the sprint. The set of pulled in features is defined as the team’s Sprint or Iteration backlog. This team will meet once every 24 hours in a meeting called Morning stand-up or huddle to capture the details on these 3 simple questions:
- What each one of the team member did the day before to meet the sprint goal?
- What each one of the team member plans on doing today to meet the sprint goal?
- And if any team member has a block or an impediment that is stopping him/her from progressing to meet the sprint goal.
There needs to be some one in the team who wears the hat or plays the role of a Scrum Master. This person is responsible for day-to-day facilitation of the team to help them meet their sprint goals, by removing any blocks or impediments.
At the end of the sprint or iteration cycle, the team meets to have a demo, where the build feature is showcased to the stakeholders and customers for feedback. The idea is to enter the next sprint or the iteration with that feedback in mind, to adapt and continue to make the product better. At the end of this session, the team members do a retrospective, where they discuss the following 3 things:
- What went well in the sprint or iteration that just ended?
- What did not go well?
- And what can be done different, for improvements.
Again, the idea is to capture feedback not just on the product, but also on the ongoing process – for the sake of improvements.
So these iterations or sprints of constantly delivering a set of features continues until the completion of the envisioned product is met.
And this is the entire process, explained in under 10 minutes.