Posts

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.

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.

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.