Decision making in Agile Transformation
One of the key elements during Agile transformation is about having your employees participate or totally own the decision making at the product feature or functionality requirements. Specially when they have spent many years in Business Analysis or Design products.
During the Agile boot camp the leadership teams must train people about the key business priorities and metrics on what makes the product success which makes the business a success. Dont hold them back or not add the “yes you are allowed to take decisions” to their job role during transformation.
By not doing so, you are not only not following the Agile principles but also not creating transparency and having employees to reach out to management for every decision which could hurt the time factor which is critical.
The only key metric or deliverable is the Continuous Integration OR Continuous Delivery that makes end users engaged in the business
Beyond, each organization anyway will have performance measurement or people evaluation methods each year or at some point that way the organizations will be able to assess if the allowed decision making power is working OR any imporvements or reassessments to be made.
Email communication in the modern corporate or business environments –
Email writing in the modern day corporate world has certainly changed. With offices spread globally, large teams, multi cultural teams, increased customer expectations, 24/7 information exchange, high end infrastructure, enhanced transparency, service level agreements etc., have added to “how exactly an email or communication has be drafted and sent to the intended recipients”.
Based on my experience the following have to be given most importance while drafting email –
- Include recipients who are precisely need the information are included in the To list. Avoid a thought that this person may need or should be kept in the loop unless you are not escalating any issue that has gone beyond a certain stage
- Unlike a conservative approach or too diplomatic directly get into the subject may be from second or third line. If the recipient has no prior background or the context of the subject you are talking, please make use of the first 2 lines to quickly mention about the subject and then get into the detail
- Do not beat around the bush – get right into the detail why are you sending this email and that too today (now). Your perspective, any data or statistics you have for the recipient to read thru and understand better. Remember “Data” than “opinion” always carry more weight
- Note that avoid paragraphs of email body unless you are writing a newsletter which is not considered email at all. People in the modern day corporate environment are ALREADY overloaded with data from various devices, contexts, people etc., so your email should carry enough relevance for the recipient to read, understand and do something about it. Crisp communication is all we need
- In my experience of dealing with superiors or people that i report to or stakeholders have always asked one question- “what do you expect me to do” or “what should i do” or “what do you need from me”. This always told me that the next time i go to them or send email – I MUST tell them something that spurs their action about the subject. Now that doesn’t mean they will immediately taken some action but it helps to be more directive or draw out their action or helps them to think in terms what you expect them to do or dont.
Ensure your email is always goes first before you go to them directly to talk about a subject. Email always gives the recipient opportunity to read, understand and be ready with the context before you setup meeting with them or go meet them in their office directly.
One of the essential and fundamental elements why Scrum is becoming very important is that when the team sits together to discuss and groom the stories, is because of the grooming and tasking of efforts.
When the product owner or manager brings the intent and create a high level user stories, the team does detailed study of the story in understanding the value that feature or functionality brings to the user and starts writing the tasks to be done to meet or build the end user functionality.
A Scrum Master has to enable the team to write the story and detailed tasks required. This is important because each day when the team comes to work they should not squander around OR search OR go back to drawing board as to what needs to be done. Ideally the team member open the agile tool > go to the user story > read the tasks > start working on each task by task. This way its a total heads down approach to crank thru the work required of the sprint and provide the required user functionality by the end of the sprint.
To conclude, it is extremely important that the entire team understands this way of story grooming is must and should, otherwise the daily stand up calls or any other adhoc meetings happen during the sprint will not yield any value and simply Agile wont work.
Qualities of a Good Scrum Master
Servant Leader - An empathetic listener and healer. This self-aware steward is committed to the growth of people
Coach - Can Coach the other team members on how to use Scrum in the most effective manner
Framework Champion - Is an expert on how Scrum works and how it should be applied
Problem Solver - Protects the team from organizational disruptions or internal distractions or helps remove them
Facilitator - Neutral participant who helps group of people understand their common objectives and assists them to achieve these objectives
Qualities of a Bad Scrum Master
Boss - Has the ability to hire and fire others
Task Master - Myopically focused on assigning and tracking of progress against tasks
Product Manager - Responsible for managing schedule, budget and scope of the product
Apathetic - Lacks interest in or concern about emotional, social, or spiritual well being of others
Performance Reviewer - Responsible for documenting and evaluating job performance