Agile – a change in Mindset

WHAT is Agile?

Agile is not just a methodology or a framework which tells us how to work. In a broader sense , I can say, it is a CHANGE IN THE MINDSET.

Agile Development holds that that requirements emerge & evolve, and however much analysis and design you do, this will always be the case because you cannot really know for sure what you want until you see and use the software. Since ages we have been working according to waterfall model where we used to accomplish below activities in a sequential order.

    • Plan & Gather requirements
    • Analyze requirements
    • Design
    • Code
    • Test
    • Finally, Deploy

Through Agile, we are uncovering better ways of developing a software by doing it & helping others do it.

That is, while there is value in the items not highlighted, we value the items that are highlighted more.

Agile Manifesto

Imagine a scenario where we have to build a CAR. In Waterfall model we will develop all the detailed documents, right from Requirement gathering to Design to Build and Testing. For many months in the cycle the Users & Owners will not able to see the Product itself. And that’s the pain. If for any reason user or the owner wants to change the design, it means either it cannot be changed or else the business will have to bear a huge cost to do the changes. This means that the scope of improvisation is quite difficult in case of waterfall model. Thereby we have 12 vibrant principles.

Agile Principles

Using Principle P3, the user can see the working model in intermittent intervals. They don’t have to wait long to see the working model, unlike waterfall approach. P7 clearly says that the measure of progress will be a working model. P2 ensures that the changes can be welcomed even at the later stages of the development. This means that agile teams will have to change their mindset to take up any changes according to the User & Owner. P4 mandates all the stakeholders – Product Owners, Development Team & Users to connect & work together on a daily basis towards a common goal.

Agile discards the creation of detailed documents & it streamlines the planning for smaller chunks of working product. Get this correct,

Agile doesn’t eliminate the Planning but it does eliminate the long-term planning & deliverable.

It focuses on short term plans every week.

Let’s talk about two issues in waterfall model – Multitasking or Context Switching & Handoffs.

Context Switch is exactly opposite of Focus.

The individual is working on multiple items at the same amount of time. A context switch is the process of storing & restoring the state of a process or thread so that execution can be resumed from the same point later. And this is costly in terms of deliverable. Imagine a scenario, a member is working on a code. Suddenly, her manager asks her to respond to a very urgent mail from business. She reads the mail and responds in due time. But once she is back to the code, she will have to spend some time in recollecting where she had stopped. This transition period is called “context switching”.

              In agile, there is a limit to multi-tasking. Team member works only on limited set of work which is of high value. This require more focus as against waterfall.

Handoffs are basically handing over the tasks or deliverable to another team member.

This is ideally an inefficient & overloaded task. Lot of time gets wasted in waiting for someone to complete the work. For e.g. developers developing the code and handing over the code to tester to test.

              In agile, the large batches of work are broken down in small batches to work. Individually, the one has to work with lesser efficiency. But the process soothes as the load on one person reduces. And the handoffs also get limited. P8 suggests on sustainable development. All – Sponsors, developers & users should maintain a constant pace indefinitely.

Agile has Sprint goals which is a time bound iteration of work intended to deliver a shippable portion of Product in a shorter scale of time. In this case one can realize that the productivity of the team increases & PO gets the product early, while the individual productivity of the team member decreases. How? In agile team member doesn’t complete the entire development, rather he just delivers a small portion to another member. In this way the waiting time between the members is eliminated.

Another key principle – P5 & P11, tells how to get the work done efficiently and smoothly.

The team which is highly motivated, self-organized, cross-functional and whose members doesn’t take the directions from others perform the best.

Such members don’t work based on their own functional role, but they have the agility to take up other roles as well. Also, such teams invest lot of time in cross skilling themselves.

In order to understand P9, we will have to understand the Pereto principle.

The Pareto principle or the 80/20 rule means that typically 80% of your results may actually come from only 20% of your efforts! 

The idea is to focus on the important 20% of effort that gets most of the results. If you have control over the scope, and if speed-to-market is of primary importance, then we should seek to deliver the important 80% of the product in just 20% of the time.

In order to achieve the desired product, a good design & excellent technology plays a very important role. Rather than choosing a complex & cutting-edge technology, its crucial to choose the right technology & simple design. And this is aptly explained via principle P9.

Let’s talk now about roles & responsibilities in the coming section.

Product Owners & Business Analyst are not similar entities.

BA’s create detailed & clear project requirements and are basically the intermediates between the business and the team. PO’s create User stories which again should not be misunderstood as the short version of project requirement. They are basically placeholder for future communication.

User Story should talk about a VALUE that the user expects after the product delivery. In another words, it is value statement in the view of user.

Here comes the Agile principle P6, which mandates F2F communication between all the stakeholders without any documentation.

    • User Stories depicts – WHAT a user wants. And, HOW is left over to the developers.
    • It’s a way to communicate to stay focused.
    • It is not an agile version of requirements.
    • It’s a note to have future communication.
    • It helps the team members to ask right set of Qs.

In order to meet the agile principle P1 – which suggests that the customer satisfaction is the highest priority.  This is achieved via Task board. It has four headers.

    • User Story
    • To Do
    • Doing
    • Done

Based on the status of the work, the members keep the user story in any of the headers mentioned above.

This is just not to track what team is working. But it depicts which highest valued feature team is working upon. The team does experiments and embraces changes in the due course. The developers follow principles P3 & P8 to deliver the code frequently & maintains constant pace.

    • Each team member works in a Timebox.
    • At max., 8 hours of work is suggested.
    • No overtime suggested as it disrupts the team predictability.
    • Normally, scrum follows a timebox of 2 weeks.

What is scrum?

Scrum is an agile framework. It enables the team to embrace agile mindset.

It allows to run experiments to improve the product, thereby allows to inspect & adapt quickly. Some of the other frameworks in the market are Extreme Programming & Kanban.

The keyword sprint comes from scrum framework. And Sprint helps in achieving the principles – P1, P2, P3, P7 & P8. It enables the delivery incrementally & iteratively. Incrementally we all know now, to get the working model in a shorter time scale, while iteratively is a process to improve the delivery at the end of every sprint.

Remember, there is no agile manifesto while tells that the team should deliver in sprints. And other entities like PO, Scrum Master, Product Backlog are not part of agile manifesto. They get their existence from Scrum framework.

Every sprint has 4 phases:

    • Sprint Planning Meeting
      • First day of the sprint.
      • Plan work for entire sprint.
      • Should be less than 2 hours.
    • Daily scrum
      • To track the progress daily.
      • Less than 15 mins.
    • Sprint review & Deploy
      • Product review.
      • Should be less than 2 hours.
    • Team Retrospective
      • Discussion on how to collaborate & work better.
      • Talks about process improvement.
      • This reflects the principle P12.

Scrum Master Role vs Project Manager Role

    • SMs are NOT project managers.
    • Rather they act as a Coach, trainer & administrator.
    • They encourage the team to take greater responsibility.
    • They motivate the team & coaches them to become cross functional.
    • They encourage team to self-manage & become self-organized.
    • They act as a “Bulldozer” who dozes off the obstacles & “Shield” who protects the team from outside influencers, respectively.
    • They act as conflict negotiator as well.

Product Owners Role vs Business Analyst Role

    • PO’s works with entire team to deliver the product.
    • PO’s shares responsibility with the team.
    • PO’s don’t handover, they rather own the product.
    • PO’s have the authority to make real time decisions.
    • Every agile team needs a customer representative & PO fills that space.
    • PO’s create a very important list called “Product Backlog”. This is a ranked list of different features that PO would like to include in the product in some point of time. In fact, not just user story, we can keep anything under backlog.

Product Manager are closer to PO who sets the direction & prioritize the work.

    • PM creates the long-term strategy.
    • PM creates the budget.
    • Once PM have the vision, then only he includes the PO to own the product.

BA’s move between the business and the developers.

Entire structure and process helps to combat another issue – “Groupthink”. In a normal framework, few experts in the team decides about a problem and it is mostly agreed by all. But agile counters “Group thinking”. This means that even a tester has full right to ask tough questions to developers on the design of the DB.

Finally, do you want to know how the estimation is done in agile? In order to reach to a common consent on user story, there is an intuitive process in agile called “Planning Poker”. This is basically a consensus building exercise for whole team to deliver the common the product. It shares the understanding of everyone to deliver the user story.

In this competitive world, any company needs to adjust their product even before their competitor does it. In this regard, agile will be much beneficial. Moreover, it’s even better because the team becomes more productive than the individual members. Every member whether a junior or an expert have a say in the product & they feel proud to show their results. Customers and User can see a working model & are able to prioritize based on the latest insights.

To conclude this topic, I would remind that agile is nothing but a change in mindset. While transitioning from old traditional model to agile one must be very cautious that they are not twisting the old roles to fit into agile. The roles are very much distinctive, and the management must understand it very thoroughly.

Leave a Reply