Agile Team (with personality observation)

Following is my message to the team (I wrote this on 5 something a.m. today because my brain was just wired with these messages when I woke up suddenly):

When we started Agile few months ago, besides hoping the team can be more effective and efficient, it also intended to serve as an eye-opener. That is - old way does not always work best and there are always possibilities to change for the better. It is not changing for the sake of changing. It is changing for the better. But no one knows exactly what need to be changed to be better. That is where the Agile is a project for exploring this.

During the introduction to Agile, while the perceptive types were mostly supportive of the agile approach, the judging types (maybe only those who are strong in judging) were mostly skeptical. Because the perceptive like the flexibility and keeping their options open while the judging types prefer the big up-front planning, which probably take days or even weeks to come out with only the plan. Am I right? :)

We are repeatedly reminded - Agile is no silver bullet. Nor is everything in live.
The answer then lies with the balance. Even with judging or perceptive type, there shall be balance between both. One should have plan, but one also should not be too rigid to change.

Before we go any further, let’s explore how we had fared so far. And later, let’s see what or where we can continue.

What we did right or wrong in Agile?

Maybe we should always have 2 types of plans. One is a long-term plan, which serves as a vision and to provide guidelines and principles so that one will not swerve out of course. Another one to complement is the shorter and more flexible short-term goal.

The big plan and the product feature list that product/ management team did is the long-term plan. Agile Sprint planning is the small plan, flexible yet strongly within the scope of the larger plan or milestones. Thus, do not get confused. When we have the big plan all laid out, we do not need to plan for Agile Sprint anymore.

We also seem like given up the point estimation. Why? Is it because the requirements are uncertain? Is it because it is easier not to estimate? I may imagine the Feeling type cringes on this – "let’s not think about this too much, just do it with our feel!" Or the sensing type – "I do not know what is the scope yet or how large is the scope, so I cannot estimate." Or even the intuitive type – "I can only see the big picture, but I do not know in details what need to be done, so I cannot estimate."

So, doesn’t it ends up ALL of us are still inept in estimating? In this particular case, personality does not help. Only experience and persistence will. Estimation is the upfront thinking process – the planning! Nobody said Agile does not need planning. If we cannot even do a good estimation for a 2 weeks project, how are we going to estimate any better for a 3-months project plan?

Though the personality test revealed something on all of us. But there is absolutely one thing the test is not telling us. That is how efficient and effective we are in doing our tasks. You may have a big picture, you may plan well or you may sense something is wrong, but nothing happen until you do something about that, for e.g. go and fix the bug now or executing the plan.

And talking about procrastination on planning, it is prevalent among all the team members. Of course, we have tried many times to plan on Friday when the following Monday we need to start new sprint, which is good. But that only happened like one out of six times.

As for SCRUM meeting, yes there are latecomers. I believed I contributed large part on this, especially lately. :). Worst is that everyone is waiting for others to call and when nobody calls, there is just simply no meeting.

During the SCRUM meeting, problems arise with people not making their points and people not listening or understanding the points being made.

And also, there is no more review meeting at the end of sprint, which is actually a time to celebrate after the lost of blood and sweat.

On top of all that, the Agile strongest advocate (yes, me!) is leaving and there is no one really driving this anymore. Although, I did slack in most parts also. And I am slacking much more now. (Unless you have already resigned and only have few weeks left from leaving a company, you will not understand how unfocused one can be. A simple and no-brainer job may seem quite impossible to achieve. :) . Believe me, you will get to this point someday. I initially did not understand this also. Or maybe you are not my type of personality and you will not.)

What we can do next?

Ok, enough of story writing. Let me make my point here on what we can continue to do or improve:

Sprint Planning:

1. Continue to plan for Sprint. Maybe we can improve this by planning 2 Sprints ahead instead of one.

2. Plan the sprint before the sprint starts. Plan for the plan to happen, i.e. allocate like one day before the sprint start for requirement study/understanding and planning.

3. Continue to provide the estimation as accurate as possible. Use past estimation to serve in relative. Leverage on your past experience.

4. Get approval for the sprint plan before going ahead.

SCRUM Meeting

5. Reduce the SCRUM Meeting to 2 to 3 times a week if you feel it is necessary.

6. Start SCRUM meeting on time. In fact, start all your meetings on time.

7. Do not wait for the latecomers to start. Let guilt guides them to come on time. J. How about like those who miss the meeting or on leave is requires to follow-up by sending out an email to the team on what they have achieved? Be creative in encouraging people to be on time and attend the meeting without reminders.

8. Change the mixing of the team in the SCRUM meeting once a while so that each team can interact with other different teams. If we reduce the meeting, all teams can meet at the same time but on different alternate days.

9. Be energetic and precise in getting your points across. Train yourself to speak like you are presenting to your customers to market what you are doing. The objective is getting people to understand and learn what you are doing. Ensure you are getting your message across, not merely just sending your message.

10. Try to listen and understand what others are saying. Ask if you are not clear.

11. Be spontaneous. Be sporting. Be efficient. Be energetic (yes, want to stress this again). Do not try to look around at others and pretend it is not your turn to speak!! (I guess this is an unconscious gesture we always make because we are mostly afraid to speak up).

12. Improve the process on how to take turn to speak. Try to volunteer yourself to be the first to speak next time. Do not always get comfortable with the wait-and-see behaviour.

13. Speak fluently and maybe give a more complete sentence. “I am doing stylesheet for Company X, which is task no. 5. ” as opposed to “I am doing no. 5 lor”. No harm to re-iterate things to make the points. A common truth about communication is that even if you repeat the same things 7 times, there will still be people who claim to have listened to it for the first time.

14. Be reminded to tell people what you have achieved and what you are going to achieve next. You need to KNOW what you are going to do next. If you usually do not, then you need to start to see how you can improve that because effective and efficient person always knows what are their next things to do. If it is not planned out for you yet, chase someone. Take initiate to plan by yourself also, if need be.

15. Be open. No one is there to judge you or evaluate how you are doing.

16. It may be a good idea to let others know sometimes the percentage of completeness like ”I think I still have 50% to go” (maybe not all the time depend on your liking). I got to know that someone came up with this before and someone also quickly opposed to this, which led me to the next point also.

17. Do not just shrug off suggestions. No one knows what is the best agile method or approach. It is up to the team to experience and decide whether it should stick or it should go. Also come to next point.

18. Arguments are strongly welcomed sometimes. Just because someone objects to your idea, does not mean you cannot argue back. Of course, please be rational and carry this out in a peaceful way.

Sprint Review:

19. Always have review after the sprint has been done. Either a demo or have the QA or product person to walk through the completed functionalities to confirm the correctness and completeness.

20. Plan the sprint review upfront.


General:
21. Continue to refine the Agile approach in all areas to suit our needs.

22. Volunteer to advocate the Agile approach if you are interested. We need people to continue the initiative to improve the practice.

23. Everyone needs to work together to find better ways to work together.

Further reading:

Ten Common Mistakes of going agile
Agile Requirements – no BRUF just GRIT

And, something to revive what a SCRUM meeting look like:



Sorry, for being brash on all this. The points made here do not come from a Manager, but is just a form of sharing.

A couple of great people said subordinates always see the red flagging light on the manager’s forehead because a manager can reward or fire them. So, just merely the presence of a manager will jolt you awake. It is always there, no matter how friendly is the manager or how good is the subordinates to try to treat the manager impartially. Thus, subordinates always will keep their guard on when dealing with their managers. It is natural and logical.

Since I am not really your manager now, I can be more frank and brash and not afraid to hurt you guys or drive you away. And I hope you will do the same to me. And because I am not really your manager now, it is easier for me to ask you guys for outings and not afraid you turn down because you scared of revealing yourself too much or you turn up because you are too scared to turn down.

Isn’t it ironic? :)