But the question is are you really following the true spirit of Agile?
Answer the following questions and find out.
1. Do all the members in your team share responsibilities?
2. Do all the members in your team know clearly what is to be done with in a sprint?
3. Is the metrics e.g completion status and bug count up to date by itself?
4. Do your developers and QA spend most of their time on their desk working instead of meetings?
5. Is most of the stories/features completed with no bugs with in a sprint?
6. Do priorities comes from Product Management and estimations/cost come from Developers/QA?
7. Are there no extra meetings than daily scrum, sprint planning and demo meetings?
If you answer Yes to most at least 5 questions than your are following Agile to a good extend.
The irony I have seen in Organizations (prev Waterfall) people are been told to follow Agile. Agile can not be told be followed, he has to be sold. Its more of a mindset than a process.
Any Process that is closer to becoming a mindset has much better chances staying alive.
Lets start at ground level up, by following agile your Developers and QA should have following benefits
- They should be spending more time doing their core work on their desks. If they are in any meetings these must be mostly due to their own need to collaborate on understanding a feature or design or an approach. If your developers and QA are being pulled in to meetings by project manager, THIS IS NOT AGILE.
- Agile means doing common sense, more trust delegated to people. If asked to any member of the team what is the sprint goal and upcoming release goal, the developer/qa must be able to clearly mention this. This is what we call People over Processes. We invest in people and trust in people. Processes are need only when
1. Managers fail to communicate the goal to the team
2. Organization lacks trust
3. Weak Leadership which is unable to replace people who do not align with
Organizations's Supreme Goal.
That is why I am against extreme processes. An Organization which relies heavily on Processes is either
1. Concentration Camp
2. Deck of Cards which keeps on falling apart
- Agile needs team members who can share responsibilities. The easiest way to make this happen is to show employees that you have trust in them and keep on grooming them. Keep appreciating regularly what people do correct, so it becomes a habit and keep communicating what is expected from them, so they are constantly reminded. If your team has 1-2 heros who pull of things, this is a BAD sign. ACT NOW and give others opportunity to become successful with in the team.
- You as the person in charge needs to make sure team is not pulled into extra meetings (which management requires) and they are stopped from working. This only means they are always serving others and in doing so staying late. Project Manager/Scrum Master needs to go to the team and provide them information instead of calling them to meetings. I personally saw this helps in getting a team extremely productive and motivated.
- Lets go a level up, team should be provided the right information at the right time. Only then you can expect productivity out of them. Product Managers are required to communicate what they want from the team well before next sprint. They are to clearly give every thing the team needs. Say mockups for functionality expected. If Product management is stretched or absent, a QA preferably or developer should be assigned a story to create a mockup or PoC of the work to be done in next sprint. This than has to be then frozen by Product Owner/Manager. Idea is team needs to be told what is expected out of them.
Another important and most difficult point is estimations should come unbiased from team members. Although most Organizations like to have some control on these, more or less Team Members should be told to drive the estimates to get the best quality shippable product
- The team needs to become mature for Agile mind set. This is all about taking responsibilities and understand how metrics and information flows in deciding the fate of Organization. Ground level metrics (light weight) like how much a user story is complete, which user story is started on, what is the bug count, needs to be done by the team by itself. Unless this does not happen, team is not mature. The team needs to understand where their status updates and metrics used at high level to take decisions.
The above can not be found in any Agile book or workshop, but had been by personal experience to running a highly effective team.
My 50 Cents on finding out If you are really Agile or not.