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.

Facilitation Training in Dublin

No matter what type of facilitation training you do, preparation is the key.  How to prep for workshops, requirement refinement, meetings, retrospectives etc.

The best preparation is to come up with a vision for the workshop. I have a simple 5 step model for training, I call it AIDED. The model highlights preparation; it’s not about how to run the workshop. Good workshops run themselves, but a great seminar needs organisation.

The model ensures that as a facilitator you are prepared and have visualised the results. No big deal if it doesn’t work out as planned but you can get the ball rolling and keep it moving if things get stuck. It’s also about the journey to becoming a fantastic facilitator. There are many layers to AIDED that you need to build-on with experience.

So when you are dropped in it and asked to facilitate, we have the model to calm the nerves and get working on it.

A, Ask. The questions to ask

I, Interaction. The type of interaction you are looking for in the workshop.

D, Discussion. What kind of discussion format do you expect?

E, Evaluation. What type of evaluation are you expecting?

D,  Decision or outcome that you want to achieve.

INTRODUCTION TO AIDED

Ask

A list of question that you can ask at the workshop.  Later, I discuss how to formulate outstanding questions; there’s a bit of an art to this. Initially, you’ll probably need about 5 or six items to debate. Not sure where to start, ask the attendees or other stakeholders what topics they want to be explored or answered. Even if you know this already it’s a great idea to ask participants directly again. It involves them and perhaps gives them ownership in the workshop outcome.

Interaction

How do you want the interaction to go? There is a vast number of possible ways that you want the communication to go. You need to pick the way that works for the question, the audience and what you the facilitator can control. Brainstorm, go round, smaller groups, fish bowl, shout out, whiteboard, Pair Share. We have plenty more to explore and learn.

Discussion

or sometimes I say delivery. How do we create a forum to get to the bottom of the topic. You’re subsequently handing it over to the floor to work through it. Again the range of techniques here is vast.  You may need to try a few from the tried and trusted cause-effect diagrams, affinity or more sophisticated Liberating Structures.

Evaluation

The facilitator needs to ensure that the attended have worked through an evolution of the items discussed. What are the options, how do they compare, this can be contentious. However, as a facilitator, you’ve got them working through it.

Decision

We have wasted our time if we don’t get to a conclusion. As a facilitator, you should prepare for the decision and mobilise the authority to decide in the room. We are passionate about this learning outcome.

There are many layers to facilitation training; AIDED can help you build a roadmap to get it right. I’ll post a few more expansions of this in the coming weeks.

 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.

Scrum Training

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

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
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

How do you Eat an Elephant

So we have heard the saying, How do you eat an Elephant – One Bite at a Time. Well that’s not how project managers eat elephants – Project manager share the elephant – divide it up and find the right people to do the eating.

Why?  There are a number of reason why

The Elephant will be well gone off before we progress any distance. Project management need to create a sense of urgency and if the goal is to get the elephant eaten then we have to share.

We will be sick of elephants. We need to give ourselves little goals otherwise we will be sick of the tedious task of just eating the same thing.

 

 

To share we first must break the Elephant down into manageable pieces. Project manager call this the work breakdown structure. Once we have identified the manageable pieces we find the right person to take on this smaller task. In-fact the The project manager puts together a team of people to work on the job simultaneously thereby getting the elephant eaten as quickly.

If it all goes well,  chances are the project manager didn’t actually eat any elephant, he share everything.

PMO