Author Archives: Yuval Yeret

About Yuval Yeret

Kanban/Agile Consultant at Agilesparks

Implementing the Scrum Master Accountability – Organizational design/Leadership Considerations

Estimated Reading Time: 5 minutes

The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization … Scrum Masters are true leaders who serve the Scrum Team and the larger organization” 

(The Scrum Guide)

As we discuss in the Scrum Guide and Professional Scrum Master classes, Scrum Masters should be able and be positioned to facilitate, coach, teach, mentor, point north, take action or even actively do nothing. 

That’s the theory at least. In reality, most SMs fall into two categories:

  • The Disempowered – acting as Scribes/secretaries/clerks for their teams – accountable for the Scrum mechanics but not to the team’s effectiveness, definitely not able to coach/influence the ecosystem around the team – because of their abilities/experience and/or how they are perceived/positioned. 
  • Traditional managers with a new name – people managers, project managers, tech leads, team leads – who continue to manage/lead how they’ve always done it. They are considered the team‘s focal point. They feel the full burden of delivery and results on their shoulders. They often resort to heroism and command and control – whether because that’s their comfort zone or because they feel they are expected to. 

Problematic implementation of the Scrum Master accountability can really interfere with the journey towards agility, empiricism, and self-management. Leaders need to figure out how to create effective Scrum Mastery / Leadership in their organization. Here are some considerations to think about: 

  • Who will have the accountability – The Scrum Guide describes Scrum Master as an Accountability which means that it’s not necessarily a distinct job title, and even if so the actual job title might not be “Scrum Master”. Designing how to map the Scrum Master accountability is a crucial step in implementing Scrum. The conversations around it are usually tough and revealing. 
  • One specific question that leaders should consider – should Scrum Mastery be an accountability of leaders/managers? Many agile practitioners will warn that this will interfere with the team’s ability to self-manage. On the other hand – the Scrum Master accountability describes a “Leader who serves” and is a key leadership accountability in an agile organization. 
  • Measurement – By putting the right measures in place, a leader can clearly define the outcomes they are looking for. Is the Scrum Master accountable for the delivery of value? Effectiveness of the Team? What else? Deciding the right measures is often difficult and can become political, especially so for enabling accountabilities such as the Scrum Master. 
  • Reporting Structure – Setting the Scrum Master up for success means figuring out a reporting structure that enables the Scrum Master to be honest and open with minimal risk of repercussion. For example, If the person owning the Scrum Master accountability reports to the Product Owner, it might make it hard for them to be honest and open about their challenges. If they report to the same people as the Developers, there might be a lack of understanding of their role. A Scrum Master that’s outside the Scrum Team’s reporting structure coming in as either an internal or external “consultant” provides certain benefits but carries certain disadvantages. 
  • Where Scrum Masters come from – Often organizations naturally think that Project Managers should be the place Scrum Masters are recruited from. Project Management is a different, somewhat overlapping set of skills that may or may not house good Scrum Masters. Leaders should understand the Scrum Master accountability and open a wide aperture to find the right people for the role wherever they are in the organization. Sometimes, the right Scrum Master for the job is found by looking at the mirror…
  • Employment Status – Each situation is different, but deciding whether the Scrum Master is better served as an external contractor or an internal employee requires some level of thought and choice. Both approaches have merit. Think of the courage the Scrum Master might have to “speak to power”. The openness people in the organization and team would have to listen to their ideas. The commitment the Scrum Master would have to the team and the organization. The respect they would garner from the Product Owner, Developers, Leaders, and Stakeholders. And how much they will be able to focus on helping the Team. 
  • Career path – Scrum Master isn’t necessarily a career path. It’s an accountability that requires certain competency. Having said that, Leaders looking to find great Scrum Masters for their teams need to figure out as well as provide transparency to how taking on the  Scrum Master accountability would support people’s career growth. 
  • Creating an open/transparent relationship between the Scrum Master and the Leader – Leaders need to partner with Scrum Masters on addressing systemic impediments that limit the organization’s potential. Scrum Masters should feel safe providing feedback about the Leader’s own behavior and organizational choices. 
  • Teams Supported – Depending on the maturity of the teams, the complexity of the problems they are solving, or the constraints of the situation the Leader must decide on how many Scrum Teams the Scrum Master supports. Leaders in many cases face the tradeoff between having a few passionate and effective Scrum Masters covering multiple teams, versus having a Scrum Master for each team that is also a Developer on that team and sees Scrum Mastery as their secondary accountability. Again, no clear choices here, but aim to have Scrum Masters who are passionate about Scrum Mastery and see it as a key part of their career journey. 

There’s no one right answer or best practice for any of these considerations. Leaders need to apply empiricism to figure out these sorts of complex dilemmas. This means trying out a certain pattern, inspecting its impact, and amplifying or pivoting away as needed. These “experiments” involve human beings, making them even more complex and sensitive. 

Having said that, An emerging pattern I’m seeing more and more often is implementing the Scrum Master as an accountability of people managers/leaders – in alignment with a mindset/culture of “leaders who serve”. This is often complemented by a small set of experienced professional scrum masters / agile coaches that provide enablement/support and on-demand deeper scrum mastery when needed. This setup meets the organization and people where they are while providing a “north star” for how leadership in the organization should look like and supporting the journey. 

Are Scrum Masters here set up for success? Are they “leaders who serve”? Which of the Professional Scrum Master choices/stances can they choose from? Are they a core aspect of our organization’s approach to leadership/management? Are they an afterthought to get a higher score on an agile maturity assessment or some RFP? Are they respected, and appreciated by the people they serve? Are they in high demand? 

To sum up – Implementing the Scrum Master accountability effectively is hard. It ties straight into the creation of servant leadership and a self-management/empowering culture in which business agility thrives. As agile practitioners we should have some empathy to why organizations and leaders are struggling with this. As leaders we should engage the agile community inside our organization and beyond it to work on figuring this out. 

Check out the Scrum Guide Companion for Leaders whitepaper for more scrum leadership perspectives.

A Kanban for Marketing Board Example

Estimated Reading Time: 1 minute(originally posted on the agilesparks blog)

Here is an example of a fairly typical Marketing Kanban board which can be useful for marketing teams that are taking their first steps towards implementing agile marketing in practice using kanban.

You can print it out and use it as a source of ideas & inspiration as you evolve your own board.

It is a slightly modified version of Henrik Kniberg’s Kanban Kick-Start Example that he graciously shared using a creative-commons license. Why do we need a marketing version you ask? Because we find that people connect better to examples in their own domain so talking about code and development doesn’t really work well with marketers… Feel free to take this one and adapt it for your use and share alike! (Here’s a powerpoint version you can edit)

PS Interested in learning more about how to use Kanban in Marketing? I talk quite a bit about Kanban including help marketers create their own Kanban boards in my Agile Marketing class. Next opportunity to take the class publicly is July 24-25 in Boston. This class is also available in-house where it’s possible to really get a Kanban board going and ready for action…


SAFe Configurations

Estimated Reading Time: 5 minutesI just shared my perspective that SAFe isn’t a hard-coded methodology and while it gives you a comprehensive and to some even overwhelming set of practices, there are still a lot of choices.

My old friend Sutap suggested: Would be great if you can share examples around how SAFe is not a one size fits all framework. Examples/ case studies will really help. From experience, enterprises typically have very different projects: from large programs running for years with say once in a quarter releases (say customer A) to enhancement requests released very frequently (but unsteady pipeline: say customer B) to fixed scope fixed timeline regulatory projects (customer C). Would love to hear how SAFe will handle such (and maybe many more) scenarios.

(Sutap and I worked on a scaled agile transformation in one very big enterprise where we saw all of those and more …)

So here are a couple of examples/case studies, some real and some semi-real. I’m not trying to explain every concept I mention here as the goal is to portray the optionality, not teach you SAFe. (If learning SAFe is your goal, come to an Implementing SAFe class or go read SAFe distilled…). without further ado – here goes:

When an enterprise like this implements SAFe they would probably have different Agile Release Trains (ARTs) for each one of those programs. All those ARTs would work on a Program Increment (PI) cadence like all Scrum teams work on a sprint cadence. But each of those ARTs might have a different style of PI.

The ART serving Customer A might naturally have a quarterly PI. The ART serving Customer B might have a quarterly PI or maybe a shorter 8-week PI or maybe even shorter (yes – despite the fact that SAFe says 8-12 weeks! herecy!).

The ART serving Customer C might have a quarterly PI. A would release every quarter. B might release every iteration, C might release to production only every 2-3 PIs.

The Program Kanban for each of them might look different to reflect the different budgeting/analysis/governance mechanism each customer uses and the different “road to production” downstream from development. For one customer a 3rd party SI might have developers/testers on the feature teams with the enterprise. For another customer it might be hard to integrate the SI’s people into the agile teams so a combination of internal Feature teams and a few Component teams with people from the SI might be the right approach at least initially. In other cases the SI might not even be willing/structured to collaborate at this level and would be considered a “Supplier” at the Value Stream level.

The infrastructure the enterprise has for customer A might be advanced enough that Continuous Integration (CI) exists and there’s no need for a System Team. For Customer C it might be too early and the System team is needed both for performing the integration as well as starting to figure out how to achieve CI. Maybe in Customer C the System Team is just focusing on improving the CI and is also working on achieving Continuous Deployment capabilities (CD). In Customer B it might be the case that there’s both a System Team and a DevOps enablement team each focusing on different stages in the delivery pipeline.

PI Planning itself might look different. The level of predictability needed in A is high and the backlog and ART  are stable enough to enable it so PI planning is pretty classic. In B it is not THAT important and actually much harder to achieve so PI Planning focuses more on main dependencies and projects saving significant capacity for emerging enhancements throughout execution while using PI Objectives to make sure the business and the ART are aligned on which enhancements to focus on as they emerge. In C due to the fixed scope fixed timeline the backlog SHOULD be even more stable than A and we would probably spend more time on estimating the features in the Program Backlog and building a roadmap to see whether we have a converging plan or need to invest more resources. Even earlier in this type of project, when doing the portfolio-level business case for this sort of epic we would need to do more analysis and estimation than for epics for customer A. And the features for customer B might actually not have any Program/Portfolio Epic above them.

For customer C it might make sense to have one roadmap for the 3 ARTs working on the project. For customer A it might make sense to have separate roadmaps since each ART is working with a separate business “tower”.

Here are a few other examples from other contexts:

  • How to deal with multiple small value streams – sometimes it makes sense to aggregate them into one Agile Release Train (ART) – especially when you want to be able to have one Program Backlog in which you prioritize those two value streams against each other and allow the ART to focus on a specific value stream/product for a while. Sometimes it makes sense to actually have a few smaller ARTs even if they are really small to the point of being mini-ARTs – in case the investment/funding for each value stream is quite stable/separate and the teams working on the different products are separate as well.
  • Should a critical core technology group that is common to multiple products be considered a separate ART? Should the different products and this core technology group be on the same Value Stream (VS) level to allow coordination in Pre/Post PI Planning? Should the products be in different VSs because that’s the only connection? Should this group be split into teams that each join a different ART? Sounds like the right “Agile” move but on the other hand what if prioritizing what this core technology group works on across the different products is a key portfolio-level decision? if so, having a team per ART actually decentralizes control of this key resource TOO much.
  • For some ARTs pair-working would make sense 20% of the time. For other ARTs that are currently scaling up their capacity by bringing in more people (Think the program working for customer C which just found out they need to add 3 more teams over the next PI to deliver the fixed scope project on time) they might go into pair-working 80% of the time initially to accelerate knowledge sharing and then go back to 20%.
  • In some cases the Scrum Master will be a technical lead inside each Agile Team. In other cases they will be one of the Managers working with the ART each covering 2 teams.

Enough questions, configurations, and options? I think so…

It would be great to have “one size fits all” for all of those. And maybe you can find some SAFe consultants that would tell you that’s the case. The good ones will at least make sure you understand there are open questions and multiple options. The best ones would be able to share from their experience what worked where, the upsides and downsides, and be able to help you figure out what configuration to try as well as guide you in inspecting and adapting on your way to figuring out the SAFe configuration that’s best for you.


Musings about “Hard-coded” Frameworks

Estimated Reading Time: 2 minutesA recent discussion on the Scrum Alliance Linkedin group was around Mike Beedle’s claim that “Hard-coded Frameworks are neither Agile or Frameworks” which is clearly aimed primarily at SAFe.  

I admit to thinking something similar before really getting to know SAFe in depth. Over time I realized SAFe isn’t one size fits all. Far from it. 

It has many configurations and options. Do we need the Value Stream level? a System Team? at which level? How many ARTs? Component teams or Feature teams? Which metrics? Which ART to start with? Even if you don’t follow my Invitation-based SAFe implementation approach that is now a formal SAFe guidance article, you still have a lot of options at all levels and it is hardly a hard-coded methodology. Yes, not all practitioners understand this. But that’s a familiar problem from the Scrum space isn’t it. “Though shall do tasks”. “Though shall estimate in story points using planning poker”. “Though shall stand up in the Daily Scrum”.

Scrum was and is a powerful tool. SAFe, Enterprise Scrum, Nexus, LeSS, Kanban and others are powerful tools as well. A powerful tool is typically also dangerous at the wrong hands or the unexperienced hands without good guidance.

Besides – it IS funny to hear about the danger of force-fitting a hard-coded framework from leaders in the scrum community that have been telling us about SHU and following practices and the danger of scrum-but all along. And rightly so! Sometimes you do need to insist on a practice/change even if it feels hard! Agile IS about challenging your comfort zone.

Can we all agree that the real art/expertise is to figure out the right set of practices that is the goldilock between too much force-fitting and too-easy “common sense that is somehow too close to the status quo”?

(Updated) Oh – and also can we also agree there’s a huge difference between force- fitting practices to challenge your comfort zone (which is healthy change management done right) and forcing people to do something vs inviting them to consider trying it? 

Agile Marketing Validation Board

Estimated Reading Time: 2 minutes

 “Validated Learning Over Opinions and Conventions”

A couple of weeks ago I was helping kickoff a team of 8-10 Agile Marketing teams. The kickoff spanning a couple of days includes:

  • Agile Marketing training
  • High level planning of their first quarter
  • Iteration planning for their first agile iteration

While doing this I saw some gaps between the training and the actual planning around the whole validation/experimentation/learning thing. In other words the difference between increments and iterations.

It’s not iterating if you’re not inspecting and possibly adapting along the way.

Taking a big campaign and breaking it into small tasks and planning two weeks at a time is one step towards Agile Marketing.

Running demos to show what you’ve accomplished and daily scrums to help manage the progress is a second step.

That’s just a glimpse of what Agile Marketing is really about.

This is why when we got to high level planning I felt something was missing from how the teams were planning. They were working on an MVP BOM – A Minimally Viable Program Bill Of Materials describing the minimum aspects of the campaign/program they were focusing on.

It was a good start to focus on smaller more minimal programs/campaigns and working incrementally. But I felt the iterative/learning message was missing from the discussion once we moved from theory to practice.

Let’s Use A Lean Startup Validation Board

At that point I recalled the “Lean Startup Validation Board“. I first learned about the Validation Board and practiced using it as a mentor in a “Lean Startup Machine” event back in Tel Aviv. It is a practical hands on planning tool that focuses you on what you don’t know and need to learn.

Lean Startup Validation Board

In the classic Lean Startup context it should help you in your search for a Product Market Fit. You start by identifying your hypothesis around who are your potential customers, what’s the problem you think they have, and what solution might fit their need. You then try to think what are your core assumptions that would need to be true in order for all your hypothesis to be true.

It’s all about risks

You then look for the riskiest assumption – the one you feel might be the first one to bring your house of cards down. Then you structure experiments/validated learning around that. If your experiment validates your assumption you move to the next assumption. If it invalidates it you need to pivot to another set of hypothesis’s and start the core assumptions validation process again.

Is This Product Management Tool Good For Agile Marketing?

Mostly, yes! The minimum tweaking I would do is to change from “Solution Hypothesis” to “Marketing Solution Hypothesis”. When I say Marketing Solution I include things like channel or message.

An example of a channel hypothesis might be – “we think that Snapchat can be a useful marketing channel for us”. A messaging hypothesis might be “During a snow storm people would really connect to messages regarding vacations in warm places”. 

After Finding Product Market Fit – Search For A Streamlined Customer’s Journey

An Agile Marketing team is many times focused on scaling/growing revenue (After Product Market Fit was already found/established). So these teams are focused on finding new creative ways to reach more people in the identified market and optimizing their customer’s journey.

So if you’re serious about Agile Marketing, don’t just plan tasks. Plan experiments aimed at validating assumptions. Plan to learn. Plan to iterate.