Tag Archives: training

9 Ways to Identify the “Perfect” Scrum Master

May 8, 2019 Mishkin Berteig 3 Comments

Preamble

Is there such a thing as a perfect Scrum Master? Likely not, because of course we are all human and not perfect beings. However, we can make a case for skills that contribute to becoming a perfect Scrum Master.

In 2017, Ken Schwaber and Jeff Sutherland updated the Scrum Values document, and in a video that same year discussed the changes they were making. They talked at length about the Scrum Master role. To quote Ken Schwaber, “It’s a very tough job”.

The 2018 new Scrum Guide states:“The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide”.

In short, the Scrum Master (SM) serves the Product Owner, the Development Team, and the Organization. This involves facilitating Scrum events, coaching and educating, removing impediments, and much more. It is safe to say that successfully undertaking those relational interactions requires good people-oriented behaviours, or soft skills.

We may not normally think of Scrum Mastering in the same breath as soft skills, but a discussion lead me to consider this. A colleague stated that a good Scrum Master must understand 4 things: the business s/he works in, the technology s/he works with, Agile and Scrum principles, and, most importantly, people! Based on his experience, he was adamant that Scrum Master certification is not enough – that soft skills should be part and parcel of their training.

How can some of these soft skills be taught?

The Certified Scrum Master Training

The first thing a CST can do is model soft skills in his/her training class: treat all the attendees with respect, be clear about the goals of training, listen and be attentive to questions and concerns, create a safe learning environment, demonstrate honesty and trustworthiness. Modelling these behaviours is one way a CST can teach without words.

But in two days, is role-modelling enough? Let’s look at the Scrum Guide for clues. “When the values of commitment, courage, focus, openness and respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone.” http://www.scrumguides.org/scrum-guide

How much are these values discussed in training? What does “courage” or “openness” look like? In-depth discussion, with examples/activities of each of those values/ skills, could go a long way in teaching soft skills.

Scrum Masters can be guided through specific exercises that help them understand and practice the Scrum Values of courage, openness, respect, commitment, focus. As well, specialized skills can be taught, including leadership, negotiation, conflict resolution, compassion and more.

I recommend a video called “Agile and Scrum Soft Skills Needed to Drive Process Success” which provides helpful guidance:
https://www.youtube.com/watch?v=owa1fftIfzA&t=7s

9 Best Skills for the “Perfect” Scrum Master

After polling the readers of the REALagility Newsletter, I’ve put together this list of skills that many of us believe every Scrum Master should strive for:

Listening well – to your team, your organization and especially your stakeholders
Empathy, friendliness and respect – builds a collaborative culture
Trust – you do what you say, walk the talk, and create safety
Openness and transparency
Identify and help solve problems
Create a learning environment – for continuous learning and improvement
Show courage – remember Schwaber’s “It’s a very tough job!”
Support team, team members, PO and CEO! – why the CEO? S/he has to be on board with the changes and growth.
Be service-oriented/team-first attitude – it’s not about you; it’s about serving the people and the process. This is why Scrum Masters are often called “servant-leaders”.

Post Script

Additionally traits that readers added: “Altruistic”, “has humor/fun-loving”, “proactive”, “easy-going & strict”, “can cheat”!

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!

agile teaching, agile training

The Art of Agile Learning Events 101: Thoughts on Good Teaching

November 3, 2017 Mishkin Berteig 1 Comment

Teaching is an art form. Good teaching requires the softer personal skills more than hard facts and knowledge. In fact, great teaching requires consistent learning on the part of the instructor. That’s part of being agile. Every class and every new group of students, whether you’re teaching Scrum, SAFe or Kanban, is an opportunity for a teacher to learn and perfect his/her art.

The points discussed here are not an exhaustive list; they are a starting point for anyone struggling with figuring out how to train/teach anything agile – or anything, for that matter!

First impressions go a long way, so be at your best. Smile and warmly welcome your participants. Smiling helps people feel more comfortable. Try to make eye contact with as many as possible. Your introduction should be energetic. It’s a lot like writing a short story or news article – the reader’s attention has to be captured in the opening lines, or the story goes unread. When you are teaching, it does not matter if you happen to be tired or had a fight with your spouse. Participants have paid to be there, and no matter what your personal circumstances are, you are there to deliver.

It’s a given that you know your subject and you know what to cover in the class. Do your best to state important ideas and principles with clarity. The essence of teaching and learning is communication. Consider this statement:

“One of the chief attributes of a great teacher is the ability to break down complex ideas and make them understandable.”https://www.fastcompany.com/44276/attention-class-16-ways-be-smarter-teacher

Recounting relevant stories is one way to illustrate complex ideas, and the more personal your story is, the more effective it will be with your listeners.

How do you respond to tough or challenging questions? The same web article continues with this thought: “Sometimes the best answer a teacher can give is, ‘I don’t know.’ Instead of losing credibility, she gains students’ trust, and that trust is the basis of a productive relationship.” Acknowledging what you don’t know shows that you’re still learning. No one is perfect or knows everything, and the more you can be yourself, the more relatable the students will find you. Remember, too, that teaching is a dialogue, so listen carefully to your students when they have a question or comment.

Since you don’t need to be worried about not knowing all the answers, that gives you more opportunity to use humour, even to laugh at yourself, if it’s warranted. The Canadian Humber Centre for Teaching and Learning places great emphasis on this aspect. Humour is ranked as one of the top five traits of effective teachers. Laughter helps everyone relax, even the instructor, and gives the learning experience a more agile feel. Laughter definitely enriches the learning experience.

Be passionate about what you are teaching. Expertise is not enough. Passion is infectious, like a fever that your students can catch. When you care about your subject, your students will also care. Your passion also helps you change up the rhythm of your speech, so that sometimes your speech will be more emphatic, and that helps create focus in certain areas of your content and greater interest overall.

Now for the gold: it’s not about you; it’s about them. Your focus should be almost 100% on your students (and you will improve as a teacher as a result). Certainly the material you’ve prepared is important, but your preparation should be such that your awareness need not remain there. Be aware of every response; read body language constantly. Keep them with you every step of the way. If you love what you’re doing, and make every effort to communicate, you will not be concerned whether you yourself are doing well; you will be concerned that THEY are doing well. This is the best secret to good teaching, and will enable you to learn so much from those that have come to learn from you.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!

Uncategorized

Using “Status” in Agile Coaching & Training

January 9, 2017 Mishkin Berteig 5 Comments

Recently after attending a Scrum Alliance webinar on “Best Practices in Coaching,” I was reminded of my experiences teaching Acting students at university, and how I used changing status to help them achieve their best.

Status refers to the position or rank of someone within a particular group or community. I believe it was Canadian Keith Johnstone who introduced the idea of “playing status” to theatre improv teams. It is used to create relationships between characters onstage, and to change those relationships to move a story forward.

Status can be indicated through position, posture, facial expression, voice and clothing. It is a fascinating tool for any trainer or coach to use.

At the beginning of a semester with new students, I would invite them to sit on the stage floor in a circle with me. I would welcome them, discuss my expectations of their learning, and tell them what they could expect from me. We’d go over the course syllabus and I’d answer questions. I purposefully put myself in an equal status to them, as a way of earning their trust, because the processes of acting* requires huge amounts of trust. I also wanted to establish a degree of respect in them for the stage by all of us being in a “humble” position on the stage floor.

However, when I would introduce a new exercise to them that required them to go beyond their comfort zones, I would deliver instructions from a standing position while they were seated. By elevating my status, I conveyed the importance of the exercise, and it was a signal that it was not something they could opt out of. In this way, I could help them to exercise their creativity to a greater extent.

Another way I encouraged my students to take risks was to take risks myself. Sometimes I would illustrate an acting exercise by doing it myself first. For those few minutes I became a colleague with my students, one of them, equal in status. If I could “make a fool of myself” (which is how it may look to an outsider), then they could too.

I had one student who had great potential, but who took on the role of class clown and would not give it up. He fought against going deeper and getting real. One day in an exercise where they had to “own” a line of dialogue, I had him in a chair onstage, while I and the rest of the students were seated. He had to repeat the line of text until it resonated with him and became real. After some minutes, nothing was changing in him. In desperation had him turn his chair around so his back was to us. I then indicated to the other students to quietly leave the room. He could hear something happening but was confused about it. He was not able to turn around and look.

When I allowed him to turn around it was only him and me left in the theatre. I had him go through the repetition exercise again. Without an audience, and with me still seated, he finally broke through the wall he had erected and connected with the line of text from his inner self. It was a wonderful moment of truth and vulnerability. I then allowed the other students back in, and had him find that connection again with the students there. He was able to do it.

He is grateful to me to this day for helping him get beyond his comfortable role as clown to become a serious actor.

When training or coaching, it seems to me there can be huge value in playing with status. Sometimes taking a lower status, an equal status, or a higher status, can move a team or upper management into discovering whatever may have been blocking the process. Again, there are many ways to indicate status and even a status change to effect progress.

In his book, “Improv-ing Agile Teams,” Paul Goddard makes some important observations about using status. He writes: “Even though status is far less obvious than what is portrayed on stage, individuals still can take small steps to encourage status changes within their own team. For example, asking a team member who exhibits lower status behaviours to take ownership of a meeting or oversee a process not only boosts that person’s confidence but also increases status among peers…these subtle actions can help make lower-status team members feel more comfortable when expressing new ideas or exposing hidden problems.”

A colleague reminded me of a 1975 publication called “Power: How to Get It, How to Use It,” in which author Michael Korda gives advice about facial expression, stance, clothing and innumerable ways to express “power.” The idea of using status in the context I’m writing about is not about gaining power, but about finding ways through one’s own status changes to help unlock the capacity and potential of others.

How can a coach use status to help someone in management who is blocking change? Is someone on a team not accepting what others have to offer because s/he is keeping his/her status high? Is a Scrum Master necessarily a high-status team member, or rather a servant to the team (low status)?

I am curious if any coaches or trainers out there have used status in a way that created growth and change.

*Good acting is a matter of the actor finding the truth in oneself as it relates to the character he or she is playing. It requires vulnerability and courage to step out of one’s known persona and take on another as truthfully as possible. Inherent truthfulness also applies to work in any other endeavour.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!

Links to Agile Info

Link: The Cost of Turnover on an Agile Team

October 26, 2015 Mishkin Berteig Leave a comment

Great article by Mike Griffiths: http://leadinganswers.typepad.com/leading_answers/2015/10/agile-talent-management.html

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!

Agile Management, Links to Agile Info, Professional Development, Reference Information, Scrum, XP and Lean

Nexus Reifies

June 10, 2015 Mishkin Berteig Leave a comment

Nexus Scrum

I had the privilege of attending Scrum.org‘s 2-day seminar on Scaled Professional Scrum. The Nexus, a connection or series of connections linking two or more things (direct translation from Latin a binding together), is the recommended scaling framework. The purpose of the Nexus is to manage dependencies between 3-9 Scrum Teams towards “reification”, to make an abstract idea real or concrete. This is ensured mostly through a single Product Owner, single Product Backlog, integrated (Nexus) Sprint Planning, Review and Retrospective and the addition of a Nexus Integration Team whose membership is made up mostly of Scrum team members internal to the Nexus, but often also includes other support personnel. The structure is very similar to LeSS, but perhaps even less prescriptive and is certainly much less prescriptive than SAFe. This is probably my favourite thing about the Nexus – the fact that it has just enough structure to be a model for scaling Scrum, but is light and flexible enough to accommodate all of the nuances that “just depend” on your situation. Like the other two above-mentioned scaling models, it places emphasis on the need for strong technical practices, continuous integration and the synchronization of events to facilitate integration. There is flexibility around synchronization, in that if the Nexus Sprint is 4 weeks in duration and teams within the Nexus want to do 2 or even 1 week Sprints, the model accommodates – as long as all of the teams’ work is combined into a fully integrated (reified) increment of potentially shippable product by the end of the Nexus Sprint.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!

Theory of Agile

The Agile Manifesto – Essay 3: Working Software over Comprehensive Documentation

June 2, 2015 Mishkin Berteig Leave a comment

How much documentation does it take to run a project with ten people working for six months? For some organizations it takes way too much:

Photo of heavy documentation for software project

This binder (about 3 or 4 inches thick) is all the documentation associated with such a project. In looking carefully at the project, creating the documentation took far more time than the time spent on designing, writing and testing the software. Yet, the documentation does not produce any value. Only the software produces value. The Agile Manifesto, asks us to focus on the outcome (working software) and to make tradeoffs to minimize the means (comprehensive documentation).

The Agile Manifesto asks us to challenge our assumptions about documentation. In many work environments, documentation is an attempt to address some interesting and important needs:

Knowledge sharing among stakeholders and the people working on a project.
Knowledge sharing across time as people come in and out of a project.
Verification and traceability for contracts or other compliance needs.
Decision-making and analysis for business and technical problems.
Management oversight and control.
Various aspects of individual accountability.

Documentation is usually heavier (more comprehensive) the more the following circumstances exist in an organization:

Geographical distribution of people.
Lack of trust between people, departments or organizations.
Regulated work environments.
Depth of management hierarchy.
Number of people directly and indirectly involved.
Knowledge and skill sets highly segregated between people.
Culture of respect for written texts.

Working Software

What if the software itself could address the needs that often documentation is used to address? Let’s look at them in turn:

Knowledge sharing among stakeholders and the people working on a project.
If the software is functional at all stages, as supported by Agile methods such as Scrum and Extreme Programming, then the software becomes an effective representation of the knowledge of all the people who have participated in building it.
Knowledge sharing across time as people come in and out of a project.
Software that is technically excellent is often easier to understand for people who are new to it. For example, excellence in user experience and design means new users can get up to speed on software faster. Use of good design patterns and automated testing allows new developers to understand existing software easily.
Verification and traceability for contracts or other compliance needs.
Test-driven development (code) and specification by example (scripting and code) are forms of traceable, executable documentation that easily stay in-sync with the underlying software system.
Decision-making and analysis for business and technical problems.
In particular, diagrams can help a great deal here. However, electronic tools for creating such diagrams can be slow and awkward. Consider the practice of Agile Modelling (basically using a whiteboard and taking photos) as a good alternative to precise technical diagramming if you are doing problem-solving.
Management oversight and control.
Reports and metrics drive much of the traditional documentation in an organization. Simplifying reports and metrics often leads to a clearer picture of what is going on, reduces the opportunities to “game” the system, and always results in lower levels of documentation. As well, some reports and metrics can be generated 100% through automated means. All that said, the fundamental premise in the Agile manifesto is that management should base decisions on what is actually built – the “Working software” by looking at it and using it.
Various aspects of individual accountability.
If you really need this, a good version control system can give you the information for this. Sign-offs and other types of accountability documentation are typically just waste that doesn’t actually help in process improvement. Most people who are in high-compliance environments already have licenses and/or security clearances that provide this accountability. If you software is working, however, then this isn’t even a concern as trust is built and bureaucracy can be reduced.

In my recent training programs as research for this article, I have surveyed over 100 people on one aspect of documentation – code documentation. Every individual surveyed is either currently coding or has a coding background, and every single person had the same answer to a simple scenario question:

Imagine that you have just joined a new organization and you are about to start working as a software developer. One of the existing team members comes up to you and introduces himself. He has with him a piece of paper with a complicated-looking diagram and a full binder that looks to be holding about 250 pages. He asks you, “you need to get up to speed quickly on our existing system – we’re starting you coding tomorrow – would you prefer to go over the architecture diagram with me or would you prefer to review the detailed specifications and design documents.” He indicates the one-page diagram and the binder respectively. Which would you prefer?

(I’ve put up a Survey Monkey one-question survey: Code Documentation Preference to extend the reach of this question. It should take you all of 60 seconds to do it. I’ll post results when I write the next Agile Manifesto essay in a month or two.)

The fact that everyone answers the same way is interesting. What is even more interesting to me is that if you think through this scenario, it is actually almost the worst-case scenario where you might want documentation for your developers. That means that in “better” cases where documentation for developers may not be as urgent or necessary, then the approach of just going to talk with someone is a lot better.

Documentation and Maps

The problem with documentation is the same problem we have with maps: “the map is not the territory” (quote from the wisdom of my father, Garry Berteig). We sometimes forget this simple idea. When we look at, say, Google Maps, we always have in the back of our consciousness that the map is just a guide and it is not a guarantee. We know that if we arrive at a place, we will see the richness of the real world, not the simplified lines and colours of a map. We don’t consider maps as legally binding contracts (usually). We use maps to orient ourselves… as we look around at our reality. We can share directions using maps, but we don’t share purpose or problems with maps. And finally, maps assume that physical reality is changing relatively slowly (even Google Maps).

Many times when we create documentation in organizations, however, we get confused about the map versus the territory.

Agility and Documentation

Of course, code is a funny thing: all code is documentation too. The code is not the behaviour. But in software, code (e.g. Java, ASM, Scheme, Prolog, Python, etc.) is as close as possible to the perfect map. Software is (mostly) deterministic. Software (mostly) doesn’t change itself. Software (mostly) runs in a state absent from in-place human changes to that software. Software (mostly) runs on a system (virtual or physical) that has stable characteristics. The code we write is a map. From this perspective, documentation becomes even less important if we have people that already understand the language(s)/platform(s) deeply.

This essay is a continuation of my series on the Agile Manifesto. The previous two essays are “Value and Values” and “Individuals and Interactions over Processes and Tools“.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!

How-To Apply Agile, Reference Information

Updated: Full-Day Product Owner Simulation

February 26, 2015 Mishkin Berteig Leave a comment

The Product Owner Simulation that I shared last summer has some minor updates based on a stronger emphasis on product vision. In particular, two 5 minute exercises before and after the Product Box exercise help to frame the concept of product vision and make it stronger.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!

Agile Management, Announcements, Professional Development

Scrum Alliance Added Qualifications – Scaling Scrum

February 23, 2015 Mishkin Berteig Leave a comment

The Scrum Alliance just announced through a press release the Added Qualifications [PDF] program. From the release:

The Added Qualifications program will begin by first offering courses in Scaling Scrum Fundamentals. Those interested in earning an Added Qualification in Scaling Scrum Fundamentals will need to hold at least one of two foundational certifications, Certified ScrumMaster® or Certified Scrum Product Owner®.

More information can be found on the Scrum Alliance Added Qualifications page.

Through World Mindware, we will be introducing courses over the next months to help you achieve these new Added Qualifications.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!

Agile Management, Announcements, How-To Apply Agile, Professional Development, Scrum, XP and Lean, Theory of Agile

Announcing: The Real Agility Program

January 5, 2015 Mishkin Berteig Leave a comment

The Real Agility Program is an Enterprise Agile change program to help organizations develop high-performance teams, deliver amazing products, dramatically improve time to market and quality, and create work environments that are awesome for employees.

This article is a written summary of the Executive Briefing presentation available upon request from the Real Agility Program web site. If you obtain the executive briefing, you can follow along with the article below and use it to present Real Agility to your enterprise stakeholders.

The Problem

At Berteig Consulting we have been working for 10 years to learn how to help organizations transform people, process and culture. The problem is simple to state: there is a huge amount of opportunity waste and process waste in most normal enterprise-scale organizations. If you have more than a couple hundred people in your organization, this almost certainly affects you.

We like to call this problem “the Bureaucratic Beast”. The Bureaucratic Beast is a self-serving monster that seems to grow and grow and grow. As it grows, this Beast makes it progressively more difficult for business leaders to innovate, respond to changes in the market, satisfy existing customers, and retain great employees.

Real Agility, a system to tame the Bureaucratic Beast, comes from our experience working with numerous enterprise Agile adoptions. This experience, in turn, rests on the shoulders of giants like John Kotter (“Leading Change”), Edgar Schein (“The Corporate Culture Survival Guide”), Jim Collins (“Good to Great” and “Built to Last”), Mary Poppendieck (“Lean Software Development”) Jon Katzenbach (“The Wisdom of Teams”) and Frederick Brooks (“The Mythical Man-Month”). Real Agility is designed to tame all the behaviours of the Bureaucratic Beast: inefficiency, dis-engaged staff, poor quality and slow time-to-market.

Studies have proven that Agile methods work in IT. In 2012, the Standish Group observed that 42% of Agile projects succeed vs. just 14% of projects done with traditional “Bureaucratic Beast” methods. Agile and associated techniques aren’t just for IT. There is growing use of these same techniques in non-technoogy environments such as marketing, operations, sales, education, healthcare, and even heavy industry like mining.

Real Agility Basics: Agile + Lean

Real Agility is a combination of Agile and Lean; both systems used harmoniously throughout an enterprise. Real Agility affects delivery processes by taking long-term goals and dividing them into short cycles of work that deliver valuable results rapidly while providing fast feedback on scope, quality and most importantly value. Real Agility affects management processes by finding and eliminating wasteful activities with a system view. And Real Agility affects human resources (people!) by creating “Delivery Teams” which have clear goals, are composed of multi-skilled people who self-organize, and are stable in membership over long periods of time.

There are lots of radical differences between Real Agility and traditional management (that led to the Bureaucratic Beast in the first place). Real Agility prioritizes work by value instead of critical path, encourages self-organizing instead of command-and-control management, a team focus instead of project focus, evolving requirements instead of frozen requirements, skills-based interactions instead of roles-based interaction, continuous learning instead of crisis management, and many others.

Real Agility is built on a rich Agile and Lean ecosystem of values, principles and tools. Examples include the Agile Manifesto, the “Stop the Line” practice, various retrospective techniques, methods and frameworks such as Scrum and OpenAgile, and various thinking tools compatible with the Agile – Lean ecosystem such as those developed by Edward de Bono (“Lateral Thinking”) and Genrich Altshuller (“TRIZ”).

Real Agility acknowledges that there are various approaches to Agile adoption at the enterprise level: Ad Hoc (not usually successful – Nortel tried this), Grassroots (e.g. Yahoo!), Pragmatic (SAFe and DAD fall into this category), Transformative (the best balance of speed of change and risk reduction – this is where the Real Agility Program falls), and Big-Bang (only used in situations of true desperation).

Why Choose Transformative?

One way to think about these five approaches to Agile adoption is to compare the magnitude of actual business results. This is certainly the all-important bottom line. But most businesses also consider risk (or certainty of results). Ad-Hoc approaches to Agile adoption have poor business results and a very high level of risk. Big-Bang approaches (changing a whole enterprise to Agile literally over night) often have truly stunning business results, but are also extremely high risk. Grassroots, where leaders give staff a great deal of choice about how and when to adopt Agile, is a bit better in that the risk is lower, but the business results often take quite a while to manifest themselves. Pragmatic approaches tend to be very low risk because they often accommodate the Bureaucratic Beast, but that also limits their business results to merely “good” and not great. Transformative approaches which systematically address organizational culture are just a bit riskier than Pragmatic approaches, but the business results are generally outstanding.

More specifically, Pragmatic approaches such as SAFe (Scaled Agile Framework) are popular because they are designed to fit in with existing middle management structures (where the Bureaucratic Beast is most often found). As a result, there is slow incremental change that typically has to be driven top-down from leadership. Initial results are good, but modest. And the long term? These techniques haven’t been around long enough to know, but in theory it will take a long time to get to full organizational Agility. Bottom line is that Pragmatic approaches are low risk but the results are modest.

Transformative approaches such as the Real Agility Program (there are others too) are less popular because there is significantly more disruption: the Bureaucratic Beast has to be completely tamed to serve a new master: business leadership! Transformative approaches require top-to-bottom organizational and structural change. They include a change in power relationships to allow for grassroots-driven change that is empowered by servant leaders. Transformative approaches are moderate in some ways: they are systematic and they don’t require all change to be done overnight. Nevertheless, often great business results are obtained relatively quickly. There is a moderate risk that the change won’t deliver the great results, but that moderate risk is usually worth taking.

Regardless of adoption strategy (Transformative or otherwise) there are a few critical success factors. Truthfulness is the foundation because without it, it is impossible to see the whole picture including organizational culture. And love is the strongest driver of change because cultural and behavioural change requires emotional commitment on the part of everyone.

Culture change is often challenging. There are unexpected problems. Two steps forward are often followed by one step back. Some roadblocks to culture change will be surprisingly persistent. Leaders need patience and persistence… and a systematic change program.

The Real Agility Program

The Real Agility Program has four tracks or lines of action (links take you to the Real Agility Program web site):

Recommendations: consultants assess an organization and create a playbook that customizes the other tracks of the Real Agility Program as well as dealing with any important outliers.
Execution: coaches help to launch project, product and operational Delivery Teams and Delivery Groups that learn the techniques of grassroots-driven continuous improvement.
Accompaniment: trainer/coaches help you develop key staff into in-house Real Agility Coaches that learn to manage Delivery Groups for sustainable long-term efforts such as a product or line of business.
Leadership: coaches help your executive team to drive strategic change for long-term results with an approach that helps executives lead by example for enterprise culture change.

Structurally an enterprise using Real Agility is organized into Delivery Groups. A Delivery Group is composed of one or more Delivery Teams (up to 150 people) who work together to produce business results. Key roles include a Business leader, a People leader and a Technology leader all of whom become Real Agility Coaches and take the place of traditional functional management. As well, coordination across multiple Delivery Teams within a Delivery Group is done using an organized list of “Value Drivers” maintained by the Business leader and a supporting Business Leadership Group. Cross-team support is handled by a People and Technology Support Group co-led by the People and Technology leaders. Depending on need there may also be a number of communities of practice for Delivery Team members to help spread learning.

At an organizational or enterprise level, the Leadership Team includes top executives from business, finance, technology, HR, operations and any other critical parts of the organization. This Leadership Team communicates the importance of the changes that the Delivery Groups are going through. They lead by example using techniques from Real Agility to execute organizational changes. And, of course, they manage the accountability of the various Delivery Groups throughout the enterprise.

The results of using the Real Agility Program are usually exceptional. Typical results include:

20x improvement in quality
10x improvement in speed to market
5x improvement in process efficiency
and 60% improvement in employee retention.

Of course, these results depend on baseline measures and that key risk factors are properly managed by the Leadership Team.

Your Organization

Not every organization needs (or is ready for) the Real Agility Program. Your organization is likely a good candidate if three or more of the following problems are true for your organization:

high operating costs
late project deliveries
poor quality in products or services
low stakeholder satisfaction
managers overworked
organizational mis-alignment
slow time-to-market
low staff morale
excessive overtime
or…
you need to tame the Bureaucratic Beast

Consider that list carefully and if you feel like you have enough of the above problems, please contact us at tame.the.beast@berteigconsulting.com. or read more about the Real Agility Program for Enterprise Agility on the website.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!

Professional Development

Announcing New Agile Training for Coaches, Executives, Job Seekers and More

January 2, 2015 Mishkin Berteig Leave a comment

New Agile Certification Training

Our new premium offering: the Certified Real Agility Coach course is delivered in an unusual format of 40 days (yes, forty) spread over one year. This in-depth, advanced training program is designed to help people with experience on Agile teams to become fully-capable independent Agile coaches. Worried about the time commitment? A substantial portion of the course is delivered as on-the-job training and a significant number of course hours are outside regular working hours… and the schedule is flexible to accommodate participants’ unique scheduling needs. Spots are extremely limited for this course. Reserve your spot now! (Contributes all the training hours required for the Certified Scrum Professional designation. As well, if you do not already have the CSM and CSPO designations, you will receive free enrolment in either or both of those courses once your registration has been confirmed.)

Since Travis Birch and Mishkin Berteig have become Certified SAFE Program Consultants, we are now offering the Leading Safe 2-day course for project, program and functional managers, change agents and department leaders. Learn about the Scaled Agile Framework; one the most popular enterprise Agile frameworks. SAFe combines Scrum, Extreme Programming and Lean to effectively allow larger groups of people to execute programs while interfacing effectively with traditional corporate governance. Do you have 25 people or more working on a program? Then the Leading SAFe training is for you!

New Agile Introduction Courses

Scrum and Enterprise Agile for Executives is a half-day workshop designed to help you solve one of the biggest problems organizations have: how to become more Agile? Using the tools and techniques of the Real Agility Program, participants will be guided to make effective long- and short-term plans for increasing productivity, innovation, quality and customer satisfaction. This workshop is delivered by Mishkin Berteig who has helped numerous executives at organizations large and small with successful Agile transformations. Just $250 per person!

Travis Birch, a Partner at Berteig Consulting who has years of experience helping Agile teams reach award-winning levels of performance, is going to be delivering two of our new offerings:

Choosing an Agile Career is a one-day workshop designed to help people who don’t yet know how they can best fit into the most important revolution sweeping the corporate world. Should you be a ScrumMaster? A Product Owner? An Agile Coach? Something else? Ideal for people who have been asked by their executives to sort out their career path in a newly Agile organization or department. $450/person with an early-bird discount available for some dates.

Kanban: Gentle Change is a deep-dive immersion into a critical process-improvement and teamwork technique Learn how tools for making work visible can improve productivity, throughput and efficiency.. Ideally suited for team leads, project and functional managers, HR managers and process improvement managers. $450/person with an early-bird discount available for some dates. Counts as 7 PDUs with the PMI and contributes to the Agile Certified Practitioner designation.

Other Workshops

CSM Certified ScrumMaster Logo CSPO Certified Scrum Product Owner Logo

Of course, we continue to offer our extremely well-received (often sold out!) Certified ScrumMaster and Certified Scrum Product Owner training courses. These courses are immersive, intensive, and designed to help you to become great ScrumMasters and Product Owners.

Please see our complete 2015 Agile and Scrum course schedule here! Most of our courses are held in the Toronto area which has a great international airport, fantastic food, amazing entertainment, and is just generally a fun place to come for a bit of training and a bit of sight-seeing. Some courses are also offered in other cities including Vancouver, London Ontario, and Waterloo. Most of our courses are also available for in-house private dates. Please contact learn@worldmindware.com for more information about group discounts, corporate savings programs or in-house private offerings.

COMING SOON We are working to offer Certified Scrum Developer (CSD) training as a complement to our already successful Certified ScrumMaster and Certified Scrum Product Owner training courses. The CSD course will help technology professionals learn the critical Agile engineering and teamwork practices that are absolutely required to make Scrum successful in delivering software products. This training is highly technical and participants are expected to already be strong software developers.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!

Agile Management, How-To Apply Agile, Professional Development, Reference Information, Theory of Agile

Tips to Start Agile in a Hostile Environment

November 18, 2014 Mishkin Berteig 3 Comments

Although Agile methods are very popular (particularly Scrum), there are still many organizations or departments which may not yet have official support for adopting Agile methods formally. In some cases, management may even be hostile to the concepts and practices of Agile methods. If you are interested in Agile, you don’t have to give up hope (or look to switch jobs). Instead, here are some tips to start using Agile methods even in hostile environments.

Regular Retrospectives

Some Agilists claim that the retrospective is actually the key to being Agile. In some ways, this is also the easiest practice to introduce into an organization. Start with “easy” retrospectives like “Pluses and Deltas” or “Starfish“. These are retrospectives that can be done in 15 minutes or half an hour. Try to do them with your team weekly. If you are are a team lead or a project manager, it will be easy to include this as part of an existing weekly status meeting. If you are “just” a team member, you might have to get some modest amount of permission.

So why would it be good to do a retrospective? Because it’s a high return-on-investment activity. For a few minutes of investment, a team using retrospectives can become aware of dramatic opportunities for improvement in how they are functioning. Here are a couple more articles about the importance of retrospectives:

What’s an Agile Retrospective and Why Would You Do It?

What is a Retrospective?

Practice-by-Practice

Although I strongly recommend starting with retrospectives, sometimes that’s not the best way to start. Myself, my first formal Agile environment, I started with the Daily Scrum. Another time less formal, I started with Test-Driven Development. In both cases, starting with a single practice, done well, led to adding additional practices over a relatively short period of months. This gradual adoption of practices led, in time, to attracting positive interest from managers and leaders. This is the practice-by-practice approach. Start with a simple Agile practice that you can do without asking anyone for permission. Make sure it is a practice that makes sense for your particular environment – it must produce some benefit! If you are technical contributor on a team, then practices such as refactoring or test-driven development can be a good place to start. If you are more business-oriented, then maybe consider user stories or one of the Innovation Games. If you are responsible for administrative aspects of the work, then consider a Kanban board or burndown charts.

It is important to get the chosen practice done consistently and done well, even when the team is struggling with some sort of crisis or another. If the practice can’t be sustained through a project crisis, then you won’t be able to build on it to add additional Agile practices.

Stealth Project

Sometimes you get an unusual opportunity: a project that is funded but hidden from the bureaucracy. This can happen for a variety of reasons, but often it is because some executive has a pet project and says (effectively): “make it so”. This is an opportunity to do Agile. Since there is little oversight from a process perspective, and since the overall project has a strong executive sponsor, there is often a great deal of freedom on the question of “how do we actually execute.” There can be challenges as well: often the executive wants daily insight into progress, but that level of transparency is actually something that Agile methods can really support. In this case, there is no need to ask anyone on what method to use, just pick one (e.g. Scrum or OpenAgile or XP or Kanban or Crystal or…) and go for it. Don’t talk about it.

The “just do it” approach requires that you have some influence. You don’t have to be an influencer, but you need connections and you need charisma and you need courage. If you don’t have at least two of those three, you shouldn’t try this approach. You have to do things and get away with things that normally would get people fired – not because they are illegal – but simply because they are so counter-cultural to how your organization normally works. Here are a few comments on Stealth Methodology Adoption.

Co-Conspirators

There’s nothing like working with a band of rebels! If you can find one or two other people to become co-conspirators in changing your organization, you can try many lines of action and see which ones work. Getting together for lunch or after work frequently is the best way to develop a common vision and to make plans. Of course, you need to actually execute some of your plans. Having people to work with is really part of the other tips here: you can have co-conspirators to help you launch a practice-by-practice Agile transformation, for example.

But, like any rebellion, you really need to trust those you work with in these early stages. Lacking that trust will slow everything you do possibly to the point of ineffectualness. Trust means that you have, for some time, a formal vow of silence. Not until you have critical mass through your mutual efforts can you reveal the plan behind your actions.

Read “Fearless Change”

I can’t recommend this one enough! Read “Fearless Change” by Mary Lynn Manns and Linda Rising. This is a “patterns” book. It is a collection of techniques that can be applied to help make organizational changes, where each technique has its own unique context of use. Lots of research and experience have gone into the creation of this book and it is a classic for anyone who wants to be an organizational change agent. Patterns include basics such as “Do Lunch” to help build trust and agreement with your ideas for change or “Champion Skeptic” to leverage the value of having systematic, open criticism of your change idea.

Don’t Call it “Agile”

This isn’t really a “tip” in the sense of an action item. Instead, this is a preventative measure… to prevent negative reactions to your proposals for change. The words “Agile” or “Scrum”, while they have their supporters, also have detractors. To avoid some of the prejudices that some people may hold, you can start by _not_ calling your effort by those names. Use another name. Or let your ideas go nameless. This can be challenging, particularly if other people start to use the words “Agile” or “Scrum”. By going nameless into the change effort, people will focus more on results and rational assessment of your ideas rather than on their emotional prejudices.

A minor variant of this is to “brand” your ideas in a way that makes them more palatable. One company that we worked with, let’s call them XYZ, called their custom Agile method “Agile @ XYZ”. Just those extra four symbols “@ XYZ” made all the difference in changing the effort from one where managers and executives would resist the change to one where they would feel connected to the change.

Get Some Training

Okay, some blatant self-promotion here: consider our Certified Real Agility Coach training program. It’s a 40-week program that takes about 12 hours/week of your time for coursework. The next cohort of participants starts in June 2015 and we are taking deposits for participants. This training is comprehensive, top-notch training for anyone wishing to become an organizational change agent focusing on Agility.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!

Reference Information, Scrum, XP and Lean

Evolution of a Scrum Diagram

September 23, 2014 Mishkin Berteig 2 Comments

Over the many years that I have been teaching Scrum (since 2005!), I have had a Scrum diagram as part of my slides and/or handouts. The diagram has gone through several major and minor changes throughout that time. Here is the progression from oldest to newest:

First Attempt

This diagram was used in some of my earliest slides when I first started delivering Scrum training. It is bad. It is woefully incomplete. But, here it is:

Second Diagram

I knew the first one was bad so after not too long, I created this next diagram as a supplement that was meant to show the whole Scrum process all in one page. Similar to other Scrum “cheat sheet” style diagrams. I used this diagram until about 2008 when I got some very good feedback from a great trainer, Jim Heidema.

Third Try

The changes I made were small, but to me, significant. Changing from a “mathematical” language of “Sprint N”, “Sprint N+1” to a more general language of “Current”, “Future” was a big deal. I really struggled with that. Probably because I was still relatively new to being non-technical.

Diagram Four

This fourth diagram made some minor formatting changes, but most importantly added “Backlog Grooming”. It’s funny how long I talked about grooming in my classes before realizing that it was missing from the diagram. I used the previous diagram and this diagram for a couple years each before making a rather major change to create the next one.

Fifth Go

A couple years ago I realized that I wasn’t really talking about the Scrum values in my classes. I started to introduce them in some of my other handouts and discussions, but it still took a while for me to reflect those values in my diagram. I had also received a lot of feedback that having two Product Backlogs in the diagram was confusing. Finally, I realized that I was missing an opportunity to use colour more systematically. So, a major reformatting, systematic colour coding and the addition of the Scrum values was my next change.

Branded Diagram (ug.)

In a rush, I added some logos to the diagram. Just made it gross, but it’s badness, combined with feedback about said badness, actually inspired a major change for the next version.

Seventh Diagram (Sep. 2014)

I was showing my brand-new branded diagram to a bunch of people who really care about design and UX. The very first comment when I handed out the diagram was: “wow, you can really tell this wasn’t done by a designer!” Well, that got me thinking deeply about the diagram (again). So, here is my newest, latest and greatest (still not done by a designer) version of my Scrum diagram!

Eighth Diagram (2016-ish)

This new diagram represents many small changes including a much stronger focus on Scrum “by-the-book”. The most important and significant change is the addition of a bit of information about the definition of done. It also includes some other very minor layout and content changes, and updated branding (again) with the new BERTEIG logo. This one has been in use since some time in 2016, but I don’t remember the exact date.

Ninth Diagram (June 2019)

A re-branding of the diagram with color and iconography meant to be consistent with our other diagrams. The work on converting from the previous diagram to this one was done by my son, Justice Berteig.

Tenth Diagram (Sep 2019)

There were quite a few things that were missing from the previous diagram and a small number of things lingering that still were not compliant with the definition of Scrum from the Scrum Guide. I think this one has all the needed changes. Big additions include the “Development Team”, “Transparency, Inspection and Adaptation”, “Product Vision” and “Marketplace”.

The Future

I would absolutely love constructive feedback about this latest diagram. Of course, if you like it, please let me know that too! The thing I like about this is that it is a way of looking back at almost 9 years of my teaching history. Continuous improvement is so important, so I welcome your comments! If you have your own diagrams, please link to them in the comments – I would love to see those too! In fact, it would be really cool if a bunch of people could make little “Evolution of a Scrum Diagram” posts – let me know if you do!!!

PS. Here is a Scrum diagram created by my colleague Travis Birch.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!

Agile Management, How-To Apply Agile, Professional Development, Scrum, XP and Lean

Full-Day Product Owner Simulation Exercise

August 5, 2014 Mishkin Berteig Leave a comment

This Product Owner Simulation exercise rests on the idea that people learn a lot better by doing something than by talking about it. My Product Owner classes were getting great reviews, but I really felt like there was something missing compared to my ScrumMaster classes which have a full-day ScrumMaster simulation exercise. It took a little while to figure it out, but this article describes in detail how I do the simulation for the Product Owner class. I’m sure it will evolve and get refined from here since I have only used the simulation twice so far.

UPDATE: 2016-08-14 – major updates to the Product Owner Simulation after having used it at least 15 times since this was originally written!

UPDATE: 2017-07-13 – minor updates including new versions of handouts that better explain some concepts, and slightly expanded facilitator’s notes.

NOTE: Permission to use this exercise / print associated materials is granted with a simple request: please link to this page on your blog, in a LinkedIn group or Google group, like it on Facebook etc. or write a comment in our comments section!

Pre-requisites: None! No prior Scrum or Agile knowledge or experience required. However, it is recommended that participants have an introduction to Scrum or have read the Scrum Guide.

Audience: Product Owners, Business Analysts, Project Managers, Product Managers and other people responsible for business results and who interact with a Scrum team.

Timing: This simulation takes at least 7 classroom hours. I usually run it from 8:30am to 5:00pm with a one hour lunch break and two 15 minute breaks during the day.

Materials Needed:

Coloured pencils and/or coloured markers
Black Sharpie fine-point markers
Scissors
Rulers
Scotch tape and/or glue stick
Blank white printer paper
Pencils, erasers, pencil sharpeners
Blank white 4×6 and 3×5 note cards
Blank white box (e.g. a shirt box from U-Line) or foam core boards (see photo)
Planning Game cards (email me if you want a bunch for free!)

Room Setup: Round tables with 5 to 7 chairs at each table. Materials distributed to each table.

Product Owner Simulation Agenda

(with facilitator’s notes in red)

Introduction to the Product Owner Simulation

Lecture: Simulation Overview, Backlog Preparation and Refinement
The purpose of the overall simulation is to learn to create a good Product Backlog in preparation for a Scrum team’s first Sprint. Many of the techniques we explore will also be useable in ongoing Product Backlog Refinement. Review the agenda with participants.
Exercise: Great Products and their Vision
5 minutes – at table groups, think about the physical consumer products you know and use often. How are those products marketed and sold? How are they presented? How do you decide to use that product vs. a competitive product? Make sure you discuss specific products rather than corporate brands or product categories.
Discussion: What Makes a Great Product Vision?
Ask for the group to brainstorm the qualities of a great product vision. Ensure that “simplicity”, “urgency”, and “emotion” are all mentioned. (Great reference: “Made to Stick: Why Some Ideas Survive and Others Die” by Chip and Dan Heath.)
Discussion: Choosing a Product for the Simulation
Give participants three product options (suggested options: “Doggy dating web site”, “iPad app for plastic surgeons’ medical and practice management”, “POS for food trucks with social features”). A table group must agree to one of the options. They will stick with this product for the remainder of the simulation. Three minutes to decide.

Product Vision

Remind participants that in Scrum, we don’t necessarily do all the steps of the simulation in any particular order. Instead, we are practicing techniques that can come into use at various times. The Product Owner Simulation must be done in a particular order. The techniques are all part of the overall process of Product Backlog Refinement.

Exercise: Product Vision Statement
5 minutes – attempt to craft a brief, compelling product vision statement that communicates “simplicity”, “urgency” and “emotion”. The audience of the product vision statement is your Scrum Team (NOT customers). Debrief by hearing from each group, then asking if the three characteristics have been communicated.
Handout: Product Vision in Context [PDF]
Lecture: Explain the Product Vision handout and ask for questions, insights. At this time, highlight the differences between a “product” and a “project”. Emphasize the concept that a product has customers who pay money and who have choice about what they buy, and that those customers are outside of your organization. Possible discussion about Scrum being ideally suited for Product Development vs. project management or operations.
Reference: Innovation Games – Product Box [site]
Handout: Product Box Innovation Game [PDF]
Lecture: Product Box
Talk about the need for a compelling vision as a pre-requisite for high-performance teams, and a way to decide what is in vs. out of a Product Backlog. Introduce “Product Box” as a way to do market research in an Agile compatible way (collaborative, light documentation, quick). Talk about the pattern of a product box: front to attract, back to showcase, sides to deal with objections. Use of online resources / web research is allowed but should not dominate the exercise.
Exercise: Building Your Product
30 minutes, with warnings at 15 minutes and 5 minutes remaining. Ensure that by 10 minutes in, the group has actually started using the craft supplies and isn’t just talking.
Exercise: Presenting Your Product
5 minutes – give additional time to allow groups to prepare for a trade show (in their market) presentation where other groups (or yourself) will role-play sceptical trade show participants.
Discussion: Debrief Product Box
Focus on feasibility of using Product Box in real life, the power of metaphor, and the power of collaboration.
Exercise: Product Vision Statement Reprise
5 minutes – attempt to craft a brief, compelling product vision statement that communicates “simplicity”, “urgency” and “emotion”.
Discussion: Debrief by hearing new Product Vision Statements.

Product Users

Handout: User Categories Thinking Tool [PDF]
Lecture: User Categories
Describe “users we sell”, “users who pay” and “admin users” as the three major categories. Users can be in hierarchies where a general user type may have two or more specific sub-types.
Exercise: Identifying Users
10 minutes. One user of each main type, at least 5 users in total. More is okay.
Handout: Persona [PDF]
Lecture: Personas, Usability and Empathy
Introduce Persona concept (great reference: “The Inmates are Running the Asylum” by Alan Cooper). Usability as part of Agile, not separate (i.e. “working software”). Identifying personas as a way to build empathy from the development team to the end users/customers.
Exercise: Generate a Persona
10 minutes. Choose a primary user. Generate name, age, background story, and relationship to product. Find an image from a stock photography site. Important: do at least a little bit of research and tie some part of your persona to that research! Try to be specific and write the background so it emphasizes the concept of empathy.

Business Value

Lecture: Good and Bad Metrics
Describe ROI, TTM and CSat as all-around good metrics. Explain red-yellow-green project dashboard and lines-of-code as bad metrics. Ask for other examples of good or bad metrics.
Handout: Value Metrics [PDF]
Exercise: Value Metrics
10 minutes. At table teams try to come up with at least 10 quantitative and 10 qualitative metrics. Use the handout as a worksheet. Focus on metrics relevant to the simulation product, but also consider metrics that might be from other businesses or viewpoints (e.g. finance metrics, marketing analytics, etc.).
Discussion: Value Metrics
Throughout the classroom, share all the metrics and write them on a flip chart so they can all be seen at once. Ask for insights or questions about metrics.
Exercise: Key Metrics
From the flipchart, each table team should choose 3 to 6 metrics that are most important to measure business success of their product. It’s okay for that short list to include ROI, TTM and CSat. Keep this list handy for the next part of the simulation.
Discussion: Metrics and Product Vision
Discuss if/how Product Vision helped to choose the key metrics. If needed, allow a few moments for participants to reconsider the metrics they chose in light of their Product Vision.

Product Backlog Items

Handout: Creating Product Backlog Items Worksheet [PDF]
Exercise: Create Product Backlog Items
Use the product box, the user categories, and the business metrics. For each row in the worksheet, identify a feature, decide which user interacts with the product to exercise that feature, and choose the business metric that is most improved by implementing the feature. For each, decide if the feature is visible to the user through the user interface. The resulting worksheet should be filled up such that at least ten of the features are visible in the user interface.
Handout: User Stories [PDF]
Lecture: Writing Effective User Stories
Use the example “As a Job Seeker, I can upload my resume, so that I get a job.” Explain the user story template based on the handout. Emphasize the idea of end user functionality. Explain user stories as an important tool, but optional part of Scrum. Usually some time is spent on a discussion about physical note cards vs. electronic tools – emphasize the fact that the note cards support the values and principles of the Agile Manifesto while electronic tools (typically) subvert them.
Exercise: Create User Stories
Goal: 20 user stories for each group’s product, at least five user stories for the persona, and two user stories for each other type of user, all done in 20 minutes. User Stories must be written on 3×5 note cards with a 2cm blank area on right side of each card. The groups start by writing one or two User Stories together, then divide and conquer to create the rest. At the end of the 20 minutes, there is a brief amount of time allocated to making sure there are no duplicated “features” described.
Discussion: Review User Stories
Workshop examples from each group. Ensure that the “benefit” section of each story does not contain a feature. Possibly discuss the three parts of a User Story as “who”, “what” and “why”. The benefit is usually related to time, money or happiness and connects the User Story to the product vision.
Handout: Simple Story Sizing [PDF]
Exercise: Small, Uncertain, Large Effort Estimation
Small means “easily and with certainty fits within a single Sprint”, large means “definitely requires more than a full Sprint of work”, and uncertain means either “uncertain size” or “uncertain if it will fit in a single Sprint”. Teams create buckets and sort all the user stories into the three buckets – they must role play being technical contributors (Development Team Members). Start by identifying one “small” one and one “large” one, then by dividing an conquering. Final step is to verify that the small ones really are small.
Handout: User Story Splitting [PDF]
Lecture: Splitting User Stories
Go through each of the “top” six splitting methods. Provide simple examples where the group needs help. E.g. error conditions as an example of splitting by business logic.
Exercise: Split Some
Goal: result in at least 30 user stories, use each of the top six splitting methods at least once, give 15 minutes. Focus on splitting the items that were estimated in the “Large” or “Uncertain” buckets.
Discussion: Review Splitting

Estimation and Financial Modelling

Lecture: Effort, Value and ROI
Customers and business stakeholders estimate value, Scrum team members estimate effort, and ROI is the calculation of the ration of value over effort. Discuss examples of ordering based on these ratios, e.g. 8/2 vs. 8/4 and 200/20 vs. 20/2.
Handout: The Bucket System [link to page with PDF download]
Lecture: The Bucket System
Review process based on handout.
Exercise: Estimating Business Value
10 minutes. Goal: all user stories get a business value estimate written in the top right-hand corner of the user story card.
Discussion: Debrief the Bucket System
Handout: The Planning Game [link to a page with PDF download]
Lecture: The Planning Game
Exercise: Estimating Effort
20 minutes. Goal: estimate 3 user stories using the Planning Game. Use the Bucket System to estimate the remainder with the ones already estimated as the reference points.
Discussion: Debrief the Planning Game
Handout: Methods of Ordering the Product Backlog [PDF]
Lecture: Ordering a Product Backlog
Review ROI as a method to order the PBIs. Reminder that the Product Owner has final authority and can ignore the estimates in deciding on the order.
Exercise: Calculating ROI and Ordering
5 minutes. Just simple divide-and-conquer calculations of business value divided by effort for all the user stories.
Lecture: Simulation Wrap-Up – Where Does This Fit?
Reminder of the idea of creating an initial Product Backlog that is “good enough” to start the first Sprint.

NOTE: Permission to use the Product Owner Simulation exercise and print associated materials is granted with a simple request: please link to this page on your blog, in a LinkedIn group or Google group, like it on Facebook etc. or write a comment in our comments section!

If you are interested in experiencing this Product Owner Simulation first-hand, please consider attending one of our Certified Scrum Product Owner learning events.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!

Professional Development, Scrum, XP and Lean

Super-Hard ScrumMaster Quiz – Test Yourself!

July 23, 2014 Mishkin Berteig 17 Comments

For a little while last year I was using a quiz in my Certified ScrumMaster courses that was deliberately designed to be super hard. Why? Because if anyone could answer it correctly before the end of the class, I would give them their certification early and allow them to leave. Not a single person out of several hundred was able to do it.

So… want to give it a try? I’ve got two files here. One is the quiz without answers. The other is the answer key. Let me know if you have any questions!!!

CSM Class Test – Super Hard! (PDF, 1 page)

(Please, give it a try before you even download this next piece!!!)

CSM Class Test – Answer Key (PDF, 1 page)

This test was first created by me and one of my close colleagues, Julien Mazloum from Outsofting. We were trying to make the CSM class something that the Chinese audience would really appreciate culturally. It worked well, up to a point. The main problem was that some of the questions were too subtle for people for whom English was their second language. That said, when I used it in my North American courses, still no one passed it! In fact, the best score I ever saw was 25 correct out of 30.

Have fun!

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!

Announcements

Announcing Summer of Scrum Toronto 2014 Pre-Registration

April 3, 2014 Mishkin Berteig Leave a comment

One of our big plans this summer is to have a selection of advanced Scrum and Agile – related training courses. We are delivering some of them ourselves, but we are also bring in outside experts for others.

Here is the course list at a high level:

– a 1-day “Advanced ScrumMaster” course
– a 1-day “Advanced Product Owner” course
– a 1-day “Managing for Success” course
– a 1-day “Enterprise Agile” course
– a 2-day “Agile Engineering Practices” course
– a 2-day “Agile Coach Training” course

Our schedule for these events will be finalized in the next few weeks. If you are interested in any of these courses, please pre-register here. Pre-registration will give you a guaranteed spot and a discount of 10% above and beyond the early-bird registration price.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!

Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)

Online

C$750.00

Mar 31

2023

Details

Real Agility Management Track - Practitioner I (RA-MT-LA)

Online

C$7950.00

Apr 3

2023

Details

Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)

Online

C$750.00

Apr 4

2023

Details

Advanced Certified ScrumMaster® (ACSM)

Online

C$1795.00

Apr 5

2023

Details

Scrum Master Bootcamp with CSM® (Certified Scrum Master®) [Virtual Learning] (SMBC)

Online

C$1895.00

Apr 11

2023

Details

Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)

Online

C$750.00

Apr 14

2023

Details

Win as a Manager with Your New Agile Coach: ChatGPT

Online

C$0.00

Apr 14

2023

Details

Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)

Online

C$750.00

Apr 17

2023

Details

Kanban for Scrum Masters (ML-KSM)

Online

C$495.00

Apr 18

2023

Details

Kanban for Product Owners (ML-KPO)

Online

C$495.00

Apr 19

2023

Details

Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)

Online

C$750.00

Apr 21

2023

Details

Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)

Online

C$750.00

Apr 25

2023

Details

Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)

Online

C$1895.00

Apr 26

2023

Details

Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)

Online

C$750.00

Apr 28

2023

Details

Win as a Manager with Your New Agile Coach: ChatGPT

Online

C$0.00

Apr 28

2023

Details

Advanced Certified Scrum Product Owner® (ACSPO)

Online

C$1525.75

May 3

2023

Details

Real Agility™ Real Agility™ Ask Me Anything / Coaching

Online

C$750.00

May 5

2023

Details

Kanban Systems Improvement® (KMPII)

Online

C$1610.75

May 10

2023

Details

Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)

Online

C$750.00

May 12

2023

Details

Real Agility™ Real Agility™ Ask Me Anything / Coaching

Online

C$750.00

May 12

2023

Details

Team Kanban Practitioner® (TKP)

Online

C$1100.75

May 16

2023

Details

Kanban for Scrum Masters (ML-KSM)

Online

C$495.00

May 16

2023

Details

Kanban for Product Owners (ML-KPO)

Online

C$495.00

May 17

2023

Details

Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)

Online

C$1610.75

May 17

2023

Details

Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)

Online

C$750.00

May 19

2023

Details

Real Agility™ Real Agility™ Ask Me Anything / Coaching

Online

C$750.00

May 19

2023

Details

Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)

Online

C$750.00

May 26

2023

Details

Real Agility™ Real Agility™ Ask Me Anything / Coaching

Online

C$750.00

May 26

2023

Details

Scrum Master Bootcamp with CSM® (Certified Scrum Master®) [Virtual Learning] (SMBC)

Online

C$1610.75

Jun 7

2023

Details

Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)

Online

C$750.00

Jun 9

2023

Details

Real Agility™ Real Agility™ Ask Me Anything / Coaching

Online

C$750.00

Jun 9

2023

Details

Kanban System Design® (KMPI)

Online

C$1610.75

Jun 13

2023

Details

Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)

Online

C$1610.75

Jun 14

2023

Details

Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)

Online

C$750.00

Jun 16

2023

Details

Real Agility™ Real Agility™ Ask Me Anything / Coaching

Online

C$750.00

Jun 16

2023

Details

Kanban for Scrum Masters (ML-KSM)

Online

C$495.00

Jun 20

2023

Details

Kanban for Product Owners (ML-KPO)

Online

C$495.00

Jun 21

2023

Details

Team Kanban Practitioner® (TKP)

Online

C$1015.75

Jun 21

2023

Details

Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)

Online

C$750.00

Jun 23

2023

Details

Real Agility™ Real Agility™ Ask Me Anything / Coaching

Online

C$750.00

Jun 23

2023

Details

Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)

Online

C$750.00

Jun 30

2023

Details

Real Agility™ Real Agility™ Ask Me Anything / Coaching

Online

C$750.00

Jun 30

2023

Details

Scrum Master Bootcamp with CSM® (Certified Scrum Master®) [Virtual Learning] (SMBC)

Online

C$1610.75

Jul 5

2023

Details

Kanban Systems Improvement® (KMPII)

Online

C$1610.75

Jul 11

2023

Details

Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)

Online

C$1610.75

Jul 12

2023

Details

Team Kanban Practitioner® (TKP)

Online

C$1015.75

Jul 19

2023

Details

Team Kanban Practitioner® (TKP)

Online

C$1015.75

Aug 15

2023

Details

Affiliated Promotions:

Affiliated Promotions:

Affiliated Promotions:

Affiliated Promotions:

Affiliated Promotions:

Affiliated Promotions:

Affiliated Promotions:

Affiliated Promotions:

Affiliated Promotions:

Affiliated Promotions:

Affiliated Promotions:

Affiliated Promotions:

Product Owner Simulation Agenda

Introduction to the Product Owner Simulation

Product Vision

Product Users

Business Value

Product Backlog Items

Estimation and Financial Modelling

Affiliated Promotions:

Affiliated Promotions:

Affiliated Promotions:

Upcoming Courses