Positive attitude - poem by openai

OpenAI generated poem about Positive Attitude

With a positive attitude in my heart,

I face each day with a smile,

For I know that with a hopeful mind,

I can go the extra mile.

Like the sun that rises in the east,

My spirit shall never fade,

For with a positive attitude,

I shall overcome every shade.

Like a bird that soars on high,

My thoughts shall always be free,

For with a positive attitude,

I shall always be me.

Like the river that flows to the sea,

My journey shall never cease,

For with a positive attitude,

I shall find my inner peace.

Like the flowers that bloom in spring,

My soul shall always thrive,

For with a positive attitude,

I shall always be alive.

So let us all embrace the light,

And let our hearts be filled with cheer,

For with a positive attitude,

We shall conquer every fear

MY FIRST YEAR AT WORK

I have seen many employees in their first year of work after college over 20+ years, few things I would like to suggest to new employees to consciously follow the follow etiquette for better working experience to both you and your team.

• Ask for work proactively. Follow up for work proactively. 
• Remember that you are getting paid for 9 hrs a day and that you work for those 9 hrs
• Ensure your blockers are raised immediately and are followed up regularly
• Update your status end of the day (EOD) to your supervisor or on status pages
• Don't sit on something you are not able to crack beyond 2-3 hrs. Ask for help from buddy/mentor/seniors and take guidance
• Stretch the initial 2 years and learn as much as possible. This ensures you are targeting a fast track career path.
• If your English speaking/writing skills are not fluent, invest your time and energy is improving that
• You gain confidence. You can communicate better. Your chances of success are also higher
• English Writing Skills
• Write a couple of papers(any topic, but preferably science/engineering topic) and get them reviewed with one of friends/seniors
• Ensure grammar and punctuations are proper
• Paragraphs are well written
• The spacing of lines is proper
• Bullets/Numbering is proper
• Indentation is as per editor and not spaces
• Learn to write crisp and concise manner and not speaking English
• Learn to articulate your question
• Learn to answer to the point
• Learn to write your resume crisp and to point and add links to your files of your masterpieces that showcase your skills
• English Speaking Skills
• Learn from apps like Duolingo, or any other sites/coaching centers to speak without grammatical mistakes
• Join Toastmaster in your company/locally
• Listen to news channels like BBC/CNN or other news channels of the countries from where your client will be from
• Practice speaking fluently. Practise Practise Practise. 
• Your language till college is non English and I cannot speak like others is an excuse, pull up your socks and invest so that you can speak fluently and grammatically correct. There are countless people who put in effort to learn and mix well with crowd.
• If you are a developer
• Learn the language writing small snippet of code. Store your exercises in git. If any accelerators are written then have a readme file
• Have a habit to writing a design approach/pseudo code/flow charts
• Write unit test cases before starting coding
• Attach unit test results to the ticket
• Walkthrough the feature to testers 
• Code should be well documented
• Should have Junits
• Run your code through Sonarqube kind of tools as your inherent deliverable
• Run the QA test cases in dev itself to avoid round trips. Bug fixing early on saves time and money
• Do certifications
• Do cloud certifications
• 
  

Stakeholders who are not plugged into delivery and escalate as their birthright

In some accounts, we come across few stakeholders who just ask the question they want to ask to showcase to their managers that they are working and tracking. 

These people don't check emails. These people don't remember the facts. They have most likely never tracked enterprise-level delivery properly in their careers. They will most likely never represent you in a positive light in their internal meetings and will try to tell negative facts only.

How can I overcome and still deliver?

* You need to continue doing what you are doing as if you are both the client and the vendor and take e2e ownership and responsibility. 

* Ensure these stakeholders are marked in the emails. 

* Send meeting invites on demo's. 

Ensure the above are done, so that when it never comes back to you and that you have data points and are covered

Why do these stakeholders act like that?

Some stakeholders watch carefully what is going on and ask relevant questions and help the team to deliver their best. They track the project better than you and there is a give and take relationship and trust here.

But some stakeholders just come once a blue moon and just ask what is in their mind, not being in sync with what is going on the ground. They conveniently forget the facts, emails, demo's, decisions made, issues teams faced for the delays and try to do WhatsApp management or email management looping in their managers that they are working, they are tracking, and they are strict on the vendors.

Any way out?

No, these guys will continue to exist. Forcefully ingest them with the status where possible and schedule weekly/monthly calls. And use stakeholder management principles to the best of your abilities ad

Metrics for Agile

As a Manager or Senior Manager, we track Agile projects. Most common metrics we should be tracking while overseeing a project are:-

Agile:-


Basic metrics we track in an Agile project are


* Sprint Burndown chart
Scrum teams pull out a certain scope from top of the Product Backlog into a time-boxed sprint. This report tracks the completion of work through the sprint and tells whether we are on track to meet the sprint goals.  X-axis represents time and y-axis refers to the amount of work left to complete, measured in story points or hours. Meeting the Sprint goal is completing all the forecasted work for the Sprint


Things to watch out for:-
*** Burndown line is not a gradual burndown but steep drops --> Scope is not being divided into manageable chunks i.e. < 4-6 hrs
*** Scope is getting added or changed mid way through a sprint
*** Meeting Sprint goals early each sprint --> Scrum team is not committing to enough scope
*** Missing Sprint goals every sprint --> Scrum team is committing to more scope than can deliver


* Epic Burndown / Release Burndown (planned vs. actual in terms of story points)
Important we track this metric, to keep a tab on overall scope. This indicates whether we are adding new requirements mid way and is a good metric to check the status of the release

* Velocity
Velocity is the average amount of work a scrum team completes during a sprint, measured in either story points or hours, and is very useful for forecasting.

* Defects
Though not a common Agile metric, as part of our waterfall gene we carry, we tend to watch the following metrics also as a good practice as this related to the quality of the deliverables


*** How many defects are found during development?
*** How many defects are found after release to customers?
*** How many defects are found by people outside of the team?
*** How many defects are deferred to a future release?
*** How many customer support requests are coming in on our delivered code?
*** What is the percentage of automated test coverage?

Governance using Agile Metrics
The above agile metrics surely gives a quantitative insight into the team's performance and provide measurable goals for the team

In practice, Sprint Burndown should be looked at during daily stand up calls along with the Scrum team.

Sprint Burndown, Epic Burndown and Defects related metrics should be explained out as appropriate to team during the retrospective meetings, while we answer the 3W's  - what went well, what didn't go well, what can we do better.

Output of retrospective meetings, should include actions items on continuous improvement feedback to ourselves as a scrum team and also with onsite/customer especially as this is the data point to be shown when scope creeps continue to happen during the sprint, which aids to not meeting the Sprint goals and having to re-plan every time and will be chaos in tracking the sprint goals

While the agile metrics are important, don't get obsessed. Listening to the team's feedback during retrospectives is equally important in growing trust across the team, working as a team, quality in the product, and development speed through the release process. Use both the quantitative and qualitative feedback in tracking the projects.

Most common agile tools are JIRA, Team Foundation Server, Grasshopper

Basic documents we use in Agile are Product Backlog, Release Backlog, Sprint Backlog, User Story Acceptance Criteria, Technical Design Approach, Retrospective notes,

Lesson: Stakeholder Support/Requirements Mgmt/Design

Let's see how stakeholder support on all process areas is crucial for project success!

A Stakeholder who doesn’t push his people to gather the requirements elaborately is also allowing ownership and accountability to be slacking.

First stepping stone of success is failing.

Incomplete requirements capture leads to everything partially done and will fail during UAT testing, where you will have the team doing requirements and mockups when they have to certify and release to production.

Precious time, effort, money is lost due to a simple mistake like not capturing requirements fully and not paying attention to design

Developers who develop will be discovering questions as they develop, and as a result, design and coding need to change.

Project Deadline is never met, as we are failing in multiple disciplines of Project Delivery Requirements Management, Design including Project Management 

Stakeholder Management

Stakeholder Management as part of PMP has a lot of importance in real time and impacts revenue recognition, pipeline, cost, time. We gain this insight and effects mostly through experience and as part of guidance by our mentors and leaders in projects.

Standard Stages in Stakeholder Management are Identify Stakeholders, Plan Stakeholder Management, Manage Stakeholder Management, Control Stakeholder Management

Each of the below points should be studied as a case study with real examples, imbibe it strongly and ensure we plan properly:-

Please feel free to comment on additional things so others can learn from your experience

1) Stakeholder Change: 
It takes time to establish a trusted relationship and is often based on quality deliverables, good governance, good channels of communication, our delivery track record etc...

When this key customer stakeholder moves out of the equation, we need to start it all over with the new stakeholder.

This person's working style; priorities; needs; previous vendor preferences; their comfort with them;  getting things done; being there for consultation; walking their corridors, needs to be considered.

You need show the similar or higher technical and management prowess, attention and availability, good intentions to make them succeed. It involves writing a stakeholder plan and each party play their role.

2) Stakeholder Support across all stages of the project
Stakeholder support and prioritization towards your strategic initiative/project is a very important success factor.

If resources are being diverted over to other business as usual and urgent activities, it means they are steering the time and effort away from your current project and might not be giving required importance to make this project succeed. Any of the success factors failing will have an impact on the project.

Stakeholder support is required to clear obstacles fast, make decisions fast,  is equally important. If proper Stakeholder support is not being given, ensure you brace up with proper communication. Dipping into your sphere of influence to get required support can be done proactively to minimize the impact.

3) Regular Monthly Stakeholder Meeting for communication of expectations vs. reality from beginning to end. In case of crisis, weekly stakeholder meeting, to ensure it is going as per expectations and plan set

4) Expectations of internal stakeholders, leading to activities over and above other important activities required to achieve the project goal

5) Stakeholder current situation and priorities affecting the continuity

6) Communication on critical emails regarding milestones, risks, issues, delays, payments to stakeholders should be carefully drafted to preserve the interests of the company and SOW, which might be beneficial for future legal arbitration purposes.

Yesterday we had a meeting, tomorrow it will be delivered

When the teams don't track their action items from meetings and don't capture Minutes of Meetings, they will always fall into this category where they will try to remember what is open and that they will be asked in tomorrow's meeting. Scramble and try to have a quick meeting, make slight progress and get an update to present in the meeting.

They will then say, we had a meeting yesterday and here is the progress.

Ideally, everyone needs to pick up the action items immediately, so there are enough follow up sessions possible and the action item can be brought to closure as required and well before the next meeting.

Else we fall into the section wherein the meeting we will update saying, we had a meeting yesterday, and here is the update, we will get it fixed tomorrow