Scrum Roles –  Agile Software Development

Who are you? The three Scrum Roles explained.

Introduction

scrum team has a slightly different composition than a traditional waterfall project, with three specific functions. To better understand the basics of Agile, it’s worth talking a little about roles and responsibilities within the Scrum team. I will also tell you a little about the problems that can happen in this structure.

The Scrum Team three roles include, The Product Owner, Scrum Master and Development Team, are sufficient to deliver high value-added software according to the framework. Let’s see, in common lines, how this works.

Product Owner, the owner of the backlog

The project begins with the Product Owner: he or she is the person who knows the business and the end user’s need. With this knowledge, the PO can prioritise the needs of the user and decide what else adds value to the company. That is, this is the person who orders the product.

The Product Owner can even decide the product developed is sufficient to meet the needs and finish the project. Incidentally, this is one of the hallmarks of Scrum. Since we opted for the essential features to the business first, it is not uncommon to finalise the project with fewer items than initially envisioned.

After all, some studies point out that most of the features are seldom or never used.

The Product Owner separates a wish list, called the Product Backlog, which contains everything he initially thinks he needs to serve the business and the end user. This list should be prioritised based on the value that each item can add to the business.

Once complete, it is up to the PO to write the user stories, which detail each item in the wish list a little more. It is also up to him to take care of the project budget, ensuring that the investment yields an expected return as soon as possible.

The Product Owner supports the Development Team by answering questions about business rules. It’s crucial to the success of the project. On the other hand, the Development Team has someone available and accessible to answer the product owners questions.

Scrum Master, the proactive coach

The next role to play is the Scrum Master. He or she acts as servant leader and coach, to both the Product Owner and the Development Team. When the organisation begins to adopt Scrum, it is common for either the Technical Leader or perhaps a Project Manager to assume this role.

Be cautious of old vices: the former technical leader will tend to give technical solutions to the development team, just as the former project manager will have a strong inclination to commit to deadlines that must be met at any cost and to direct the team members, telling who does what. A good Scrum Master is there to help the team practice self-organisation.

The Scrum Master knows the process; he can instruct the Product Owner concerning Scrum practices. It guides the PO throughout the project. In the same way, it should guide the Development Team to achieve that team sprint goal. It is up to the SM to eliminate any team of impediment that hinders the progress of the team, seeking to help the team to improve its productivity.

Mike Cohn once wrote about the six attributes of a good Scrum Master:

  • Responsible for the adoption of Scrum practices and not for the success of the project;
  • Humble to the point of putting the interests of the team above their own;
  • Collaborative because he or she helps to create a collaborative environment among team members;
  • Committed to the purpose of the project and to the resolution of impediments that prevent the team from reaching its objectives;
  • Influential, both inside and outside the team, to carry out their duties to build the team and to eliminate impediments;
  • Understand the knowledge necessary for the team to achieve its goals.
  • Knowledge in facilitation techniques and Team Growing are differential of any Scrum Master.

Development Team

The Development Team is composed of those who create the product increment. Scrum does not define titles, so all its members are mostly developers, regardless of their function within the framework. The concept of the multidisciplinary team: all members can perform any task that is necessary for the project. However, it is common to observe teams that have members with specific functions.

The size of the team varies according to the project. Some people defend the idea that a team has 5 to 9 members. In particular, I believe the team should be small enough to stay agile and big enough to deliver the expected value to the product. It is a somewhat subjective interpretation, but it gives more freedom to the organisation of the team.

Another exciting feature is that the team is self-organising, that is, who decides who does what, what the roles of each member are and what is not Sprint is the team! This is key to creating a collaborative environment within the team. Seeing sense and actively participating in decisions, team members become much more motivated to commit to the expected results.

To learn more about our Scrum Master Course view our in-class courses to help you develop your skills.

 Waterfall Vs Scrum – what is better?

Waterfall advocates that we do a significant amount of design upfront. But it’s not possible to do it all up upfront. That never happens in any traditional project.

Waterfall Vs Scrum - Althris Dublin Training for project management

Scrum Master Certification

Scrum advocated that we should not over design as the customers/user doesn’t know what they want. Therefore spending time investigating would be wasted. Let’s build it and as we develop, check with the customer to see if it’s what they want.

Importantly, Scrum is not a series of mini waterfalls where we design for a few days and then build then test the next few days. We should do the design, develop and test at the same time. Removing the upfront design effort and merging it with the build. Chances are, it will take the same amount of energy to design and build, but it will be what the customer wants – better quality. And we have maximised the amount of work not-done by not delivering what the customer did not need.

Project Management and Agile-Scrum

But what about the long-term planning, a lot of the longer term planning goes out the window. But Scrum does not account for the fact that there is still some longer-term planning required. For example, it may take the supplier three months to provide the interface design or organise the training days at least two months in advance. You are going to have to implement some traditional planning to get this right. Agilest might call this release planning; traditionalists might call it program management. I think they are more or less the same thing – both aim to link organisational strategy to tactics.

Both traditional project management and agile-scrum are trying to tackle the “getting it done” part of the business. A business needs to recognise the tactics for change. However, they approach it in a different way. Traditional Project Management suggests that we can deliver on the tactics by planning, setting the rules and measuring progress. The tactics for an agile-scrum help a team share the goals and empower them to get it done – now.

So what will work better, empowering the team or measuring the activity? You decide based on the complexity of the task and the engagement levels of staff.

Althris provide training in Scrum Master, Certified Product Owner, Agile and Iterative Project Management Methods.

Project Management Agile Training

Agile Training in Dublin – Starting the Agile Journey

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 one 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 is impossible to read or does a project manager use this stuff? Scepticism of these methods kick-off my class nicely and it doesn’t take long for students 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.

Twelve Principles of Agile Software Development

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 to get them to agree that a dynamic business would welcome changes and a more conservative business might be better to resist them.  The question “which type of business would you rather work for ?” became redundant.

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 agree that it was vital to have close co-operation especially in a dynamic environment.

The Stacey Matrix

Scrum Master Training Dublin Stacey’s 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 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 felt that good business analysis could 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 little light-hearted games at this stage. I used a “document the drawing” vs “describe the drawing” game and this went down 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. After the session, they all agreed to implement a personal Kanban board for their exam practice. At this stage I figure I can do no wrong, we decide 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.

Some questions arose like

  • But what happens when we don’t have full-time teams
  • Most of our project are about the 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 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 attendees felt that Agile training wasn’t entirely focussed on project management but instead team management.

Brush up on your knowledge with our expert PMP evening workshop session. PMP may still have a long life but let’s stretch ourselves and be more agile.

Exam Pres

The course is based on the PMI-ACP Examination Content Outline, including:

  • Tools and Techniques for Agile Project Management (50% of exam questions)
  • Knowledge and Skills (50% of exam questions)

We provide training on the underlying principles and values of the Agile Manifesto and the most common Agile methodologies that are on the Exam, including:

  • The Scrum Framework
  • Extreme Programming (XP)
  • Lean Software Development
  • Kanban in Software Development
  • Other
  • Feature Driven Development (FDD)
  • Dynamic systems development method (DSDM)
  • Crystal Clear

Coverage

We will cover all 6 Agile knowledge domains and underlying task areas:

  • Value-Driven Delivery
  • Stakeholder Engagement
  • Boosting Team Performance Practices
  • Adaptive Planning
  • Problem Detection and Resolution
  • Continuous Improvement

 

 

 

 

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

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.