Bootstrap Agile with Agile

If your organization is planning to roll out Agile processes, take it step by step starting from addressing the process issues in a priority manner just like you handle your customer projects. Let this knowledge and lessons flow from individual to individual and from team to team until at least the processes get stabilized. Let the teams be participative in the process improvements, and don’t try to force it hard, without reasoning, and don’t forget Agile principles here as well.

 

Collaborate People:

Collaborate with the team(s) in identifying and prioritizing the pain-points of the existing process. Suggested approach is to ask stakeholders from different roles and different experience levels to participate. This will bring the possible 360 degree view.

Be ‘specific’ about the problems and the proposed solutions. Don’t use text book statements. For example, ‘Follow iterative development model’ maybe too generic solution but identifying ‘What exactly would be the deliverables’ with an iteration's code drop and ‘How should we be following up with the customer’ will be specific.

Process the Feedback:
What is that you implemented right?
What can be done better?

Let the lessons (good and bad) be shared across the iindividuals and the teams.


User Stories:
As a Developer, what is working for me and what is not working for me?
As a QA Engineer, I feel I need these requirements.
As a Project Manager, here are the issues that I would like to address.
…

Take out the Waste:

 The whole purpose of Agile is about minimizing the rework and waste and maximizing the productivity. So, implement only those principles of Agile that your team really needs. What worked for the other organizations and the teams may not be the same as what your team needs.

Example: If you don’t really need burn-down charts, don’t use them. If User Stories do not make any sense to your specific project, keep them aside. It is not just about spending time on things-of-no-use  but you are loosing time to be spent things-of-use.

Ask this simple question, “Is this method making my team do better or worse?”. Betterment is not always about doing new things. It maybe about not doing the things that-are-not-worth-doing i.e., taking out the waste.

To summarize, consider your process change also like a mini project, sticking to the basic Agile principles, processing the feedback with continuous attention with proper team collaboration. Things will fall in place in a matter of a few weeks. We may call this ‘Bootstrapping Agile with Agile’.

A process that is organically evolved would always carry more value than a process that is purely taught. As much as possible, try not to be biased by the name of the process but focus on the Goals that you need to achieve from the process that serves the interests of all the stakeholders.

 

 

What 'exactly' are the issues that you would like to solve with Agile?

What are the 'root causes' of these issues (not symptoms) so that you can plan implementing Agile from the roots? Remember it should not become yet another process.


"Attribution: Images on this post are downloaded from FreeDigitalPhotos.Net"