Process is a way, Practice is the key

“Name of the process cannot make any magic by itself. The set of yet another BIG terminology in the process documents is not just good enough to reach your Quality goals. It’s all about your practices and how you tune them to suit the long-term(final project deliverables), short-term(iteration or sprint) and immediate(problem-in-hand) needs of your team.”

Here are some practices that can be promoted and encouraged along with the so called process improvements.

---

Ownership & Contribution

“Everyone cannot be good at everything. If someone is good at thinking of a better design, someone else will be very good at writing some complex string parsing logic. Respect Integration of Skills along with Integration of Tasks.”

• Every individual takes the ownership of delivering the tasks assigned to him.
• Everyone has the right to seek help from others when needed or offer help to others as desired.

Your Boss need NOT be right all the times

• Okay, it’s not that “Boss is Never Right” :)
• Create an environment where healthy debates over project issues/technical options take place with Quality of the project as a common goal.
• Manager contributes but doesn’t impose his ideas on the execution though he solves the conflicts. Team’s agreement is always respected.

Meaingful Meetings

Break the rules. 'Getting the job done' is the ultimate goal.

(x)Scrum is not more than 15 minutes: Not correct.

• As long as the team is discussing something useful that adds to the Quality, a few minutes extra is worth it. Remember, Agile is basically about minimizing the rework and waste and scrum is a very good platform for this. There is no point being too strict on this time.
• Remember that a considerable part of a typical software project time/cost is spent in rework and bug-fixing if the teams are not properly collaborated. Do the right thing at the right time.

(x)Everyone should stand in the Scrum: Not necessary.

It’s okay as long as everyone participates actively.

(x)Technical issues not to be discussed: Misinterpretation.

Technical issues are always on the top for discussions. Yes, you are right. Only those strategy and planning meetings cannot create working code.

Discuss things like “HashMap Vs HashTable” that caused a bug in your code; the interesting thing that you have come across about some String parsing logic that everyone should make a rule to follow; Revisit exception handling in the code developed so far with a hint from some bug encountered; Show that piece of code if it helps the team; Anything that is a parameter for the top-most goal - Quality.

The guideline is “your learning” should add to the “quality of the team” and not just the “quality of the individual”. There is no point in the same mistakes are getting repeated with different individuals at different times.

(x)One cannot speak for more than 3 minutes: What purpose does it serve?

If someone has something important to update or share, let him take the time he wants. The intention is to serve the purpose right. Don’t use ‘Stop-Clock’ methods. Maybe the issue he is encountering might lead to uncovering a major product bug which is worth fixing now than being reported by the customer.

Wisdom of the Group

“Okay, YOU are good, but WE are better together”. Different individuals bring in different insights. It’s not that everyone is to be on every task though.

Don’t wait for the scheduled meetings

If there is some potential bug or logic flaw that you have noticed, stand-up and speak it loud. Often, informal meetings are far more effective than formal and scheduled meetings. That is because informal/at-the-desk meetings are mostly about something “specific” and thus very much focused.

Knowledge Sharing

"Share the knowledge and that’s how you got it. Scrums are generally a good platform for this, though not limited to."

• Create a platform where knowledge sharing happens on a continuous basis, without saying and without planning.
• Knowledge sharing is not just those PPT presentations.

Set aside the rules, Do-What-Is-Needed

• If there is an erroneous code that has to be corrected, do that NOW before you build something more on that erroneous code. Otherwise you are consciously adding more bugs to be fixed later.
• Relax your sprint backlog spreadsheet before the flaw creeps in other places. Communicate with the other stakeholders accordingly as needed.

Be a good listener, pay attention to what others speak

Applies to everyone in the team. No more explanation is required. Don't forget that 'good learning skills are part of good communication skills'.

---

We need to understand the fact that none of these principles are meant to deal with the incompetency of the team members. It is all about complementing the individual efforts to get the job done more effectively as a team. It’s about how you can demonstrate 1+1 = 3 (Complementing rule) than 1+1 = 1 (Overhead rule).

As one can depict from the above, these guidelines are not a matter of documentation but a matter of practice. Things that are understood well can always be implemented well.

 

 

 

Is your team working as a Team?

Yes, you read it right.

Is your team working as a Team?

 

 

 

 

 

 

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