Is Agility for me?

Is Agility for me?

It depends on who I am:
  1. A business leader or executive
  2. A project leader
  3. A team member
Agility yields good results if the entire eco-system of an organization is Agile. It is common to see friction between agile and non-agile layers of the organization. This friction becomes counter-productive, hence, it is important to have Enterprise Agile strategy. Here are the key parameters you can consider for Agility at various levels:

1. Organization
All companies face the problems that agility addresses, but not all companies are ready for the radical ideas needed to become agile. Agility is still a developing topic and it should only be addressed by people who are not "risk adverse". As an example, one of the common risk for the executives is uncertainty of what will be delivered at the end of a release in agile projects. Well, this perceived agile risks hinders lot of bigger risks that non-agile methods have.

Organizations who want fully worked out answers and concepts and a solution that they can implement with little risk should stay clear of the topic. Business Leader/Executive responsibilities for Agile include:
  • Nurture innovation
  • Focus on integrating value
  • Driving force for the Agile strategy and business success
  • Invest in the predictable Agile delivery
2. Project
A project needs to have significant urgency, complexity and novelty (uniqueness) to be a good fit for Agility. Project lead should review the following aspect of the project:
  • Novelty: We want to use agile when we are doing something that is new, or at least new to the team building it. If it’s something the team has done before over and over then the team probably doesn’t need an agile approach.
  • Urgency: The timeboxes and iterations of an agile approach are devised to keep the intensity and focus going on a project. If there’s no urgency to the project, those are unneeded.
  • Complexity: Project should be complex enough to use a process. It may not make sense to apply agile for data entry.
3. Team
Agile is a complex adaptive system. It can not succeed without self-organizing team members willing to adapt constant changes. Agile focuses on shared responsibility instead of command & control.

How do I identify level of agility at the team level?
Here is a list of key parameters, which will help you gauge your engineering team's agility.
  1. Agility of your engineering practices: Can you build, deploy, and test (automatic) with every code check-in? [high agility] v/s [low agility] Do you give a build to QA on a weekly basis to test?
  2. Quality of user stories (requirements): Are you able to write good user stories which can be executed in less than a week? [high agility] v/s [low agility] Your user stories can't be broken down to fit in a sprint and team needs multiple weeks to complete those as per the definition of "done"
  3. Sprint (iteration) Overheads: Sprint reviews are very light-weight.  [high agility] v/s [low agility] Team needs to rehearse before giving demo to the stakeholders. Team is complaining that they hardly get time to code. In other words, you need to minimize sprint overheads to have shorter sprints.
  4. Cross-functional team: Every team member can work on most of the tasks, hence team always works on the highest priority tasks.  [high agility] v/s [low agility] Team members have special skills, hence, tasks need to wait for those people to be available.   
  5. Ability to rapidly change: Flexible architecture that allows to rapidly adjust with changing business realities with some refactoring.  [high agility] v/s [low agility] Rigid architecture that may require complete rewrite to meet changing business needs. 
  6. Technical debt: Low amount of waste [high agility] v/s [low agility] High amount of waste.

Here is non-software specific view of agility:


Consider this as a starting point. There could be many more ways to find agility of your team. If you really want to findout then just give Agile a try. Pick a sample project and explore. You may also review Agile Adoption Process.

References:
  • Featured Articles [articles]
  • Agile Rules of Thumb [rules
  • Deciding What Kind of Projects are Most Suited for Agile [article
  • Self-Organization: The secret sauce for improving your team [video]

2 comments:

  1. Different terms get applied on overall productivity according to the requirement so this is the way how it is and i am sure business agility can also be bring when we think of getting a finer outcome and that.

    ReplyDelete
  2. If a team is growing overall in the best possible way they can actually help other people with getting better,Like scrum guide is a very fine way with doing better and at the same time having what we need can help us for sure.

    ReplyDelete