Courses – Scrum Master Training in Dublin 

Scrum Master Training provides a framework for leading and developing your team. As we know, the goal of any organisation is to have high-performing, cross-functional teams. Agile has transformed how projects operate and how innovation is applied. Scrum is a highly effective framework to apply agile. 

The Scrum Master is responsible for making sure that the team lives by the values and practices. They help the organisation to empower the team to deliver on the vision for the product. They are the organisation change agents and remove obstacles to improve as a process owner for the team and to do anything possible to help the team perform at their highest level. He/she is a genuine mentor, visionary and process champion for the team and not a mere manager, guru or a project administrator. This Scrum Master session is a 2-day course that covers the principles and (empirical) process theory underpinning the Scrum framework, and the role of the Scrum Master in it.

In this course, students work on real-life cases with other classmates together as a team. This course is made up of discussions and hands-on exercises based on real-life situations. Scrum Master courses take place in Dublin and Cork, and you can arrange in-house training. In addition to this, the course covers all the topics related to Scrum Master including practice exams.

Topics Covered 

  • Scrum theory and principles
  • The Scrum Framework
  • The Definition of Done
  • Running a Scrum project
  • Working with people and teams
  • Scrum in your organisation
  • The role of the Scrum Master
  • Scrum Master sample exam with work through and discussions on responses

Who Should Attend?

Project manager, Program Manager,  Technical project manager, Team lead, Project lead, Technical lead, Release manager, Test manager, Test engineer, Quality engineer, Quality analyst, Test analyst, Business analyst, Software Engineer, System Engineer, Developer, Programmer, Account manager, Service Manager, Manager, Product Manager, Software coder, Software tester, Manager – software development, Architect – software development, Product management

Sample  I Quizz

This is a 20 question I sample quizz, it its a fair reflection of the PSM and a slightly more difficult than CSM questions. More difficult questions have been added recently to to the quizz so be sure that any tests you do are recent versions (Summer 2017).

Its 15 minutes long which reflects the timings in the real exam, register on the site to get more sample exams.

The Specific Reasons Why a Scrum Master is Not a Project Manager

 

Companies new to Agile often fall into the crucial trap of mistaking the Scrum Master role with the role of a Project Manager. This often leads towards a dramatic detriment in productivity, since the Scrum Master role requires a very specific skillset which is entirely different from the more generalist role of a Project Manager.

 

This article will point out the main differences between those roles and help you to chose the right person for both positions to make your project a success.

 

The Classical Role of Project Management

 

The Project Manager leads the project on a day-to-day basis, controls, communicates and provides direction. His role can be summarizes into the four following categories:

 

#1: Manage Processes: The Project Manager gets the project “up and running”, selects the team, establishes milestones and project schedules with the team and leads the project on a daily basis

 

#2: Track Process: The Project Manager monitors the timely achievement of milestones, tracks team costs and investments, overseas the documentation and provides direction

 

#3: Facilitate Cross-Functional Collaboration: The Project Manager Identifies linkages between sub-projects and coordinates cross-team cooperation

#4: Communication: The coordination of key project-related messaging to internal and external audiences, as well as communicating project information to the line management are Project Management roles

The Specific Role of the Scrum Master

The Scrum Master on the other hand does not manage the team on a daily basis. His role is more of a coaching and a facilitation role regarding Scrum, which makes him the link between the project team and the client.

Scrum Masters cooperate closely with the Executive Sponsor. They ensure that the project complies with Scrum and that all processes are implemented properly. The role can be summarized into the 3 following categories:

#1: Overcome Stumbling Blocks: The Scrum Master steers the development, resolves problems and involves the right people in the development process

#2: Oversee the Groundwork: The Scrum Master keeps two eyes on user experience, functionality issues and feedback from all stakeholders

#3: Provide Guidance: Helping to facilitate changes and assist in the planning process while providing overall Scrum guidance is a crucial function of the Scrum Master

 

There you have the main difference:

The Scrum Master is there to help and assist with highly specific technical knowledge but not to manage the workflow.

Summary: The Scrum Master is not a Project Manager

 

The role of the Scrum Master is more specific and technical than the more general role of a Project Manager. Both are important. Confusing these roles however almost certainly leads towards failure in the execution of Agile – and towards huge losses.

 

Make sure you have these important positions covered with the right people.

Agile Priniples

Back to Basics: When was the last time you looked at the Agile Manifesto?

 

The Agile Software Development method was officially introduced in 2001 (http://agilemanifesto.org/). However, evidence of similar incremental software development methods dates back to as early as 1957. The recent hype due to the method’s continuous improvement and rapid development led to confusion and information clutter.

 

It is time to take it back to the basics today and focus on Agile’s core values.

 

Honestly, when was the last time you looked at the Agile Manifesto? If this has been a while ago, here is a quick summary to refresh your memory and help you focus on the core conceptual framework.

 

The Agile Manifesto – The Key to Success in Agile Development

 

The manifesto was laid out in February 2001, when 17 software developers met in Utah to discuss lightweight development methods. The results have been groundbreaking. Here are the main values and working principles.

 

The 4 Core Values of Agile

 

In order to uncover more user-friendly ways of software development, the following values have been announced.

 

Individuals and Interactions      >          Process and Tools

Working Software                           >          Comprehensive Documentation

Customer Collaboration                >          Contract Negotiation

Responding to Change                  >          Following a Plan

 

Are you following these core values in your recent Agile project? If not, do not be surprised if the project lacks in success.

 

The 12 Core Principles of Agile

 

#1: Customer Satisfaction: Develop valuable and useful software quick

#2: Welcome Change: Make changes during all stages of development

#3: Frequent Delivery: Produce little working chunks of software constantly

#4: Close Cooperation: Co-create the software with all stakeholders

#5: Motivate Individuals: Develop a working atmosphere of mutual trust

#6: Direct Communication: Talk to involved parties face-to-face as much as possible

#7: Working Software: Produce software that creates results

#8: Sustainable Development: Maintain a constant development pace

#9: Continuous Attention: Focus on technical excellence and good design

#10: Simplicity: Maximize the amount of work not done

#11: Self-Organization: Allow teams to self-organize around their strengths

#12: Regular Adaptation: Adapt to changing circumstances

 

These principles can be applied to almost all processes of your business. In Agile, they are crucial towards the efficient and timely achievement of real results.
These core values and Principles are vital to the implementation of an agile process, it is essential that you regularly look to these principle to ensure you are not just following a process but truly building an agile environment.

The Six Attributes of a User Story and Why They All Count

The current best practice in Agile Software Development to clearly and briefly describe the functionality from the end-user’s perspective is the User Story. High quality User Stories will become part of the product backlog iteration. Weak User Stories are a waste of time and should be avoided at all cost.

This article will teach you the six attributes every effective user story must possess to pass the backlog quality check and ensure you spend your time right.

 

The INVEST Mnemonic To Writing High Quality User Stories

This simple, yet profoundly powerful mnemonic is a creation of Bill Wake the co-inventor of Extreme Programming.

I = Independent

A great User Story has the potential to stand for itself. By following this criterion the story can be scheduled and implemented in any desired order. This makes the story usable in different contexts and for multiple concepts.

N = Negotiable… and Negotiated

Outstanding User Stories are co-created by the programmer and the user. Only the main essence is captured, while the details are steadily added and influence the whole backlog in an iterative manner.

 V = Valuable

All great stories add specific value to their target audience, in this case: the user. Especially when splitting stories, each individual piece should address one very specific area in which value is created, while telling the overall conceptual story.

 E = Estimable

Every User Story must be estimable in order to be considered for a ranking by the customer. The degree of ratability is directly linked to the story being negotiable. Only stories that are understood by all stakeholders are estimable in scope and budget.

S = Small

A Story should not be overwritten and only focus on one key value adding idea. Keeping it within the range of a few person-days and at most a few person-weeks ensures that the story will be estimable.

T = Testable

Stories must be testable in order to be considered for the product backlog. If a story is not testable due to a lack of information it probably is not estimable and does not provide specific value to the customer.

All of the six attributes have to be considered in order for the User Story to be implementable. They affect each other in an iterative manner. Shortcomings in one area may lead to an information deficit in another and towards an unusable story.

 

Take the time to check your User Stories for all of these attributes. Time has shown that a Feedback Circle of Proposing – Estimating – Implementing is the most effective way to produce a great User Story, implementable in many different contexts.

Where to with the user story when completed

A user story is typically functionality that will be visible to users, by users this includes end users, administrator’s manager. To create a user story will require a number of tasks to be completed. These tasks are often shared out among a range of people such as analysis’s, designers, programmers and testers so each has their own task. When put together the tasks complete the user story.

 

User stories appear on the Product Backlog and tasks appear on the sprint backlog.

Include INVEST workshops as part of good Scrum Master training and coaching.

Agile Practiitioner

The PMI-ACP is not difficult  but it does throw up some strange questions as the PMI try to relate the traditional PMP material to the  Agile methodologies. Many of the analysis techniques like  earned value are difficult to related to software development in a waterfall environment and applying them to agile seems like an unnecessary overhead we have no BAC.  The good news is that it is all due to change.

The current exam focuses on Scrum , Lean, Agile Concepts (the manifesto)  Kanban and XP and then mixes them up to create situation questions relating to general management or Project management (servant leader, Emotional intelligence etc.)

Mike Griffiths book is still the best general book, though I don’t think it gives Lean the coverage that is needed for the ACP Exam. Be careful with the online PMI-ACP exam question available online as  many of them are absolute rubbish, frustratingly written in an unknown dialect of English with confusing or completely incorrect answers.

The Velocitech website is probably the best set of exams out there and Andy Crowe’s  book is a good reference book with exam questions for the ACP exam but it is not a complete guide.

I do suggest that you research Mike Coen (Scrum) and  Mary Poppendieck (Lean) material. Their  publication,  webinars and blogs are a good source. Ken Schwaber book the “the art of doing twice as much in half the time” is worth a read for motivation though not particularly useful ACP

The books if you have the time are;

    • User Stories Applied: For Agile Software Development – Mike Cohn
    • Agile Software Development with Scrum – Ken Schwaber & Mike Beedle
    • Extreme Programming Explained – Kent Beck
    • Agile Estimating and Planning – Mike Cohn
    • Lean Software Development: An Agile Toolkit – Mary & Tom Poppendieck
    • The Art of Agile Development – James Shore;

The Project Management Institute suggests a number of others on their website. These have changed from the previous exam  with 4 new books added and 4 removed. 2 are on Kanban alone.

The exam time is 3 hours with most of my student competing it in 1.5 hour and many in less than an hour. The question are not as tricky as the PMP exam, correct answers are more obvious and less where the answer required is the ‘‘best’ or ‘first’. Moving from agile concepts will catch you out, one minute we are taking about the customer, the next it’s a product owner and the next question may be from the point of view of a Project Manager.  

The course is a good course to get yourself up to speed as a traditional project manager, a middle manager or perhaps as a product owner. For developers or budding Scrum Masters It may not provide the level of detail and doesn’t deliver the ‘fun’ experience that agile encourages.

The course is changing with a different approach. It looks to me like it will concentrate more on the approach and mind-set and less on the specific concepts.  I suggest that it will aligned with the directions that the PMI have for the skills of  a combination of technical, leadership, and strategic and business management expertise

The new PMI-ACP exam will see a number of changes (PMP Exam Content Outline,) summarised below

There are sever domains of Agile practices

    1. Agile Principles and Mindset
    2. Value-driven Delivery
    3. Stakeholder Engagement
    4. Team Performance
    5. Adaptive Planning
    6. Problem Detection and Resolution
    7. Continuous Improvement (Product, Process, People)

The distribution of questions on the PMI-ACP exam paper are now based on the domains

  1. Agile Principles and Mindset – 16%
  2. Value-driven Delivery – 20%
  3. Stakeholder Engagement – 17%
  4. Team Performance – 16%
  5. Adaptive Planning – 12%
  6. Problem Detection and Resolution – 10%
  7. Continuous Improvement (Product, Process, People) – 9%

New Tools and Technique / Knowledge and Skills are added while many are removed from the new PMI-ACP exam syllabus. New items added including:

    1. Developmental mastery models (for example, Tuckman, Dreyfus, Shu Ha Ri)
    2. Participatory decision models (for example, convergent, shared collaboration)
    3. Agile hybrid models
    4. Managing with agile KPIs
    5. the Five WHYs
    6. retrospectives, intraspectives
    7. control limits
    8. pre-mortem (rule setting, failure analysis)
    9. fishbone diagram analysis
    10. minimal viable product (MVP)

Althris Training have worked with our partners to redevelop our course material for the new ACP exam. To keep you posted and get more updates on both drop me an email

Does ‘servant leader’ sound strange to you? After all, does it make sense to talk about leading a team so that it moves forward to achieve goals, while being behind it to tend to the wants and needs of team members? Yet in numerous project management situations this style of leadership can be very effective. What might look like incompatibility at first blush becomes a doubly positive force for obtaining better results faster and more efficiently.

Agile project management methods like Scrum are a case in point. Handling change and rapid development cycles requires intelligence and creativity from team members. Leaders that try to pull rank are likely to do more harm than good. On the condition that everybody understands the basic rules of engagement, the contributions to be made and the objectives to be met, hierarchical levels can be taken out of the equation.

A servant leader then:

  • Assures the well-being of the team and team members
  • Prioritizes his or her own actions to help team members solve problems (without dictating the solution)
  • Focuses on people, on the understanding that well-motivated and enthusiastic people will meet project targets and expectations best.

At the same time, the servant leader is also the lynchpin for communicating with sponsors, stakeholders and other management. This is as challenging as any other leadership approach. That means good servant leaders are usually the ones that have had the right training and experience. And the right training also instills the recognition that servant leadership is one possibility among several, to be applied as and when the situation calls for it.

Focus Courage Respect Commitment Openness

Scrum Values apply to all the team not just the Scrum Master or Product Owner and they are Values that can be effectively applied to Agile and traditional waterfall methods. When moving from waterfall to Agile there values are the first thing for the Scrum Master to get the agile team to buy into.

 

Focus – Team focus and Sprint goals are important responsibilities for the Scrum Master. The Scrum Master should remove impediments from the Team and protect the Scrum team members from external influence.

 

The Product Owner and Scrum Master should be responsible for ensuring a well groomed backlog which is both estimated and ordered and the team should be fully be focused on delivering the work committed to in the sprints.

 

Courage – The Team member must have the courage to speak out and ensure that their contribution is heard but with an openness other. The. Scrum Master needs to have the courage to negotiate with stakeholders and the Product Owner when it’s right to do so!

 

Whilst at the same time the Scrum team needs the courage to commit to as much work as possible within the Sprint whilst respecting the definition of done.

 

Openness – This is a core Scrum Value that makes Agile so much more effective than traditional management.

 

The Back log should be fully qualified and visible so that everyone is aware of what work is up and coming. The retrospective must be fully open with problems openly discussed

 

Commitment – The Scrum team commits to what they will complete each sprint. They also commit to how the work will be ‘done’ and to meet the Definition of Done.

 

The Team commits to doing whatever is collectively necessary in order to meet their goals.  The wider organisation also commits to support the scrum team and to respect the values of Agile.

 

Respect –This is perhaps one of the important values in Agile… And sadly one that I often observe is not followed! The Product Owner gets to dictate what work gets done and in what sequence – And it’s the responsibility of the Scrum team to respect those decisions. However The Product Owner must trust and respect the team to decide how they will accomplish this and respect the team when they push back or if they believe the Product Owner is encouraging them to overcommit. The Scrum Master should be aware that they are not management but the servant leader responsible for ensuring that the Scrum team is able to run at maximum efficiency and to coach stakeholders, Product Owner and the Scrum team on all things agile!

 

At Althris Project Management Training we have some tool and Agile games to help get the team focused on these values. For further reading I suggest you look to see what Ken Schwaber says about the Scrum Framework for software development.

Make no doubt about it the early scrum (Planning and Daily)  meetings set the tone for all the following activities of the project. With Scrum, life cycles are short and the pace hot with little time afterwards to re-jig team attitudes and behavior.  With the early meeting setting the tone for the rest of the cycles I suggest that you create an additional scrum kick-off meeting.  This can help to ensure that subsequent scrum meeting are focused on the scrum job and not the “ground rules”

This Scrum kick-off meetings gets the getting to know how it works out of the way. Subsequent team meetings will need to be rapid stand-up ‘huddles’ lasting for all of 15 minutes, you don’t want your kick-off meeting to seem too leisurely. Yet you also want to take enough time to set the scene properly for future success. The following tips may help:

  1. Remember that Scrum is also about trusting people’s ability to solve problems. The team may be the best source of answers for some questions that arise.
  2. Make sure your whole project team is there, for full input and engagement. Change the date to accommodate anyone who has a schedule conflict.
  3. Notwithstanding quick-fire project meetings in the future, allow plenty of time for the kick-off meeting.
  4. Make sure team members get to know each other. Fun exercises and games are one possibility.
  5. State or remind the team of how Scrum works and the roles of the Scrum Master and project team members.
  6. Agree on definitions (when is a deliverable truly ‘done’) and project tools (specific project management and issue tracking software, for instance).

When you get steam up on your Scrum process afterwards, remember that from time to time, it’s good to have periodic get-togethers along similar lines to the kick-off meeting. This can be an important factor in maintaining team enthusiasm, cohesion and momentum.