Scrum roles

/by

Scrum Roles

Scrum is a lightweight Framework that helps teams to deliver value. Scrum describes three accountabilities, also known as Scrum roles, that make up the Scrum team: Product Owner, Scrum Master, and Scrum Developers, also sometimes simply known as the development team.

The Scrum Team’s primary focus is to make the best possible progress toward the Sprint goal, which is the single objective for the Sprint. Within a Scrum team, there are no sub-teams or hierarchies. Rather, the team is a self-organized and self-managing unit of professionals. In contrast to classical project management methods, Scrum doesn’t have a product manager or a team leader. Let’s dive into the different Scrum’s different roles and responsibilities.

Recommended e-learning: Learn about the different elements of the Scrum framework and why it works only in its entirety in our Scrum Foundations online course. 

The Product Owner

According to the Scrum Guide, the Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.

Product Owner Responsibilities

 This role also holds a lot of accountability, as the name suggests. The PO has three key responsibilities.

Recommended for you: Product Owner Online Short Course

Manage the Product Backlog 

The Product Owner is usually one person who is accountable for effective Product Backlog management. The Product Backlog is an emergent, ordered list of what is needed to improve the product or service. This includes developing and communicating the product goal, creating and ordering product backlog items, and ensuring that the product backlog is transparent and visible at all times. As a result, they often have to prioritize work and backlog items by keeping the product goal in mind. 

Stakeholder Management 

Often the PO has to “fight on both sides”. The Scrum Team often works within a specific time frame (the Sprint). During the Sprint, the Product Owner often needs to deal with marketing, management, or customers in order to prioritize work and maximize value. The PO must be an excellent communicator, as they must be in contact with all stakeholders, sponsors, and the Scrum team throughout a project.

Return on Investment

The Product Owner is also responsible for the return on investment (ROI). They validate the solutions from the end-user’s point of view and verify whether the quality is acceptable or not. 

Product Owner vs Product Manager

Typically speaking, product managers are strategic and focus on the product’s vision as well as the company’s objectives and the market. Product Owners, on the other hand, are more tactical and focus on fulfilling a product vision by managing backlogs and working in cross-functional teams. A good Product Owner needs to be able to take responsibility, as the name suggests, for the success or failure of a project, which means they need to communicate effectively and juggle people’s expectations.

The Scrum Master

The Scrum Master (SM) is accountable for establishing Scrum as defined in the Scrum Guide. The SM helps to increase the team’s effectiveness by enabling continuous improvement and making sure that everyone understands the theory and practices of Scrum, both within teams and the whole organization. 

Recommended Training: Certified Scrum Master (CSM) Certification 

Scrum Master Responsibilities

According to the Scrum guide, “Scrum Masters are true leaders who serve the Scrum Team and the larger organization.” 

Improve the Team’s Effectiveness

The Scrum Master should create optimal working conditions for the team and keep these constant throughout the Sprint. This includes making sure that the team follows the Scrum Framework and understands all the elements of Scrum, including the five Scrum Events. They should have a comprehensive knowledge of Scrum and be able to act as a servant leader by creating the ideal environment for teams to thrive.

Remove Impediments

A Scrum Master is tasked with creating an environment for teams to thrive. They should aim to get rid of all possible impediments – or problems – that might disturb the work of the team. Usually problems can be classified in three different categories:

  • Problems the team cannot solve: For example, there may be a lack of necessary hardware or software, or a stakeholder such as a manager is making unrealistic demands of the team. 
  • Impediments related to organizational structure or strategic decisions: There are many examples of this. Perhaps the office or virtual workspace is not adequately set up to enable teamwork: maybe there is an unreliable internet connection, or meeting rooms aren’t available. Another common example is that the Scrum Master is viewed as being a project leader, and the team isn’t viewed as their equals. 
  • Problems related to the individuals:  This may include technical issues like computer crashes, or delays resulting from team members needing to wait for input to complete a task they’re unable to handle alone.  

The Scrum Master can’t and shouldn’t solve every problem alone, but they are still responsible for guiding the team towards solutions and removing impediments. This task often takes up a lot of time and requires great resilience and the ability to care deeply for the team. 

Serve the Whole Organization 

The SM should lead the organization in adopting Scrum. They should help employees and stakeholders enact and understand Scrum so that it can be successfully implemented. They may need to coach and advise in these instances.

 

Scrum Master vs Project Manager

The most obvious difference between a Project Manager and a Scrum Master is represented by the name itself. A Project Manager manages the project and sets the tasks, while the SM is in charge of ensuring that the team adheres to the Scrum framework. The Scrum Master does not interfere with the decisions of the team in terms of what they do, but acts as an advisor to the team when it comes to how they work. They only interfere when any participant in the project does not align with the principles of Scrum. A project manager, on the other hand, often gives directions and takes responsibility for the completion of tasks.

The Scrum Developers

The Developers, or sometimes simply referred to as the Scrum Team or development team, have all skills necessary to create a valuable Increment for each Sprint, and they self-manage. 

Scrum Developer Responsibilities

This team typically consists of three to five people and the specific skills needed by the Developers are often broad and will vary with the domain of work, however, they typically share the same set of responsibilities within a Sprint.

Create a Plan for the Sprint

The developers do not simply receive tasks from a project leader; they are self-managing and decide how many User Stories they can accomplish in one Sprint themselves. They create a plan for the Sprint, the Sprint Backlog (which is composed of the Sprint Goal, the Product Backlog items selected for the Sprint) as well as an actionable plan for delivering the Increment.

Manage and Execute Their Work 

The developers instill quality by adhering to a Definition of Done and work to ensure that they meet that standard. They may need to adapt their plan to reach the Sprint Goal and always hold one another accountable during the Sprint. 

Scrum Developers Work Differently from Traditional Teams

Developers in a Scrum Team decide on their tasks and are responsible for the execution of them – the team becomes a manager. The Scrum Master does not need to delegate all the work and plan the project

Get The Most out of Scrum

Scrum is simple to understand, but it can be difficult to master. Scrum is purposefully incomplete: It just defines the rules of the game, like the rules of a sport. That’s one reason why Scrum is hard to master: you need to know so many things outside Scrum to make it work successfully. 

And if you need help implementing Scrum in your organization, get in contact with us.

Daily Standup

How to Revive Your Daily Standup

/by

The daily standup is a fundamental part of Scrum rituals, but it’s also one of the most misunderstood. At agile42, we’ve been coaching organizations to facilitate these Scrum events for 15 years. We’ve guided hundreds of teams towards making these 15-minute sessions stand out as a useful, valuable, and enjoyable event. Here’s our guide to what a daily standup actually is, along with some of our tried-and-tested methods to bring life back into the daily standup. 

Recommended online course: Facilitating Scrum

What is a daily standup?

The daily standup is a 15-minute meeting that takes place every day. Although the meeting is not exclusive to Agile methods, it’s an integral part of many Agile frameworks and methods including Scrum, Kanban and XP. 

Daily standup vs Daily Scrum

While the terms “daily standup” and “Daily Scrum” are used interchangeably, there is technically a difference. The Daily Scrum is how it is referred to in the Official Scrum Guide and makes up one of the five Scrum events. The daily standup is a more general term for a quick 15-minute catchup, used in Kanban and other settings outside of a Sprint.

Why is a daily standup meeting important?

It is important to understand the purpose of the daily standup, so that you can make sure this Scrum event is a good use of everyone’s time. The two key purposes of a Daily Standup are: 

  • to agree as a team on how to deliver the most value in the next working day; and
  • to inspect and adapt the sprint plan if necessary, in order to deliver the most value in the sprint.

If you’re having trouble keeping your daily standups, it also helps to remember the Lean and Agile principles that guide these events: 

  • Focus on outcomes over output (or results over activity)
  • Focus on priorities
  • Emphasize team ownership of results over individual assignments
Daily Standup Meeting

Photo by Parabol

How to run a daily standup

The standard format for a daily standup consists of each team member answering three questions: 

  • What did you achieve yesterday? 
  • What will you achieve today?
  • What impediments are in your way?

This format is used widely with varying degrees of success. While it is the original, traditional format, you don’t have to use it if it doesn’t work for your team. Each team has its own needs and preferences, and as long as you’re focusing on what’s important – like communicating, prioritizing, and managing the flow (not the people) – you can change the format to better suit your needs. The traditional three-question format can also really easily devolve into a mere status update meeting, failing to achieve the purpose of the daily standup and failing to embody its principles. If that’s happened to your dailies, you may need to find a way to revive your standup. 

How to revive your daily standup

If your daily standups have turned into status updates, your team is disengaged, and you’ve lost touch with the principles of Scrum that guide the concept of these meetings, you’re not alone. Many organizations have difficulty running effective standups, and their teams feel like they’re not an effective use of their valuable time. If the team is not finding the meeting useful, you need to find the root cause and fix it. Here are 10 ways you can bring life back into your daily standups, and reap the benefit of this crucial Scum event. 

Think of it like a sports huddle 

Jeff Sutherland, one of the creators of Scrum, says “The idea is for the team to quickly confer on how to move toward victory—i.e., complete the Sprint.” It may help to think of it like a huddle before a sports game: the team comes together to re-energise, encourage, and strategies for the day. It’s not a chance to chat about training schedules, travel expenses, discuss goals for the year, introduce new players, or any of the other concerns a team might have. It’s a quick, razor-focused strategy session for the match they are currently playing. 

Ask the right questions

If your daily standups are not working well for your team, and don’t feel like a good use of their time, it’s important to discover the root cause of this. Get someone from the team to observe the meeting and think about the following questions, to guide them to the cause of the concern: 

  • Situation: Does the team report to itself or the ScrumMaster? Is the situation presented honestly? Do they have facts and information in front of their noses? Is the granularity right?
  • Focus: Is the goal clear? Is the team focusing on getting the next backlog item done, rather than ensuring everyone has work for the day? Is there a lot of bureaucratic overhead?
  • Speaking: Does everyone get the opportunity to speak? Who speaks most, who is most silent? Do people listen intently or are they just waiting for their own turn? Are people supporting each other?
  • Decision-making: Who makes decisions? Is it one person or the whole team? Do they evaluate multiple options? Are decisions based on facts? If they make guesses, do they go on to validate the decisions before investing time?
  • Language: Does the team have their own “slang”? Does the body language support the verbal message? If you’re running virtual standups, are cameras on or off?
  • Trust: Are they showing respect for each other and for other teams? Are they having fun together? Can they bring up difficult topics? Are they showing courage?

Focus on the work, not the individuals 

The focus of a daily standup should be on stories and priorities, not on any individual’s to-do list or performance. Since you’re talking about the work and flow itself, and not about individuals, it is possible that one team member may speak a few times while others may speak less (or not at all) some days. This is okay: it is not a status report or a chance to check up on productivity; it is a chance for the team to make sure they have everything they need to achieve the outcomes they have in mind for that day. 

Brush up on your Scrum foundational knowledge

You simply can’t facilitate a standup well if you aren’t well-versed in the principles of Scrum. Consider taking an online Scrum course, to make sure you are being guided by the right principles and practices. 

Online Scrum Courses

Keep it to 15 minutes

The 15-minute time limit of a daily standup is there for a reason. Set a timer, and make sure you stick to it. This keeps the meetings productive, focused, and to-the-point. If other distracting conversations come up during this meeting, you can make a note of them, but do not discuss them now. Which brings us to our next point… 

Use a parking lot to stay focused

Use a “parking lot” for discussions that are too long or do not concern the whole team. You can have a literal whiteboard in the office, or a virtual space like Miro or Trello. When the standup veers off course, and other topics emerge, simply note them down for later and move on. Remember that anyone has the right to call “timeout” on distracting conversations; this is not the job of a leader or Scrum Master. 

Make sure these conversations and concerns don’t get forgotten forever. You can stick around after the standup to continue talking about them, or perhaps set aside a few minutes in your Retrospective at the end of the Sprint or project to do so. You can use a voting system to determine which parking lot conversations to prioritize and analyze. Keep the stand-up focused, finish it on time, and then anyone who needs to continue the parked discussions can do so after the meeting is over. 

Agree on the Scrum Master’s role

It is not essential that the Scrum Master attends this meeting, but it is also allowed, if that works for the team. However, it is crucial that the daily scrum is for team members to connect, prioritize, and plan for the day. The team should be speaking and making eye contact with each other, rather than the Scrum Master (or any single individual). This is a good way to tell if there’s a problem in the way the standups are running.

Agree on the Scrum Master’s role, and what works for your team. Should they attend? If so, should their key focus be to ensure that everyone remains focused and no external people are disrupting the purpose of the meeting? Or perhaps they should simply observe, or be available in case they are needed to help with any particular impediments.  

Change up the format

The traditional three-question format might work nicely for you, and that’s fine. But there are a number of other tried-and-tested formats that we’ve used at agile42 that can boost the effectiveness of the standup, depending on the team. Here are a few examples, suggested by some prominent thought leaders in the Agile community. 

Walk The Board

Jason Yip, Senior Agile Coach for Spotify, uses the “Walk The Board” format for standups. It is a great way to keep the focus on the board. Here’s how the format works: 

  • Gather around your team’s board. 
  • Start with the highest priority story/feature in progress.
  • Ask what we, as a team, can do to get that story done (per our Definition of Done).
  • Ask what is blocking us, as a team, from getting the story done.
  • Repeat steps 3-4 for the next few priority items, up to your team’s WIP limit. 
  • To finish, validate that everyone on the team has been heard and all are focused on the top priority stories.
Kanban Board Daily Standup

Photo by Parabol on Unsplash

The Sprint Goal

Olaf Lewitz, veteran and leader in the Agile community, suggests using a slightly different set of three questions: one that shifts the focus to the team and the sprint goal, rather than each individual’s list. He suggests asking:

  • What did we (as a team) achieve to get closer to the sprint goal?
  • What’s blocking us from focusing on the sprint goal?
  • What do we agree on doing today to make sure we reach the sprint goal?
The Two Plus One Questions

Founder of agile42, Andrea Tomasini, starts his standups by asking each person the first two questions:

  • What have I achieved since last time?
  • What impediments are still in my way?

Based on these answers the team as a whole can devise the best plan for the day. Finally, each individual can clarify her/his commitment to the team’s plan for the day by answering the third question: What do I commit to achieving today?

The Story of the Day

Dave Sharrock proposes a single question, to ensure the team remains razor-focused on the sprint itself. The question is, simply, “Which story will we finish today?”

Use a ball to add dynamism 

If you’re finding your main concern with standups to be that there is low energy and engagement, and you’re sure that you’re using the right format and sticking to the time limit, you can try adding a ball to the mix. Use a stress ball, tennis ball, or really anything you can throw around your workspace (without breaking things).

Once each person finishes speaking, they can throw the ball to the next person to indicate that it is their turn. This can make things a little more lively and fun, and it has the added benefit of keeping people listening and paying attention, since the structure is a little more unpredictable than going in a circle. If your team works remotely, you can use a version of this technique relatively easily. Simply say who you are passing the ball to, and that person can use your video conferencing tool’s “Raise Hand” feature to indicate that you’ve “caught the ball”. As an added bonus, nobody needs to know how good (or bad) your real-life catching and throwing skills are. 

Check the granularity of your tasks 

If you’re finding that your daily standup often runs over the time limit, and they’re defined by impediments, high levels of stress, or not meeting daily goals, there might be a problem with the granularity of your tasks in the first place. The tasks set each day should be achievable in a single day, to match the frequency of the meeting and foster collaboration rather than any kind of competition.

agile42 offers remote Scrum training

We offer Certified Scrum Master (CSM), Advanced Certified Scrum Master (A-CSM), Certified Scrum Professional-ScrumMaster (CSP-SM), Certified Scrum Product Owner (CSPO), Advanced Certified Scrum Product Owner (A-CSPO), and Certified Scrum Developer (CSD) training, in live remote sessions with our experienced certified coaches. If you need help, coaching, mentoring, or training, don’t hesitate to reach out!

person sitting on gaming chair while playing video game

Agile & Gaming Companies

/by

Handling rich creative content in a traditional Scrum team doesn’t always work as we might think: a single cross-functional team might simply be too large.

In many cases, the artwork and creative elements of a product, such as a game, requires work from many skilled artists, from graphic artists and UX to animators and audio engineers. Creating an art team to deliver art assets, and having them operate as a Scrum team can work. But there can be challenges with this too. In the following article I describe the experience of a gaming company that experimented with art Scrum teams and ended up combining engineering Scrum teams with art Kanban teams. This change was driven by the art team as an experiment, with the clear need to outperform the status quo (an art Scrum team).

Design + UX + UI + TESTIn many Scrum development teams, the design component is included in the team’s delivery. Either stories include mock-ups to be implemented as seen, or the cross-functional team includes a dedicated graphic designer/front-end designer who works as part of the cross-functional team to deliver a working product at the end of the sprint.

For highly creative (artistic) products, such as games, that include a large amount of design work, often equal to or greater than the engineering component, this approach can be difficult for a number of reasons.

•   First, the team size tends to be too large. Including art, audio, animation and engineering skills on a single team can lead to a large team, easily in double figures.

•   Second, there is often weak dependency between art and engineering. Building out art assets, including audio and animation, has little to do with the engineering components (how the art assets behave or interact) once the core mechanics have been proven (normally with wireframes or concept art).

•   Third, conflicting product ownership. The product ownership for art assets is typically owned by the Art Director, while the entire game is owned by a Game Designer or Executive Producer.

While there are many different ways to address this, and ultimately, every product team will experiment to find the way that works for their team, below is the story of one such team, and how they solved these challenges.

A well known US-based gaming company develops freemium games for handheld devices. These games are free-to-play with in-app purchases,  and designed specifically to be played online through mobile devices. One of their game teams, in the final stages of development, were developing against a tight deadline with high expectations on the team.

The team itself consisted of up to 25 developers (engineers, testers) and artists (designers, animators and audio engineers) responsible for bringing the final product together. Initially, the game team split into three Scrum teams, two engineering teams and an art team. While this worked well for the engineering teams, the nature of the work that the art team had to deliver (part concept work, part asset creation, part final asset delivery) fit poorly into a sprint. The art team felt pressured unnecessarily to follow a commitment to deliverables that didn’t match the reality of creative work.

The art team required constant review and approval by the Art Director, with a high chance of considerable change as the entire game design developed with time and functions such as audio or animation, were rarely needed until final assembly. It quickly became apparent that an art Scrum team was not going to work, and rather than persevering at the risk of losing the enthusiasm of the designers, the team was asked to come up with a different approach that had to work as well as or better than the current model. With some guidance, the team identified Kanban as a potential alternative, and decided to try it out.

There are four particular guidelines agreed with the team that enabled this to work spectacularly well.

1  The art team stayed as an art team, meeting every day around the board and sharing successes and learnings together at the Sprint Review. Art skills shared with other game teams were also included in the team meetings as necessary.

2  The Kanban board visualized all the asset work to be completed, and broke that work down into the different stages of development, from concept work to final art to animation to audio to final assembly and integration with the game. This helped team members support one another and stay focused to get a particular asset or deliverable all the way across the board.

3  Work on the board was prioritized according to the commitment of the two engineering teams. That is, the highest priority work was directly tied to the expected deliverables of the engineering teams during their sprints. The art team actively participated in the planning, refinement and standup meetings of the engineering teams, and tracked the dependencies between art assets and engineering stories. The aim* of the art team was to deliver completed artwork to the engineering teams during the sprint so that the Sprint Review included a truly shippable product increment, including engineering changes and complete artwork.

4  The team worked to a Definition of Done for concept work, and a separate, more rigorous Definition of Done for final assembly. This was required to make concept reviews consistent and meaningful, so that a minimum level of content was available.

*This was not a hard and fast rule. Sometimes, there was considerable amount of artwork to be delivered once the engineering was complete – for example, think of the levelling up artwork for a building with seven possible upgrade levels. Each level requires considerable creative work, but little or no engineering work.

The result of Scrum engineering teams working in parallel to a Kanban art team was a Sprint Review every two weeks that delivered a working game (shared across the studio for immediate feedback directly after the Sprint Review). The art team was much more comfortable without the constraints of the Sprint, and able to build their own team dynamics driven by the needs of the game that maintained a focus on deliverables for the game, rather than functional areas of responsibility.

Finally, UX work – designing gamescapes and in-game environments, continued to be delivered in close coordination with the engineering teams, building out concept work ahead of the engineering teams so that the engineering teams knew what to build when they needed to build it. UX work, like architecture, requires a runway. Design work needs to be completed ahead of the sprints in which the concepts are built by the development team. This provides enough time for thoughtful and thorough analysis and, where possible, feedback of concepts or prototypes, before providing the development teams with well-defined concepts to build into the product.

In conclusion, as the level of creative work on a product increases, the structure of the cross-functional teams creating the product becomes less ideal, less likely to follow a single cross-functional team. The creative work may need to split from the engineering work. In our case, the teams evolved how they worked to best suit the skills and temperament of the small, cross-functional teams involved. The guiding framework was a clear focus on the game increment as a final product. Although the art teams choose to work using a different method than the engineering teams, the regular cadence of review was maintained – a game increment produced every sprint that included completed artwork. This resulted in iterative and incremental deliveries, combining work from both Kanban and Scrum teams. Regular delivery of a game increment, not how each team worked, is the defining constraint

assorted notepads

The 2015 State of Scrum report

/by

The 2015 State of Scrum ReportThe Scrum Alliance just released their updated State of Scrum report based on their investigation of the industry. The survey uncovered findings that not only reflect where Scrum is today, but what we can anticipate it will look like tomorrow. These include who is practicing Scrum, how they are practicing it, success levels associated with Scrum, and plans for its continuing use.

Report statistics provide intriguing insights and information such as:

  • 87% say Scrum improves teams’ quality of work life
  • 81% believe certications improves the practice
  • On average, Scrum is successful 62% of the time
  • 95% will continue to use Scrum

The report is free to download from the Scrum Alliance site.

a picture of a cell phone and parts

Techniques for Breaking Down Technically Complex User Stories

/by

Breaking down user stories to fit into a few days of work and still deliver value is a vital component of Agile and Scrum. This is what allows the Scrum team to get fast feedback on the work they are doing to ensure it aligns with customer needs.

So what happens when the Product Owner can’t break down a story any further and it’s still too big to be manageable in a sprint? This creates a very difficult problem that the Product Owner and Development Team must work together to solve. 

In this post, we’re going to break down this user story:

As a data center technician, I want to be able to configure VLANs on a network switch from a web interface so I can easily make changes to any switch without being trained on the switch configuration process.

This kind of user story can be very challenging because there are a lot of complexities and unknowns contained within it. For example, the team might know that the switch must be configured through SNMP, but may have never used it before.

Looking at the Pieces

To start us off, we need to stop thinking about the story as a single thing and start looking at the pieces. So, let’s set aside worrying about value and user stories for a moment and break down the steps.

One great way to do this is to take a stack of sticky notes and have the team draw the steps in the process of the user story on each sticky note, then put them up on the wall. This lets the team quickly brainstorm the parts of the user story together. The picture below shows how this might look for our example:

sticky notes visualization

Notice that these stay very high level. The goal is not to create a detailed plan of how this will be implemented, but rather to create a visualization of what is involved with the story. A good rule of thumb is that the Product Owner should still be able to follow along with minimal explanation from the team. This will be important for the next step in the process.

It’s also important to remember that this doesn’t have to be perfect. If some of the steps are slightly off or missing, that’s ok.

Finding the Value

Now that the team has established many of the parts of the story, we can start looking for groupings with value. This is a collaborative conversation between the Product Owner and the team to identify what will add value and what will be technically plausible.     

Grouping tasks

You can see that a few things came out of this conversation. We’ve grouped the display of switch data into one story and the configuration change into another story. We’ve also de-scoped some of the steps. The caching has been set aside, and the Product Owner understands the performance impact that has. 

We also decided that testing the change could be very complex and agreed that a simple validation would be sufficient for technicians to safely use the software, but we might keep another story in the backlog for something more robust later.

Finally, the conversation led us to realize that there might be some additional work around selecting which switch to manage as well as supporting multiple models and manufacturers. This functionality has been moved to other stories in order to provide a more manageable scope for the read and edit stories.

A Different Way to Look at Value

It is very common for teams to become accustomed to looking at value as a full feature that you can package up and sell to a customer – complete and production-ready. While not unreasonable (and not always wrong), this mindset can sometimes make it difficult to break down these kinds of stories. 

If we look at the Agile Manifesto, we don’t see any references to terms like “production-ready” or “sellable”. Instead, we see terms like “working software” and “collaboration”. So when we look for a story to have value, we want to see that we’ve created working, functional software and that it helps us collaborate with our customers and users and helps us learn something about the software we’re creating.

If we look at our groupings above, we can see that none produce documentation, mock-ups, or processes as their deliverable. For example, if we took on the update story first, we would have a simple interface that actually updates the VLAN on a given switch. This doesn’t solve the whole problem, but it lets us put real software in front of the users to see how they use it. In doing so, we may find that the user wants to see what VLANs are already trunked to the switch to select from. This not only tells us that we need an enhancement to the work already done, but it may also influence how we collect and store information from the switch in our “read” story.

Conclusion

Through this process, we’ve turned one large, complex story into five much more manageable stories:

  • As a technician, I’d like to see the current switch VLAN configuration.
  • As a technician, I’d like to be able to save new VLAN configurations from a web interface.
  • As a technician, I’d like to be able to select which switch I am managing.
  • As a technician, I’d like to be able to manage multiple switch manufacturers and models.
  • As a technician, I’d like any automated changes to be validated with robust testing.

All of these produce valuable, working software that helps us collaborate with our customers. They are now ready to be prioritized in the backlog and worked through just as any other user story.

 

Bent Myllerup interview on the role of Scrum Master

/by

During the talk with Marko Keba he answered to far-fecthing questions like “What are the main qualities of a good Scrum Master?”, “What does listening really mean?” and “How to take decisions effectively?”. The video can be watched here below or on YouTube.

book lot on table

Thesis about the Scrum method as used by agile42

/by

Last month, Inga Geitmann’s thesis, “The Scrum Method as an Instrument of Lean Management and Their Implementation,” was published and is now available all over the world… here is a small summary:

“It ́s necessary to optimize working processes because of the economical benefits and it increases the lastingness of resources and working overhead. Methods especially in the software development were created to help organizations increasing their output while reducing costs. This is out of the economical principle where the idea is from to produce the highest output with less input. The scrum method is an agile method out of the lean management and was created by Toyota. This method was taken over and adapted from the car industry to the software development. Today a lot of big companies work agile with scrum. The increasing trend of using scrum and other agile methods shows the demand of reducing costs in times of uncertainly financial markets. The implementation of scrum through agile42.com within a customer shows the empiric way how this works.”

Check here for more information and to purchase the book online.

stainless steel tool on gray sand

Kanban and Scrum

/by

In August last year Gartner signalled the death knell of Waterfall. All the evidence over the last 25 years points to some form of Lean-Agile method as the only sensible way forward for managing knowledge work. Kanban and Scrum (together with eXtreme Programming) are the pre-eminent Lean-Agile methods. I would argue that any investment you make in learning these will be the best investment you can make for your career and also the best investment your organisation can make in ensuring business sustainability in the long-term.

You might think it strange that a company named Scrum Sense would talk about Kanban. The truth is that Kanban was a baby in diapers when Scrum Sense started, while Scrum was already the de facto standard in the Agile world. When Maritza van den Heuvel approached me in November 2009 about the possibility of hosting David Anderson in Cape Town I jumped at the opportunity. He visited early in 2010 and we had a great time exploring this new process with him. We learned a lot and I’m tempted to say that we also helped clear up some mis-conceptions about Scrum.

Three years have passed and Kanban now has a significant presence in the Lean-Agile world. The latest worldwide Agile survey places Scrum and Scrum hybrids (most commonly Scrum + XP) first with 66% of the Agile market and Kanban second with 24%. Impressive growth in just about 5 years. Why is this?

As usual, there are some good and some bad reasons. Let’s start with the bad. Many organisations that attempt to ‘do’ Scrum are not actually willing to make the adjustments to their ways of working, ways of managing and company culture that are needed to realise the hoped-for benefits. Scrum is not the silver bullet they hoped for. So some look for the next shiny thing…and discover Kanban. By now, a number of these organisations have also dumped Kanban in search of something easier. One client of mine who did this has largely gone back to Scrum.

There are good reasons too. I see organisations trying to use Scrum to manage work that is really not complex, sometimes repetitive and whose arrival rate is highly variable. Not conducive to being planned in week- to month-long fixed increments. Much more suited to being handled using clear policies and SLA’s.

By now you are asking yourself what the differences are between these to Lean-Agile methods, and where to use what. This is, naturally, a non-trivial question. A good starting point to seek answers is Henrik Kniberg and Mattias Skarin’s free mini-book.

My message is this: if you want to be equipped to make good decisions in the future Lean-Agile world you need to educate yourself in both Scrum and Kanban. And along the way you will realise that you need to develop your so-called “soft” skills and learn how to manage organisational change too.

aerial photography of people

Tips for the beginner Product Owner: How many PO?

/by

Basically, this article is about why it is a bad idea to try to counter a dysfunctional situation by adding more people to the job.

A phenomenon that I encountered often is that companies tend to hire more Product Owners when their setup with one does not seem to work. Can the reflex to just hire more people when the existing ones are not doing what is expected from them help?

Before we take a deeper look into what can go wrong, let‘s summarize how it should be. The three main qualities of a PO are:

  1. Availability
  2. Knowledge
  3. Authority

The Product Owner needs authority. When he says something and gives information to the team, that should be valid and hold. If he cannot say anything because either he does not know or is not allowed to make a decision, this is a major dysfunction.

In order for the Product Owner to make a decision, he needs to be knowledgeable. He needs to know about the product and the product domain. He needs to understand his customers for whom he is building the product, so he needs to be in contact with them. Without knowledge, his authority will not hold and he will lose the ability to make decisions.

And finally, he needs to be available for the Team Members and Scrum Master if they have questions. As well as for the stakeholders when they bring new ideas to the table or have concerns. The best PO is of no use if he is not there to answer a question.

All these qualities enable the PO to optimize the Return on Investment, for which he is responsible. Being responsible also means (apart from the burden) being able to act or decide on one‘s own without supervision. If you are dissatisfied with the work of your PO, the first thing that you should look into is: Is your PO really empowered and can she ultimately shape the ROI? Does she have the tools, like a clear product vision and business values attached to product backlog items? Is the team stable and is she the only channel from whom the team can pull product backlog items?

Often occurring problems after a transition to Scrum is that there are still managers that give direct tasks to members of the team, overrule the decision of the PO or do not really allow him to make decisions. Often, the PO is not allowed to talk directly to customers and stakeholders, so someone else becomes the main source for information that the PO depends on. Lastly, another problem is that the PO is not solely a PO but also responsible for a multitude of other tasks, reducing his availability and focus on the product.

If one of these things is happening, it does not matter how many people are sharing the PO position, it will not get any better.

Normally, one PO can deal with one Team (5-9 developers). Under rare and complex conditions, it might be a good idea to give him a business analyst as an assistant, but at least as often, a PO might also be able to deal with two teams at once. By adding more POs to the job, you dilute the ideal „one face to the team“. If the Backlog is set up as suggested and the team is following the Scrum rules, this will work out.

So before you decide to add more people to the PO position, think about how it could help and if there are no other dysfunctions that need to be solved if your PO tells you that he is overloaded.

Conditions, where it is a good idea to put more POs on the job for one team, is when you have a lot of „disruptiveness“ of the business and have to work out different „branches“ of strategy or be prepared for quickly opening opportunities. Another one may be a highly complex outside world with many different stakeholders that you need to care for. When you should do this, keep in mind that you need a shared responsibility for the ROI and a clear distinction of who is responsible for what.