The below link has some good material to prepare for the exam.
1500 questions and answers: PMI ACP Practice Exam with 1500 questions
1500 questions and answers: PMI ACP Practice Exam with 1500 questions
Tuesday, September 22, 2015
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
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.
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.
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.
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.
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!Wednesday, August 5, 2015
Agile: To be or not to be
Greetings everyone. This article is about a fantastic dilemma for any leadership about if we shall decide for the organization to follow agile or not.
Now-a-days Agile is the buzz word. If you are a leader in your organization, and meet some one at any business conference or seminars you would probably be asked the question "So, do you follow agile?". And then if you already are agile, then you are lucky. But if you are not yet agile, then you fall in the dilemma "To be agile, or not to be?" And the person who asked you in the first place, is also not sure about why s/he went on agile?
Now, first of all, it would be a bad idea to arrive at your cabin one fine day and announce that from today we all will be agile. You need to do some pre-work and feasibility study to make some informative decision about agile adoption.
1) Type of your product/customer
This is the era of competitions. Faster and Consistent wins the race. You need to ask yourself "Does my customer want faster delivery?", "Is s/he ready to spend time daily with my development team?", "Do we need to release frequent updates to our product?", "Are we clear about the vision of the product?", "Is the market ready for frequent updates to the product?", "At what speed my competitors are coming up with new product ideas?"
Agile will be valuable when -
- customer has enough time to spend with your development team.- market is ready to accept frequent updates to the product.
- there are many competitors coming up with new ideas every now and then.
- there are changing requirements based on market direction.
2) Early to market
By following different agile methodologies, we can bring our product early to market. This helps to make the consumers use the product with its bare minimum features. If our product development can be done early in chunks of features, then agile is best suitable for it. For e.g. new mobile device - can be launched early in the market with bare minimum features of calling and texting. Later we can add camera, Bluetooth and hundreds of other features in chunk.3) Early ROI
Once we bring the product early in the market, we start getting return on it early. If we are looking for early ROI, then we surely can go for agile.4) Continuous feedback
As the product is being used by end customer, and we invlove our customer in the product development, we start getting regular feedback on the product deliveries. This helps us improve the product as well as the process. This way we can also come to know changing priorities in the market.5) Type of work
If the type of work required to build the product is repetitive, then agile might not be a good choice. Agile is best suitable for creative product developments. e.g. if your team works on software installations, then it might not require agile. If your team works on developing a internet banking website, then it will get benefited from agile.
6) Adaptability
Every change follows reluctance to change. If your organization is flexible and adaptable to changes, then agile implementation will be smooth. Agile demands complete shift in the mindset of each and everyone involved in it. Everyone from the top management to the actual development team should be open for this change. Training helps but the continuous coaching is required to transform the team into a successful agile team.
7) View of IT department
Do you look at your IT department as a cost center? If yes, then it will be hard to change the mindset of people. IT department, in agile, should be looked at as a valued partner. This will help in improved customer involvement and improved team collaboration, which are the basics of agile manifesto.
Subscribe to:
Posts (Atom)