Building High Performance Agile Teams at Agile Cambridge 2012 Conference

Here are the high level details of our session at Agile Cambridge 2012 conference.


Session TitleBuilding High Performance Agile Teams 
Session TypeExperience Report
Duration90 minutes
Session Description
Agile Cambridge 2012 - Conference Schedule
Our aim is to have you leave this session with thought provoking ideas on how to improve your team's Agile model. We will be demonstrating some of the various Agile methods we have used to help teams mature from being just another Agile team to becoming a high performing Agile team.

This session will cover many different aspects of how you can improve the processes and practices of your team/s. We will touch on business relationships, interactions, communication, collaboration, team empowerment, ceremony improvements, test automation, continuous integration, continuous delivery, automated acceptance, BDD, Kanban (focus on Class of service in a defect environment) and numerous other techniques with real world examples of our own journeys.

Speaker(s)Naveed Khawaja (Morphilibrium)
Over the past decade, Naveed has helped major players in the verticals including manufacturing, finance, public/ civil service, energy, utilities and telecom.

Various organizations ranging from fortune 6 to 300 have benefited from his passion for the transformation towards continuously improving iterative, incremental and collaborative product development with a focus towards agility and leanness.

He has degree in Computer Science, is a Design for Lean Six Sigma Software green belt & is an Oxford Business Alumni  with a philanthropic agile and lean spirit.

Having five patents & two invention publications, Naveed Khawaja brings a unique combination of motivation, productivity  and innovation.


Get the slides for our session at Agile Cambridge 2012

Connect via linked in

Agile edible bites

Every now and then considerable events occur with and around us. We can either take notice and think about these or keep our concentration to the results of higher value.

While wrapping up this particular week on  a Friday evening (as captured in the photo - look carefully :)), I realized that drinking a glass of milk will give me the required nutritious value. Before placing it on the desk - it was imperative to think about the positioning of the glass on my personal kanban.

The following five columns are the standard swim lanes:


  • Backlog
  • Prioritized Backlog
  • Today's Backlog
  • In Progress
  • Complete


Fortunately, my 'Today's Backlog' has been completed and the last activity is in progress.

On any given work day, before even checking the email - I look at the backlog, prioritize it and then choose the activities of the highest value for that day (while keeping both long and short term results in perspective).
Items are moved to the 'Today's Backlog' column as the first step while maintaining the priority.

The first item in that column is picked up and moved into 'In Progress'. Then it is worked on with a focus on only one activity - known as  'Work in Progress'. Upon its completion the item is moved to 'Complete' column. The cycle continues till we exhaust the whole backlog for the day.

In the midst of explaining how a personal kanban works for me - the next item is to enjoy the rest of the glass of milk.

Have a great weekend.




Collaborative story progression

Following up from a recent post on kick-offs, here is the further evolution within a similar line of thought. 

In pursuing the path for more interactive and collaborative solution development with agility and leaness, we as a team have implemented another initiative.



Because Information is subject to interpretation, even with kick-offs in place - there is a continuous challenge of adequate expectations management throughout the lifecycle of a piece of work (story). 

After the kick-off, the team members used to go back to their silos and struggle again at the end. 
By taking another baby step of enforcing a rule of collaborative story progression - we are challenging the status quo further.


While being on a journey to develop a solution for each self-contained piece of work - the team gets together and tries to understand what is actually expected as an acceptance criteria and defines the meaning of 'done'. This includes the proxy customer or business analysts, user experience representatives, technical author, developers and test team members. After this intial session, this process continues as the test team members discuss possible failure scenarios with the development team members. The deveopers write automated unit tests while testers capture further test scenarios within reasonable limits of the acceptance criteria. 



In simple words - it is like rowing. A good streamlined start is beneficial, however - it is the continuous team effort that gets us the gold.

With this approach - there are hardly any surprises or last minute changes for a given story.

Try to change this habit of not working in isolation and you will be surprised by the immense benefits in the long run. As any other continuous improvement technique - identification of such a scenario is an effective trigger. Results will be reaped with less rework and more customer expectations that are adequately met. 

Understanding and presenting a complex problem

A fresh pair of eyes is sometimes a good solution to our so-called unique challenges. Because the new person is not biased towards a specific solution and is willing to ask 'dumb-questions', having such a discussion with a wider audience is often frustrating for the team members. Coming up to speed on a complex scenario and then offering a potential alternative in a specific domain burns alot of extra time for various team members unnecessarilty.
Anecdotes are some of the strongest tools to help us solve a problem and address the complexities of day to day business challenges. 
 This is a simple three step process yet quite challenging to master:
  1. Have a smaller (more involved) group present the contextual scenario to a reasonable level of detail informally.
  2. Identify the pattern of the situation and what is not being said.
  3. Share a thought provoking anecdote from another context that is similar to the identified pattern.

The next time you stand up infront of an audience and share the solution to a problem, it would help if you keep the solution as an analogy in another domain. The team will get much better understanding with a new context as the minds will not be hardwired to their own 'unknown-known' constraints.


Popular Posts