Article: Agile Transformation: 3 tricks to help you improve the odds

A Brand Reachout InitiativeEmployee Engagement

Agile Transformation: 3 tricks to help you improve the odds

Create the Future Read similar articles

 

Here's a toolkit to help you navigate transformation
Agile Transformation: 3 tricks to help you improve the odds

An organization’s success is determined by how quickly they adapt and respond to the changing environment. External forces like globalization, digitization and fierce competition are compressing product lifecycles, time to market, and delivery time. They are also making technological advances and innovations faster and more frequent. To handle these changes, organizations need agile teams who can get work done faster and better. However, a key question that needs to be addresses is whether it is possible to develop your teams into ‘agile’ ones? 

Although, there is no recipe to create the perfectly agile team, because every culture and organization operates in a different context, there are certain commonalities which contribute to a teams’ success. Let’s delve into three common practices that will improve some odds of transforming teams into agile and high performing ones.

Three Practices of Successful Teams:

Are you (ready to cook): This practice states that a project should be ready to be worked upon as soon as the team picks it up. However, the question that arises is what makes any project ‘ready to cook’. The following three elements should be looked at to ascertain that:

  • Not ambiguous: The title of the project should be clear and obvious. The project should be actionable, and where errors can be fixed easily.
  • No questions left: The team should seek as many answers before they start working on any project in order to save significant amount of time. The questions can be anything ranging from “what do the customers want or how to approach a particular problem”.  
  • Clear end goal: The team should be able to tell what are they trying to accomplish and how did they go there.

Once the aforementioned three elements have been chalked out, the team must check for some ideal qualities of the project which make it further ready. INVEST framework (which is an acronym) beautifully captures the six qualities:

  • Independent: Projects should be able to stand on its own and not depend on others. They should be easier to understand and each should be wrapped up entirely before moving on to others. This will also help in managing the backlogs.
  • Negotiable: It implies how teams should best approach the projects once they pick it up. It doesn’t mean avoiding any specific details; rather it is more about focusing on the high level end goal of the project.  
  • Valuable: It is about making a meaningful impact on the product and value to the customers. 
  • Estimable: It is about how well one understands the project. The project should be clear and small enough which one can hold and process effectively. 
  • Sized appropriately: Projects should be big enough to make an impact but at the same time should be easier to understand.
  • Testable: It is about understanding how a project is finished and testing the end result.

INVEST helps us decide which projects need to be picked up and also warns teams about the backlogs.  

Backlogs are the list of those projects on which teams are not excited to work on. DEEP framework provides yet another set of criteria which helps teams distinguish good projects from the backlogs. It says that good projects should be ‘Detailed appropriately and Estimated well, and not Emergent like backlogs which change over the course of the project. Lastly, these should be Prioritized well’, the most important projects should remain at the top, while the less urgent should be at the bottom. 

Done means “Done”: “How do we know that the project is complete?” The best way is by asking customers few questions to capture their answers:

  • What is the goal? : What did we try to accomplish with this project? And what was the end goal?
  • Corner cases or exception: There will always be some corner cases but teams must deal with it carefully.
  • What will we not do?: It is all about defining our boundaries so that there are no surprises at the end. 

Once the aforementioned aspects are clear, chances would be high that the projects would be accepted by the customers. Well accepted projects clear out misunderstandings if there’s any between the customer and the development team. Once the criteria is decided, team members should come forward and together decide on the ‘done’ criteria where projects would be considered completely finished. It can be anything ranging from ‘Unit tested’, or ‘Peer Reviewed’ or ‘Added to deploy script’.

Keep It Together: The last practice is about keeping teams together once they are formed. Teams can be formed instantaneously however they take a lot of time to evolve. Every time a new team is formed they go through the following stages:

  • Forming: in this stage teams start and feeling each other out. People mostly remain quite and don’t interact much. This stage doesn’t last very long.
  • Storming: At this stage, team get to know and trust each other. Team members challenge each other’s opinions owing to which conflicts also start arising which can be good if handled and channelled carefully.
  • Norming: In this stage people start to gel in real terms and start following a normal routine.
  • Performing: At this stage teams are usually on fire and they know how to work together and manage conflicts which are mostly productive in nature as they solve the problems.

Most of the teams go through this process and whenever a new team member joins, the entire dynamics changes - process resets and starts from the beginning. Also each team varies in terms of how long they take to gel with each other. One should be patient and give team ample time to work as one cohesive team. It is usually seen that smaller teams take less time to adjust—the ideal size of the team should vary  from 9 to 5 (7+-2). If team is smaller than 5 members, it will be difficult to plan and get bigger tasks done without outside help. Members more than 9 will be too big to handle and will pose a threat of members stepping onto each other. Even the recent research at Harvard indicates that optimum size of the team is 5 people.  This team size is not just restricted to the IT set up rather it can be generalized to many other occupations.

To summarize, teams should pick those projects which are ready to be worked upon, they should further INVEST and ascertain the qualities a project should have to ensure that there are no backlogs. Once the project is picked up and worked upon, acceptance and done criteria should be well defined to ascertain if the project is finished and the end goal has been accomplished. Last but not the least, sincere efforts should be made to keep the teams together to make them happy and productive.

This article is written in partnership with Pluralsight a technology learning platform which provides the agility to accelerate market leadership through technology, grow and retain top talent and deliver on key business objectives. 

Read full story

Topics: Employee Engagement, Life @ Work, #Create The Future

Did you find this story helpful?

Authors