Sunday, June 26, 2016

Testers role in agile

What testers do in agile?


coders + testers

In a perfect agile team, there are no people called as developers and testers. Entire team contributes to development and testing. So this article is non-existent in a perfect world. But in the real world, where developer (actually coders) and testers were in existence before agile came, this article finds a valid place. Development team does not mean coders. Software development comprises of coding and testing. So till now, we were mistakenly calling the "coder" and "developers". My view is "developers" = "coders" + "testers". So when we say development team in agile, we really mean coders and tester and any other roles which are required to achieve the say do ratio.
In non-agile environment, the role of a tester includes analysis, test case design test case writing, and test case execution. He is involved right from the project initiation stage up to when the project is closed.
However, in agile environment his role primarily is to work as part of a development team, and to ensure that quality is built into a product by working closely with the product owner. This helps the tester get more details out of the story cards. It will be difficult for the development team to meet the acceptance criteria and consider a story "done" if the tester does not engage him/herself with the product owner. The role of a software tester in an Agile environment goes beyond “just testing” and logging bugs.

Monday, June 6, 2016

How I passed PMI ACP exam

Dear Friends,
I will give you some tips and hints to help you complete you PMI ACP i.e. Agile Certified Practitioner exam in the first go.

Step 1) Real life experience:

I agree with PMI's criteria that we need to have 1500 agile project experience. It gives you good knowledge about how things can go right or wrong practically. So if you do not have that real life experience, then please get it. It really helps you to solve atleast 20% of the PMI ACP exam questions.

Step 2) Classroom training:

This 3 day training was also important to know some unknown things in agile, lean and kanban.

Step 3) Books:

My main study guide was the book from Mike Griffiths: PMI-ACP Exam Prep. I read it three times.
First I read the book in fast pace. I focused on headings and diagrams. After reading each chapter, I also solved the exercise at the end of the chapter. For the first time I got only 50% answers correct.
Second time I read the book in full details. I also carefully read those sections, for which I got wrong answers in the first time exercise. Then I solved the exercise and this time I got 70% correct.
Third time I read the book with 100% attention to each and every word. (remember to read each and every word) Now, this time I got 100% correct answers when I solved the exercise (may be because I would remember the answers by then).

Step 4) Solving the online exams:

Each time I completely read the book, I also solved questions from below links. Some of those are free and some of those are paid. I recommend to solve free ones first :) Paid ones are also equally worth. Paid ones cost you from $3 to $10, which is worth than not doing it & putting $495 at stake. From free ones, I got approximately 20% similar questions in my exam. From paid ones like udemy, I got approximately 50% similar questions in my exam. edward-designer link is like a composite of all the online guidance. Remember the questions are not exactly same. Those are similar and you will get fair idea of the difficulty level and also you will get to know your gaps.
Step 5) During the exam:
First read the question carefully and understand grammar of it. If it is easy, solve it. If you are in doubt, mark it and go to the next question. After you solve all easy ones, solve the marked ones. This should leave you with 30 minutes. Now in those 30 minutes, review carefully each answer of all those 120 questions. I am sure you will change answers of at least 5 questions (because your brain keeps on thinking).
Out of 120 questions, I was able to solve 80 questions with ease. Those werevery straight forward (based on my knowledge and experience). 20 questions were little tricky, but if you think twice, then they were reasonable. Rest 20 were very difficult and I had to spend 1 hour to solve those.... and I am sure I might have scored 0 in those 20.
Suggestion: Apart from the suggested book above, also read other books on lean, kanban and XP. Also browse one website related to these topics daily. This will help you to solve those 20 tricky questions.
Best of luck!

Monday, May 23, 2016

Facebook statuses of a scrum master

Day: 23 May 2016

6:00 AM
Did yoga and meditation. This will help me to keep myself calm and composed while tackling every unexpected impediment at today's scrum.

7:00 AM
Had hot cup of ginger tea with a sandwich. Heading for office. Need to reach before my team, so that I can remove any unwanted distractions before my team reaches its desk.

8:00 AM
Called our helpdesk to check Tonny's PC, which was not starting up. Could resolve the impediment within 30 minutes.

9:00 AM
Reminded the Product Owner about adding details to the 3 stories those are on top of the backlog. Those 3 stories are the potential candidates for next sprint.

10:00 AM
Researched on a new Retrospective technique called "sinking ship". We will use it to gather action items in this sprint's retrospective.

11:00 AM
Fought with a project manager who was intruding my scrum team and who was asking the team to prepare reports for leadership meeting, which was outside of our sprint work. Won the battle successfully.

12:00 PM
Had Paneer-Tikka for lunch at "The great India cafe" on 43rd street.

1:00 PM
Held a training session for new developers in our scrum team on TDD. I hope they understood it very well.

2:00 PM
Checked Rally tool to see if everyone has updated the stories with details, hours, TODOs and new tasks. Burndown looks pathetic.

3:00 PM
Enjoyed the backlog grooming session. Stories for next sprint are almost ready. Had to cut down few discussions which were going off track.

4:00 PM
Booked meeting rooms for tomorrow's midsprint review. Booked meeting rooms for Demo and Retrospective meetings. Booking in advance helps to get the room closer to the team location.

5:00 PM
Facilitated daily stand up meeting. Got to know about an impediment in an integration story. Setup meeting with the third party application owner to analyze the problem along with a senior developer from my side.

6:00 PM
Informed in SOS that the integration story in in risk due to dependency on third party application. We should update our Definition of Ready to incorporate the dependencies.

7:00 PM
Enjoying at the Hard Rock cafe with some chickens who want to implement scrum in their teams.

This article briefly tells you the roles and responsibilities of a scrum master.

Thursday, May 19, 2016

If you do these 6 things, then you are a good Lean Enterprise.

1) Loose your weight

In a usual weight loss program, we loose our weight and then gain it once we stop the program. But in a good lean enterprise, you focus at it often. Remember, this does not mean firing the people or doing a massive re-org. These are the best treatments that last a month!

Loosing weight in Lean, implies to keep looking at ways to continuously shed away what we would collect as we grow and do new stuff. Those could be excess inventory, unused or rarely required tools, expensive services (getting more expensive day by day), unproductive events, inflated processes, never ending projects, etc.

2) Wash yourself

Cleanliness is both the abstract state of being clean and free from dirt, and the process of achieving and maintaining that state. Keeping surrounding clean, allows to identify dirt and dirt making elements, helps loose your weight sooner. Cleanliness improves productivity, drives discipline, promotes transparency, limits back side gossips. The best part of it is we get encouraged to be clear in thoughts, words and deeds.

Daily Kaizen, Kaizen events and focus on 5S(sort, set, shine, standarize and sustain) helps the teams to keep the surroundings and environment clean.

3) Learn to say Sorry and Thanks more often.

Every team member in your team is leader in himself/herself. And in such a diverse teams, the biggest impediment in front of the team is leadership style of everyone. One action is perceived by different people differently based on their beliefs, egos and attitudes. Interpersonal strife and collaborative challenges rule until open communications and reiteration of meanings serve as the key.

Humble confidence is necessary while dealing with people and leading them. Accepting the mistakes and moving on becomes the guiding factor. Learning from ones/other's mistakes builds upon the experience and showing gratitude adds the flavor of humbleness.

Encourage Gemba walks, Gembutsu, Genjitsu and Genri and Genichi styles at the workplace.

4) Stitch in time, Save nine!

Lean is all about learning and improving. Learning from failures is the key. The failure is not an event. It is the result of a chain reaction. We need to identify the root cause (and not the root person) for the event and stitch over there. This stitch on time, saves further chain reaction.

Identify that small gap in your system which made the person fail!

5) What goes around, comes around!

Every business produces waste. Lean promotes reducing the waste. The waste could be unused inventory, WIP items pending too long, approval chains, scrap and many more. The businesses are meant to produce profit, value and brand.

When we start reducing the waste, productivity increases. This results in increased profit and value. This creates stronger brand recognition. All this is done to provide satisfaction to the customer. If we produce more waste, then customer will get lesser value and the result is "dis-satisfied customer".

So if you produce more waste, then more waste will come back to you. If you produce more value, then more value will come back to you in terms of profit.

6) Meditate

Yes, you heard it right! With the hectic pace and demands of modern life, many people feel stressed and over-worked. There are many things in life that are beyond our control. However, it is possible to take responsibility for our own states of mind – and to change them for the better. Meditation practices are techniques that encourage and develop concentration, clarity, stability, satisfaction and a calm seeing of the true nature of things.

When you see the true nature of the things going on in your enterprise/project, you start recording them. Once those are recorded, those get improved. Periodic audits identify gaps those are wastes, The process improvement reduces wastes. All improvement opportunities drive towards consistency, predictability, stability, and team satisfaction.

Note: The headings given to each of the above paragraphs, are not to be meant for taken literally; take those as a pun.

Tuesday, September 22, 2015

PMI ACP exam questions preparation

The below link has some good material to prepare for the exam.

1500 questions and answers: PMI ACP Practice Exam with 1500 questions




PMI-ACP Exam Prep Free Materials

PMI ACP Certification‎

PMI-ACP Exam Preparation & Tips Online

PMI-ACP Practice Quiz

free-pmi-acp-exam-questions

Free PMI ACP Exam Questions



How I passed my PMI-ACP test

PMI-ACP mock and practice exam simulator

PMI ACP exam question PMI ACP exam questions

Free PMI-ACP Exam Practice Questions, Study Tips

PMI-ACP Full Length Practice Exam

PMI-ACP Exam Prep: 1000+ PMI-ACP Practice Questions

30 Free Questions with Answers on PMI-ACP Examination
Agile Certified Practitioner
Agile Certified Practitionar
PMI sample questions.

Thursday, September 10, 2015

How my team transitioned into Agile Scrum

Greetings everyone! Moving into agile scrum? Let me help you by sharing my experiences, so that you can get an idea of what is coming ahead!

Our team was waterfall. We were developing a software with release cycle of 1 year. Our business analysts (BA) used to get requirements. They used to draft a big requirement document and developers used to write an enormous technical specification document. At the same time testers wrote big test cases covering end to end scenarios. Initial phases of waterfall, testers used to have lesser work and then they were getting stretched towards the end of the cycle. At the same time, our customer had to wait for 1 year to get the new features.

The Day arrived, when our management said "Lets go agile!". We exclaimed "What?!?!?!?!" They said "Google it and implement it!!". Everyone of us, developers, testers, DBAs, BAs, team leads started running here and there to gather information about agile. We also appointed an agile coach who was excited enough to try different experiments on our team


Year 1

Quarter 1

Our journey started with scrum. We had total 30 team members which included developers, testers, business analysts, DBAs. We divided the team into 3 scrum teams. We decided to have sprint length as 1 month. And courageously we declared that our initial velocity would be 50 story points. We decided a date as day1 of sprint1.
It was a gloomy Monday afternoon. We knew that D day1 is next Monday. We religiously started to groom the stories and found out that there are just few stories with fewer details. We started shouting, screaming and bugging our scrum master. He followed up with the product owner and then we received some more details and some new stories. Somehow till next Monday, we were able to groom sufficient stories for sprint 1.
After a month, we had a successful sprint 1.
We all were very much excited and committed for sprint 2. Here the "descent" started. Sprint 2 was major failure with 50% say-do ratio. Everyone started to finger point on others. Our agile coach had to had lot of conversations with the individuals to re-iterate scrum values. Sprint 3, 4 and 5, were all same.... all failed.


Quarter 2

After sprint 5 failed, we concluded that scrum is not working for us. We had lot of dependency on other teams. Customers were not ready spend time with us for grooming stories. Team members were bored of daily stand ups.
We consulted our Agile Coach and then we started with Kanban. We decided our WIP count. Again it started failing. We tried to put scrum rituals in Kanban mode and it was a total mess.


Quarter 3

Now, our Agile Coach, was in action. We had a detailed 2 day long retrospective of last 2 quarters. We identified what was working well and what was not. We had invited senior leadership in the same to get buy-in for our suggestions.
After this, we decided to follow scrum. We decided sprint length as 2 weeks. We got agreement from our customers to spend daily 1 hour with the development team. We spread awareness about scrum value "Transparency" into the team members. We arranged Scrum Master training for our scrum masters which helped them to learn to say "No" with courage and valid reasons.
This seemed to be working well. We had several sprints being successful one after the other.
But this was not THE END.


Quarter 4

As the sprint started to be successful with 100% say-do ratio, product owners and management wanted more velocity.
We started hearing -
"Last time you delivered 30 story points. This time we want it to be 35"
"That team is delivering 40 story points. Why your team is just at 25?"


We started to do Capacity Planning in terms of hours to show to the management that velocity can not be increased to a certain extent. We are humans and let us be humans.
We also coached the management that comparing velocities of two teams is not appropriate because velocity is not a measure of productivity.
We also had to coach the team to prepare necessary and sufficient documentation. For last 3 quarters, there was zero documentation because we were in mis-belief that agile says "no documentation".
Now the team started to create high level technical details and some functional documents which would help us to preserve the knowledge in case of attrition.


NOW

Now, our teams are quite stable in scrum. We have dedicated roles of scrum master, product owner. We also have global teams spanning the continents. We do some overlap with other teams seating in other time zones to ensure proper handover. But this is not THE END. We want to implement scaled agile now!