Starting the Agile Journey

Project Management Agile Training

Agile Training

Recently I have had the opportunity to present to students taking Project Management certificates and diploma courses with one of the University programs in Dublin. I was asked to do 1 day on agile out of the 10 or 12 day programme. These are all experienced employees spending considerable time and money on this course.

Each student has a copy of the thick brown PMP (Project Management Professional) manual which I now see has changed from white pages to grey – how apt. At the beginning of the class I get the opportunity to ask them if they have enjoyed reading it. Was it interesting etc?

It generally doesn’t take long for someone to say that it impossible to read or do project manager actually use this stuff etc. This kicks-off my class nicely and I get them to agree that’s it’s “a pile of …”.

Ok I have to roll-back a little as they have spent thousands on this and I better not blow the other 90% of the course out the window yet. And I’m just making the point about the complexity of the approach suggested in the PMP.

After a short discussion on their agile knowledge I head towards the agile manifesto and more importantly the Twelve Principles of Agile Software Development. Two areas cause particular concern.

  • Welcoming change even late in the day
  • Business people and users working together on a daily basis.

They were all concerned about changes going on forever and welcoming more changes then becoming a never ending story. We had a good debate and on this topic I was able get them to agree that a dynamic business would welcome changes and a more conservative business might be better to resist them.  I didn’t need to ask the question “which type of business would you rather work for ?”

I had to take the idea of Business people distracting developers every day on the chin. I couldn’t win this one but again we did agreed that it was vital to have close co-operation especially in a dynamic environment.

Scrum Master Training Dublin Staceys matrix also causes a bit of stir. Interestingly one person was familiar with the “the challenge of complexity” and was keen to point out that Stacey has disowned his own matrix as too many people miss-use it. Ouch – I figured that I could still hold my own on this but best to press on. In particular it was felt that good business analysis can be used get agreement on the requirements reducing some of the complicated work. Additionally good risk management might tackle some of the technology uncertainty.

 

I didn’t come out of this unscathed but the class got the point. Time for a little light hearted games at this stage.  I used a “document the drawing” vs “describe the drawing” game and this went down really well. We got near total agreement that old-fashioned BRD’s (Business requirements documents) are painful to write and often miss the mark.

 

Onto a winner now with personas and user stories. By now I’ve started to win them over and it was time to introduce Kanban. Super session and all agreed to implement a personal Kanban board for their exam practice. At this stage I figure I can do no wrong, we agree to break.

The afternoon we looked at Scrum and in particular the Scrum Principles. We hit on the role of the scrum master and servant leadership. We used games to outline “work in progress”, commitment and waste.  The group started to explore how agile would fit into their working environment.

A number of questions arose like

  • But what happens when we don’t have full time teams
  • Most of our project are about integration of suppliers and customers?
  • What about change management
  • How does agile fit with long term planning

By days end we saw some super agile concepts and there was no disagreement that we should really concentrate on getting things done as opposed to over planning everything. Agile is very important for team productivity but scaling was still going to create a management overhead.  Some felt that Agile wasn’t actually project management at all but that it was team management.

PMP may still have a long life but let’s stretch ourselves and be more agile.

Business Analyst is not the same as a Product Owner

The Product Owner is not the same person as Business Analyst.

The key is in the name, its all about ownership. A Business Analyst collects and analyses requirements which is a major part of a product owner role but there is a lot more to it than analysis.

The product owner roles is to Create Business value, so its not just collecting requirement but it to prioritise them.  The product owner then works with the development team to get the highest priority part of the product produced first.

  • Monitor progress toward a goal (*)

The Product Owner is accountable for the success of the project, that’s a significantly more than most business analyst would say.  Their role is also to create the product vision and create a road map for delivery. It much more akin to a project Manager or I’d even say a project sponsor.

The Product Owner manages the long list of deliverable (called the product backlog). Therefore the roles is more akin to a scope management role.

  • Scope may be clarified and re-negotiated between the Product Owner and Development Team (*)

 

The Product Owner also defines a definition of done so there is a quality aspect to the role as well. It’s of little value to the customer if the deliverable is not fit for purpose. They are not the only person doing a quality role the development team has a roles to play.

  • This Increment is useable, so a Product Owner may choose to immediately release it.(*)

The Product owner is responsible for communication. Particularly to stakeholder and to enable the appropriate level of communication between stakeholders and the development team.

  • Ensure that the product backlog is visible, transparent and clear to all (*)

If the product Owners Role is to create Business Value then they must also ensure that the development has the appropriate resources to get the value. This element of the roles may be shared with someone like the Scrum Master who is trying to remove impediments. But to me it suggests the Product Owner is responsible for cost management.

The Product will document requirements, probably in the form of user stories but the role is not just Business analysis.  The role also takes over some of the Project manager’s role and also some of the Sponsor’s role.

(*) Taken for the scrum guide

Althris provide Scrum Master Training Dublin

Planning and Execution of Test Cases During Agile Development Iterations

Scrum Testing Product Owner

Introduction

During the software development process it is vital to establish a robust process of software quality assurance, even if you are developing using an Agile development methodology.

It is important to mention that Agile development should not be confused with development without a defined quality management software. It is strongly recommended that the tasks of creating test cases and performing automated tests be planned for each development iteration.

In addition, having a test-focused person is a key to the quality of software development during the Agile iterations.

Agile Planning and Quality Assurance Tasks

The Agile iteration planning process allocates at least one resource for testing activities, and does not involve this resource in development activities within the iteration. This process is important to avoid poor quality testing.

Within a development team of five people, having at least one person focused on these tests tasks will greatly help to ensure the quality of the software. In this case we are talking about functional tests (black-box testing) planned and written through test cases. However, we must not forget that the unit tests (white-box testing) are the responsibility of the development team, and the tasks of developing these unit tests must be estimated together with the backlog items.

The advantage of include planning and execution quality assurance tasks even in an Agile software development cycle is the concern of the development team in delivering quality software to those responsible for running the tests. It is amazing how the simple fact there is a person planning and thinking about software testing already increases the quality of the software.

Here are some tests tasks that can be executed during a development iteration:

  • Creating a test-planning;
  • Creating the detailed test cases for each user story or backlog item;
  • Preparing test environments required for system tests;
  • Preparing test data: getting real data from production or simulation.

In addition the tests can be automated, so the tasks below can be included:

  • Automating unit tests;
  • Automating functional tests;
  • Writing mocks, test drivers, data simulators, test frameworks.

Scrum Master Dublin

Tools for planning and running tests

It is not the purpose of this article to present test tools. However, it is important for the agility of the software development process to look for tools to automate the execution of the tests as well as documenting the test plans and the test cases.

Remember that tests can be re-used in future development iterations, so it is very important to define a centralised method and tool to manage the test plans and test cases. An efficient test management tool will help you with the agility and quality of your software.

The following are some suggestions for test tools:

  • qTest
  • PractiTest
  • Test Collab
  • TestFLO for Jira
  • XQual
  • TestCaseLab
  • Microsoft Test Manager (Test planning and automation)
  • Microsoft Team Services (Test cases)
  • Selenium (Automation of functional tests for Web applications)
  • TestRail

Agile Estimation: Approaches

Planning Poker

Agile Estimation: Approaches

The software development process, with its constant uncertainties and frequent changes, together with the difficulty in getting users to articulate their requirements, has long been a headache for project managers.

Agile development processes still bring with them some of these headaches, but we can simplify the estimation process. I have listed some of the approaches below.

Poker Planning Games

Planning Poker

Planning Poker

Planning Poker is a technique used to estimate the relative size of tasks, or the effort required to complete them, in software development. A development team estimates using a deck of cards that are usually a Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34, … ) to indicate the difficult of the task. You can easily replicate this by asking the team to make their own cards. When starting off in Agile, sometimes teams equate this to the number of hours required to perform the estimated task – though this is probably not the best way to do it.

The estimates occur as follows:

An item is selected for discussion.

  • Each team member chooses a card that most reflects the “size” of the selected story (or task). This decision is based on the knowledge and experience of each member of the team.
  • All members show their cards at the same time so that there are no changes of mind after each member has seen the other hands.
  • In most cases we will have cards with different values. The divergences, and the reason for the differences in the estimates, is discussed. Large divergence suggests a lack of information, in which case more negotiation/discussion must occur in order to get agreement on the estimation.
  • The story estimation ends when the cards’ values converge to a value agreed by shared consensus of the team.

Agile Estimation using the Fibonacci sequence

Consider the sequence of numbers 1, 2, 3, 5, 8, 13, 21, ….

Each number is the sum of the two previous numbers. In some cases, the numbers are rounded up or down to the nearest 5 or 10. Often a 0 and a 1/2 are also added. 0 (zero) represents a story that requires no appreciable effort to develop; for example, if another story already being completed will be used to end this story.

Generally, the question mark is used to indicate that a team member does not have enough knowledge of the story to estimate it, and thus requires more discussion and greater detail about the story.

The symbol of infinity is used to indicate that a story is too large to estimate, more like an epic, and so needs to be broken down into smaller stories.

The idea here is that the team should really develop their own technique for building out estimates. Time may not be the best measure, as the team should be trying to get more efficient in each subsequent sprint. The non-linear nature of the Fibonacci sequence makes it harder to sit on the fence with in-between estimates.

Estimate user stories using T-shirt sizes

T shirt sizing

Sizing

There are several other ways of estimating stories, another of which is T-shirt sizing. In this type of estimation, stories can be small, medium, large, or XL. What exactly these sizes mean depends on the team. In addition to the terminology being familiar and easy to use, even by non-technical people, this works really well on teams with very short iterations.

 

 

 

 

Conclusion

Estimating software delivery times really is an art. The accuracy of the estimate depends greatly on each team, as well as the level of detail available for the estimate. The most important thing is for each team to evolve, always seeking to increase the accuracy behind the estimates.

In addition, estimates combined with good retrospectives can help identify parts of a system that need refactoring. For example, if stories fall behind, or are often labelled as difficult, you can investigate what these stories have in common, and seek solutions that can mitigate those problems.

Of course there are many agilest that advocate no estimates at all

, ,
PMP Exam Day
prometric test centre

Preparing for and Passing the PMP Exam

Having got the approval email from the PMI and before you schedule the exam, let us just revisit the exam content outline:

  • The PMP exam consists of 200 objective-type questions with 4 answer options.
  • The five domains consist of questions in the following ratio:
Initiation 13%
Planning 24%
Executing 31%
Monitoring & Controlling 25%
Closing 7%

 

  • 25 out of 200 questions are not counted towards the score, as they may be for pre-release testing. As such you don’t know which 25 questions are not graded, and so you should just treat it as 200-question exam.
  • The maximum time to answer all questions is 4 hours.
  • The PMI does not disclose your pass score; in most cases the pass score is thought to be around 61%

So you have built up your confidence over time; have already taken the 35-hour course; have gone through the PMBOK Guide; and have a fair knowledge of project management practice. Now you need to test that confidence by answering questions and checking the answers. Once chapter-level answering is finished, you need to go for a mock test of 200 questions; a minimum of two full 200-question mock-up exams passed at above 80% is suggested. This is an indication that you are adequately prepared to venture into the actual exam.

How to Handle Each Question

One of the advantages we have in answering objective-type questions is that the right answer is in front of us – we just need to select it. Carefully read the question-and-answer choices. Attach importance to words such as always or never, except for, or have to, best, worst, most, least, first, last, etc.,  and then determine which answer the question is looking for. Look at the following example question.

Conditions that are not under the control of the project team that influence, direct, or constrain a project are called:

  1. Enterprise environmental factors
  2. Work performance reports
  3. Organisational process assets
  4. Context diagrams

The term conditions NOT under the control needs to be carefully read. Answer A is correct. (Note that the question calls for a plural answer, and all answers are plural.)

Here is another example where we need to read carefully:

A logical relationship in which a successor activity cannot start until a predecessor activity has finished is known as:

  1. Start-to-start (SS)
  2. Start-to-finish (SF)
  3. Finish-to-start (FS)
  4. Finish-to-finish (FF)

Answer C is correct. A clear scrutiny of the question and the answer choices is required. You need to eliminate the answers that do not fit with the question.

Another example:

External organisations that have a special relationship with the enterprise and provide specialised expertise are called:

  1. Customers
  2. Business partners
  3. Sellers
  4. Functional managers

Based on experience, we can quickly eliminate A, C and then D, to correctly answer B.

A practical tip is to not spend more than a minute with a single question. You can come back to the question later. Sometimes, the other questions may throw some light on this question for you. Try to recollect the study that you did within that knowledge area and process group, and work out where the question belongs. For some questions you may have to recollect your project management experience. Here is a question where we need to recollect process ITTO – Input, Tools and Techniques, and Output:

An output of the Direct and Manage Project Work process is:

  1. Deliverables
  2. Activity list
  3. A work breakdown structure
  4. A scope statement

The answer is A

It is recommended that you try to remember ITTO to select the answer to these types of questions. I suggest that you get familiar with these by reviewing them regularly so you as much get a ‘feel’ more than just learning them off by heart.

After you enter the testing centre for the exam, you will be given a pencil and paper and 15 minutes’ preparation time. This can be used to prepare a chart of process groups, knowledge areas and certain tables or formulas you can recollect. This may be handy for answering the exam questions. Try to utilise all of the 4 hours’ exam time to check your answers before you submit. Best of Luck!

/Althris

, , ,

PMP ready – Exam requirements

PMP Certification – To Be or Not to Be?

Project Management Professional (PMP) is the most important industry-recognised certification. It is one of the flagship certifications offered by the Project Management Institute (PMI), the leading not-for-profit professional membership association. PMP is recognised globally as a gold standard in project management. The PMP certification can provide a significant advantage when it comes to salary and earning potential. Well over 700,000 certified PMPs around the globe stand as testimony to its benefits!

Gaining and maintaining PMP certification goes with its own process, starting with the first goal of passing the PMP exam. There are certain prerequisites as to eligibility for taking the exam. The PMP Handbook by the PMI outlines the eligibility criteria. The first step is to see whether you meet the following prerequisites:

  • A secondary-level degree (high-school diploma, associate’s degree, or the global equivalent);
  • 7,500 hours spent leading and directing projects;
  • 35 hours of project management education.

or

  • A 4-year degree;
  • 4,500 hours spent leading and directing projects;
  • 35 hours of project management education.

Explanation of educational qualifications

  • A high-school diploma or associate’s degree or global equivalent means education partaken for 3 years or less after school leaving.
  • A 4-year degree means any graduate degree such as Engineering or Technology, of 4 years’ or more duration, which is partaken after 10+2 school years.
  • You will need to show 36 hours of PMP related Project Management Training from a training organisation such as Althris Training Dublin

Explanation of experience requirements

  • For diploma holders, the project management experience required is 7,500 hours. This is roughly 60 months or 5 years’ experience.
  • For degree holders, the project experience required is 4,500 hours. This is roughly 36 months or 3 years’ experience.
PMP training Dublin

You get a real certificate with embossed stamp

Explanation of “Leading and Directing Projects”

This means that you should briefly state any job/experience that you have done in the field of planning, execution and control. It is not necessary that you should have experience in all of the project processes.

Explanation of Non-Overlapping Experience

  • Let us assume that you have managed two projects in the year 2016. Project A ran from January 2016 to May 2016 (5 months). Project B ran from March 2016 to February 2017 (12 months). This should not be taken as 17 months’ experience as there is an overlap of 3 months. Experience will be taken as 14 months only.
  • Experience reported should have been accrued within the last 8 consecutive years prior to your application submission. If you are applying in 2017, you can report experience between 2009 and 2016.

The PMP exam has a price of US$405 for PMI members, and $555 for non-members. PMI membership is not mandatory for you to take the exam. However, it makes sense to become a PMI member, at a fee of $139, as you get an exam fee reduction of $150! Additional benefits can also be enjoyed with PMI membership. 35 hours of project management education needs to be undertaken through a Registered Educational Partner (REP) that imparts the training and grants the necessary certificate towards fulfilment. Its cost can be ascertained from the education partner.

The next part of this article is “PMP – Applying for and Scheduling the Exam”

/ Althris

, ,

PMBOK 6 Tailoring

PM Tailoring

The Project Management Body of Knowledge (PMBOK) presents the guidelines for best practices that can be applied to projects. It also presents a standardised terminology. PMBOK guideline preparation itself follows ANSI standards, so it is natural that it goes for a standardised terminology! Generally a single word (or phrase) is used to define or describe a process (or element) of project management. Those who have worked on projects can readily appreciate the benefits of standardised terminology in the project management profession. In the real world, we have seen the confusion created by using different words for the same thing.

PM Process Mapping

One of the important phrases that have started appearing from PMBOK Guide Third Edition is tailoring. The usage of this term in the later editions is growing, and there is an even greater emphasis on tailoring in the 6th edition, which emphasises the importance given to tailoring. Project management methodologies/processes are constantly increasing; and real-life projects are becoming ever more diverse and complex! The saying One size does not fit all goes well here. It makes sense now to throw some light on tailoring.

Tailoring is making project methodology fit. There may be different situations warranting different methodologies and the adaptation of different processes. Industry type, environment, organisational experience, kind of project, etc., may lead to different processes being chosen for different projects. Each project is unique with its own set of goals, resources and constraints. Tailoring is the act of adapting different processes to make them suitable for different projects. The standards, guidelines and rules presented in PMBOK may be general and globally applicable. There is a need to design and tailor the processes so that desired goal is achieved in each project.

The project manager along with his/her team is responsible for the process of tailoring. To quote PMBOK,

for any given project, the project manager, in collaboration with the project team, is always responsible for determining which processes are appropriate, and the appropriate degree of rigor for each process. Project managers and their teams should carefully address each process and its constituent inputs and outputs.

When the project manager and his/her team do this they obviously buy into this.

There can be several stages in tailoring. In the initial stage, the PM methodology may be based on the PMBOK Guide. In the second stage it is more geared towards the elements of the project and based on Organisational Project Management Office (PMO) guidance. The third stage of the tailoring can be at the project execution level, depending on how well suited the processes are for achieving the desired outcome. As we can see, tailoring is done throughout the entire life cycle of the project. Another important aspect to remember is the documentation. There is a need to document the tailoring process approach in the project management plan, and then at the execution stage, in terms of how each process was tailored, and why it was added, removed, or revised.

Four key takeaways from this blog post are:

  1. Tailoring is making project methodology fit.
  2. The PM and team are responsible for the tailoring process.
  3. Tailoring is done in three stages.
  4. Tailoring needs to be documented.

Join the conversation and follow us to get an update on PMP exam preparation or take an open PMP test.

Agile Development: How to Write Effective User Stories

A user story is a short and simple description of the customer’s need. It is usually told from the perspective of those who are requesting the new feature or requirement. A user story is short and sweet, but prompts the developer to get a handle on what is required. It makes it easier for the developer to produce an on-target feature of superior quality, and allows them to understand the goals and needs of the customer more quickly. It is normal to write a user story on Post-its or index cards.

Usually, user stories have a specific format, such as the following:

“As a [persona],
I want to [do something],
so that I can [realise a reward].”

Product Owner Requirements

 

This is a sample from my training course where we ask students to use Lego to build features.

The user story prompts the user to ask questions, and suggests, for instance, specifying not just any cow, but a cow that can be milked.

 

 

Using lego to plan creation of stories

Use the acronym INVEST to get to the best user stories.

So a user story should be all of the following:

  • Independent (I): A user story should not depend on another one. Dependent user stories are difficult to estimate and prioritise, and removing a dependent user story often causes problems in others.
  • Negotiable (N): A user story is not just a text detailing the features that the product owner expects, or a piece of functionality that will be implemented. Look on a user story as a starting point for a conversation, or an opening problem for the team to suggest solutions to.
  • Valuable (V): We cannot just create fun user stories. We must describe the value that the customer will get from this user story.
  • Estimable (E): There must be enough information to allow the team to make an estimate about the user story, otherwise it cannot be started.
  • Small (S): A user story cannot take more than one sprint to complete. Any user story larger than this will be impossible to plan or estimate safely. If it’s too big, create an epic and split it into smaller user stories.
  • Testable (T): If you cannot test a user story, you cannot know whether it’s worked. If a specific user story cannot be tested for lack of information, do not put it in your backlog.

Use themes and epics when necessary.

If you use the INVEST concept to create user stories, and can keep to it, you’ll have good quality stories. In some situations you will see the need to separate them into themes or epics.

  • Themes: A theme is a group of user stories that share attributes in common. Often, multiple user stories will have similar goals, or be related in an obvious way. All of them are directed together to a single path; however, they do not need to encapsulate a specific feature or necessarily be delivered together. So a theme may contain several epics or several user stories.
  • Epics: An epic is a great user story that cannot be completed in a single sprint, resembling a theme being built with multiple stories. Although the stories that make up an epic are completed independently, their value to the business may not be delivered until the entire epic is complete. This means that it does not make sense to deliver an epic until all the stories tied to it are complete.

Althris provide Scrum Master Training in Dublin and Cork, check out our PSM sample exam papers.

Agile Development: Making Sprint Retrospective Meetings More Productive

Sprint Retrospective is the opportunity for the entire Agile Team (Product Owner, Scrum Master and Development Team) to inspect and create an action plan for improvements to the next sprint. The meeting helps the entire team to identify what worked well, and what should be improved.

I have some tips for making sure the meetings go swimmingly:

  1. The Scrum Master must be well prepared as a facilitator for the meeting.

There are thousands of retrospective techniques published in books and blogs, which when applied well achieve wonderful results. The main question is how and when to apply one particular technique or flow rather than another. However, an important issue is not only knowing the technique but knowing how to facilitate a retrospective.

Expertise in conducting good retrospectives is only gained after a period of experience. There is no single way for the Scrum Master to conduct good retrospective meetings.

The points below will help the Scrum Master to be prepared for the meeting:

  • Be prepared: Collecting relevant facts prior to the sprint cuts out the discussion as to whether, say, we have 20 or 25 stories completed.
  • Let all participants express their points of view.
  • The more the Scrum Master knows the team and the people, the more efficiently he or she can conduct the meeting. Get to know you team mates, and help them express themselves.
  1. Choose a good time for the meeting.

The scheduled day and time of a Sprint Retrospective is very important, because depending on the team and the daily work scenario, people may be tired, or focused on other important aspects such as deployment or bug fixes. You have to make sure everyone is available. First thing on the day after the sprint finishes sound good, but team members may also need time to gather their thoughts.

  1. The product owner needs to be present.

It is critical that the product owner is present to make a meeting effective and more productive. This is even written in the Scrum Guide. The first sentence of the Scrum Guide on Sprint Retrospective is as follows: “The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create an improvement plan to be implemented in the next Sprint.”

Since the Scrum Team is composed of the three Scrum roles, including the product owner him/herself. The presence of the product owner is mandatory, whether or not your Scrum Team enjoys it.

  1. Do not look for the guilty.

One of the biggest fears when people enter a Sprint Retrospective is that the meeting becomes a witch hunt, where the only thing that matters is to find whoever is guilty for the problems. To avoid this, it is very important that the team understand the objectiveness of the meeting. The team should be prepared from the outset to listen to constructive criticisms so that they can create an action plan of improvements for the next sprints.

This will only be achieved after a time of maturation of the team within the Agile methodology, so these discussions should be encouraged by the Scrum Master.