Going to SAFe Program Consultant Training – London England

Travis Birch and I are going next week to the SAFe Program Consultant (SPC) training with Dean Leffingwell.  For Berteig Consulting, this will be an opportunity to expand our knowledge and to, perhaps, offer some new services including training and consulting.  Of course, there have been many articles written about SAFe from a Scrum perspective, but I’m hoping to write an article about it from an enterprise Agility perspective.  I have been involved as a coach and consultant in a number of such transformations, and I’m interested to see what I can learn from SAFe and perhaps how it can help to improve our Real Agility Program.  I currently consider SAFe to be a “pragmatic” approach to enterprise Agility vs. a “transformative” approach.  This perspective is based on some light reading and 3rd party reports about SAFe… clearly not a good enough base of knowledge!  I’m looking forward to bridging that gap!

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Scrum Alliance, Scrum.org and Scrum Inc. Announce Collaboration

My heartfelt congratulations on this important and historic event!  Scrum is one, again!

From the official announcement issued by Scrum Alliance:

SCRUM ORGANIZATIONS ANNOUNCE OFFICIAL
COLLABORATIVE ADOPTION OF SCRUM GUIDE

Scrum Alliance, Scrum.org, and Scrum Inc. announce the release and joint endorsement of a new community website, ScrumGuides.org. The new website is the official source of “The Scrum Guide, The Definitive Guide to Scrum: The Rules of the Game.”

 

Dr. Jeff Sutherland and Ken Schwaber created Scrum and authored “The Scrum Guide” to ensure Scrum remains true to its core principles and values.

 

“The Scrum Guide is the canonical definition of Scrum. Ken and I have worked closely together for decades to keep it simple, clear, and, in the true spirit of Scrum, to include only what is absolutely necessary,” says Sutherland, CEO of Scrum Inc. “Scrum is a powerful tool to radically increase productivity. Every implementation of Scrum is different, as teams and organizations apply it within their context, but the fundamental framework always remains the same. For Scrum Alliance, Scrum.org, and Scrum Inc. to come together to recognize the central place the Scrum Guide holds will provide clarity to the hundreds of thousands of Scrum practitioners across the planet.”

 

The explosive growth of people and organizations using Scrum in recent years has led to some market confusion as to the precise definition of Scrum. The preeminent certifying bodies, Scrum Alliance and Scrum.org, coming together in support of a common definition of Scrum is a win for Scrum practitioners around the world.

 

“The pieces of Scrum are carefully fit to each other to yield the best possible results. This has taken years for Jeff and myself to achieve. Watch for new versions as we continue to refine,” said Ken Schwaber, founder of Scrum.org.

 

“It’s time for convergence in the Scrum community,” said Scrum.org’s operations chief David Starr. “Giving this clear explanation of Scrum clarifies the framework for the entire industry. We are pleased to support a shared and unambiguous source of truth defined by Scrum’s creators.”

 

Carol McEwan, Scrum Alliance Managing Director, said, “This makes the most sense for the Scrum community. The Scrum Guide is based on the principles on which Scrum was founded. It offers Scrum practitioners worldwide a common standard and understanding of the foundations of Scrum. This collaboration adds real value and can only benefit everyone practicing, or considering practicing, Scrum.”

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Evolution of a Scrum Diagram

Over the many years that I have been teaching Scrum (since 2005!), I have had a diagram of Scrum 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:

01 Scrum Process Diagram

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.

02 All of Scrum Diagram

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.

03 All of Scrum Diagram

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.

04 All of Scrum Diagram

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.

05 All of Scrum Diagram

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.

05 All of Scrum Diagram - Branded

Newest Diagram

Literally just a week ago, 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!

06 The Scrum Process

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

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Agile Advice Book Update

Well, last spring I announced that I was going to be publishing a collection of the best Agile Advice articles in a book.  I managed to get an ISBN number, got a great cover page design, and so it is almost done.  I’m still trying to figure out how to build an index… any suggestions would be welcome!!!  But… I’m hoping to get it published on iBooks and Amazon in the next month or two.  Let me know if you have any feedback on “must-have” Agile Advice articles – there’s still time to add / edit the contents.

There are six major sections to the book:

  1. Basics and Foundations
  2. Applications and Variations
  3. Agile and Other Systems
  4. For Managers and Executives
  5. Bonus Chapters
  6. Agile Methods Quick Reference and Selection Guide

The book will also have a small collection of 3 in-depth articles that have never been published here on Agile Advice (and never will be).  The three special articles are:

  1. Agile Mining at a Large Canadian Oil Sands Company
  2. Crossing the Knowing-Doing Gap
  3. Becoming a Professional Software Developer

Again, any feedback on tools or techniques for creating a quick index section on a book would be great.  I’m using LibreOffice for my word processor on a Mac.  I’m cool with command-line tools if there’s something good!

 

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

The ScrumMaster is Responsible for What Artifacts?

Organizations like to have clear role definitions, clear processes outlined and clear documentation templates.  It’s just in the nature of bureaucracy to want to know every detail, to capture every dotted “i” and crossed “t”, and to use all that information to control, monitor, predict and protect.  ScrumMasters should be anti-bureaucracy.  Not anti-process, not anti-documentation, but constantly on the lookout for process and documentation creep.

To help aspiring ScrumMasters, particularly those who come from a formal Project Management background, I have here a short list of exactly which artifacts the ScrumMaster is responsible for.

REQUIRED:
- None – the ScrumMaster is a facilitator and change agent and is not directly responsible for any of the Scrum artifacts (e.g. Product Backlog) or traditional artifacts (e.g. Gantt Chart).

OPTIONAL/COMMON:
- Obstacles or impediments “backlog” - a list of all the problems, obstacles, impediments and challenges that the Scrum Team is facing.  These obstacles can be identified by Team Members at any time, but particularly during the Daily Scrum or the Retrospective.
- Definition of “Done” gap report, every Sprint – a comparison of how “done” the Team’s work is during Sprint Review vs. the corporate standards required to actually ship an increment of the Team’s work (e.g. unit testing done every Sprint, but not system testing).
- Sharable retrospective outcomes report, every Sprint – an optional report from the Scrum Team to outside stakeholders including other Scrum Teams.  Current best practice is that the retrospective is a private meeting for the members of the Scrum Team and that in order to create a safe environment, the Scrum Team only shares items from the retrospective if they are unanimously agreed.  Outsiders are not welcome to the retrospective.
- Sprint burndown chart every Sprint – a chart that tracks the amount of work remaining at the end of every day of the Sprint, usually measured in number of tasks.  This chart simply helps a team to see if their progress so far during a Sprint is reasonable for them to complete their work.
- State of Scrum report, every Sprint – possibly using a checklist or tool such as the “Scrum Team Assessment” (shameless plug alert!).

NOT RECOMMENDED (BUT SOMETIMES NEEDED):
- minutes of Scrum meetings
- process compliance audit reports
- project administrative documents (e.g. status reports, time sheets)

NEVER RECOMMENDED:
- project charter (often recommended for the Product Owner, however)
- project plans (this is done by the Product Owner and the Scrum Team with the Product Backlog)
- any sort of up-front technical or design documents

The ScrumMaster is not a project manager, not a technical lead, not a functional manager, and not even a team coach.  There are aspects of all of those roles in the ScrumMaster role, but it is best to think of the role as completely new and focused on two things:
- improving how the team uses Scrum
- helping the team to remove obstacles and impediments to getting their work done.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Ranking: the Best and Worst Roles to Transition to ScrumMasters

So you’re trying to do Scrum well because you heard it gave you great results.  You know that the ScrumMaster role is critical.  How do you find the right people to fill that role?  Here is a list of several roles that people commonly leave to become ScrumMasters, and a few not-so-common roles as well, all ranked by how well those people typically do once they become ScrumMasters.  From Worst to Best:

  • Worst: PMI-trained Project Managers (PMPs).  Too focused on control and cost and schedule.  Not easily able to give teams the space to self-organize.  Not able to detach themselves from results and focus on the process, values and teamwork needed to make Scrum successful.
  • Bad, but not awful: Functional Managers.  The power dynamic can be a serious hindrance to allowing teams to self-organize.  But, good functional managers already are good at building teams, and empowering individuals to solve problems.
  • Bad, but not awful: Technical Leads.  Here, the biggest problem is the desire to solve all the team’s technical problems instead of letting them do it.  Now, instead of detachment from results (project managers), it’s detachment from solutions.
  • So-so: Quality Assurance people.  Good at rooting out root-cause for problems… just need to shift from technical mindset or business mindset to cultural and process mindset.  Another problem is that QA is not nearly as respected as it should be and QA people typically don’t have a lot of organizational influence.
  • So-so: Junior techies: Enthusiasm can make up for a lot of gaps and naiveté can help solve problems in creative ways, but there will be a huge uphill battle in terms of respect and influence in an organization.
  • Good: non-PMI-trained Project Managers: rely on teamwork and influence rather than tools, processes and control (of course there are exceptions).
  • Awesome: Executive Assistants.  Respected and respectful, use influence for everything, know everyone, know all the processes, know all the ways to “just get it done”. Of course, they don’t usually know much about technology, but that often turns out to be good: they don’t make assumptions, and are humble about helping the technical team!

The ScrumMaster creates high performance teams using the Scrum process and values.  The ScrumMaster is not accountable for business results, nor project success, nor technical solutions, nor even audit process compliance.  The ScrumMaster is responsible for removing obstacles to a team’s performance of their work.  The ScrumMaster is an organizational change agent.

Other things you might want to consider when looking for a ScrumMaster:

  • Does the person have experience managing volunteer groups?
  • Does the person have good people skills in general?
  • Does the person want to create high-performance teams?
  • Can the person learn anything – business, process, technical, people, etc.?

Bottom line: try and avoid having PMI-trained project managers become ScrumMasters.  Even with good training, even with time to adjust, I often find that Scrum teams with PMI-trained project managers are always struggling and almost never become true teams.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Technical Push-Back – When is it Okay? When is it Bad?

Whenever I run a Certified Scrum Product Owner training session, one concept stands out as critical for participants: the relationship of the Product Owner to the technical demands of the work being done by the Scrum team.

The Product Owner is responsible for prioritizing the Product Backlog. This responsibility is, of course, also matched by their authority to do so. When the Product Owner collaborates with the team in the process of prioritization, there may be ways which the team “pushes back”. There are two possible reasons for push-back. One is good, one is bad.

Bad Technical Push-Back

BudapestDSCN3928-smallThe team may look at a product backlog item or a user story and say “O gosh! There’s a lot there to think about! We have to build this fully-architected infrastructure before we can implement that story.” This is old waterfall thinking. It is bad. The team should always be thinking (and doing) YAGNI and KISS. Technical challenges should be solved in the simplest responsible way. Features should be implemented with the simplest technical solution that actually works.

As a Product Owner, one technique that you can use to help teams with this is that when the team asks questions, that you aggressively keep the user story as simple as possible. The questions that are asked may lead to the creation of new stories, or splitting the existing story. Here is an example…

Suppose the story is “As a job seeker I can post my resume to the web site…” If the technical team makes certain assumptions, they may create a complex system that allows resumes to be uploaded in multiple formats with automatic keyword extraction, and even beyond that, they may anticipate that the code needs to be ready for edge cases like WordPerfect format.  The technical team might also assume that the system needs a database schema that includes users, login credentials, one-to-many relationships with resumes, detailed structures about jobs, organizations, positions, dates, educational institutions, etc. The team might insist that creating a login screen in the UI is an essential prerequisite to allowing a user to upload their resume.  And as for business logic, thy might decide that in order to implement all this, they need some sort of standard intermediate XML format that all resumes will be translated into so that searching features are easier to implement in the future.

It’s all CRAP, bloat and gold-plating.

Because that’s not what the Product Owner asked for.  The thing that’s really difficult for a team of techies to get with Scrum is that software is to be built incrementally.  The very first feature built is built in the simplest responsible way without assuming anything about future features.  In other words, build it like it is the last feature you will build, not the first.  In the Agile Manifesto this is described as:

Simplicity, the art of maximizing the amount of work not done, is essential.

The second feature the team builds should only add exactly what the Product Owner asks for.  Again, as if it was going to be the last feature built.  Every single feature (User Story / Product Backlog Item) is treated the same way.  Whenever the team starts to anticipate the business in any of these three ways, the team is wrong:

  1. Building a feature because the team thinks the Product Owner will want it.
  2. Building a feature because the Product Owner has put it later on the Product Backlog.
  3. Building a technical aspect of the system to support either of the first types of anticipation, even if the team doesn’t actually build the feature they are anticipating.

Okay, but what about architecture?  Fire your architects.  No kidding.¹

Good Technical Push-Back

Rube Goldberg Self Operating Napkin

Sometimes stuff gets non-simple: complicated, messy, hard to understand, hard to change.  This happens despite us techies all being super-smart.  Sometimes, in order to implement a new feature, we have to clean up what is already there.  The Product Owner might ask the Scrum Team to build this Product Backlog Item next and the team says something like: “yes, but it will take twice as long as we initially estimated, because we have to clean things up.”  This can be greatly disappointing for the Product Owner.  But, this is actually the kind of push-back a Product Owner wants.  Why?  In order to avoid destroying your business!  (Yup, that serious.)

This is called “Refactoring” at it is one of the critical Agile Engineering practices.  Martin Fowler wrote a great book about this about 15 years ago.  Refactoring is, simply, improving the design of your system without changing it’s business behaviour.  A simple example is changing a set of 3 radio buttons in the UI to a drop-down box with 3 options… so that later, the Product Owner can add 27 more options.  Refactoring at the level of code is often described as removing duplication.  But some types of refactoring are large: replacing a relational database with a NoSQL database, moving from Java to Python for a significant component of your system, doing a full UX re-design on your web application.  All of these are changes to the technical attributes of your system that are driven by an immediate need to add a new feature (or feature set) that is not supported by the current technology.

The Product Owner has asked for a new feature, now, and the team has decided that in order to build it, the existing system needs refactoring.  To be clear: the team is not anticipating that the Product Owner wants some feature in the future; it’s the very next feature that the team needs to build.

This all relates to another two principles from the Agile Manifesto:

Continuous attention to technical excellence and good design enhances agility.

and

The best architectures, requirements, and designs emerge from self-organizing teams.

In this case, the responsibilities of the team for technical excellence and creating the best system possible override the short-term (and short-sighted) desire of the business to trade off quality in order to get speed.  That trade-off always bites you in the end!  Why? Because of the cost of fixing quality problems increases exponentially as time passes from when they were introduced.

Young Girl Wiping Face With Napkin

 

 

 

 

 

 

 

Refactoring is not a bad word.

Keep your code clean.

Let your team keep its code clean.

Oh.  And fire your architects.

¹ I used to be a senior architect reporting directly to the CTO of Charles Schwab.  Effectively, I fired myself and launched an incredibly successful enterprise architecture re-write project… with no up-front architecture plan.  Really… fire your architects.  Everything they do is pure waste and overhead.  Someday I’ll write that article :-)

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Full-Day Product Owner Simulation Exercise

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

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.

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)
  • Planning Game cards (email me if you want a bunch for free!)

Room Setup: Round tables with 4 to 6 chairs at each table.  Materials distributed to each table.

Agenda (with facilitator’s notes):

  • 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. Review the agenda with participants.
  • Discussion: Choosing a Product for the Simulation
    Give participants four product options (suggested options: “Doggy dating web site”, “iPad app for plastic surgeons”, “POS for food trucks with social features”, or come up with your own app idea).  A table group must agree to one of the options.  They will stick with this product for the remainder of the simulation.  5 minutes to decide (usually takes much less).
  • Part 1: Product Vision
    • Lecture: Innovation Games – 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
  • Part 2: Product Users
    • Lecture: User Categories
      Describe “end users”, “customers” 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 (end, admin and cust), at least 5 users in total.  More is okay.
    • 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.
  • Part 3: User Stories
    • Handout: User Stories and Splitting
    • 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.
    • Exercise: Create User Stories
      Goal: 20 user stories for each group’s product, at least two user stories for each 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.
    • Discussion: Review User Stories
      Workshop examples from each group.  Ensure that the “benefit” section of each story does not contain a feature.
    • 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.
    • Discussion: Review Splitting
  • Part 4: 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
    • 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
    • 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
    • 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 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!

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

The Agile Framework: Agile Values and Principles, The Agile Toolkit, The Agile Organization

When I am speaking with executives, ScrumMasters and other leaders of change in organizations, I often present a simple 3-layer model to understand the relationship between the various moving parts in the Agile Framework:

  1. The Agile Values and Principles – These describe the culture and, in the Agile Manifesto, are the definition of the word “Agile” as applied to software development. I didn’t write the Agile Manifesto so I don’t get to re-define the word Agile.  To give an example: in the manifesto it says “The best architectures, requirements and designs emerge out of self-organizing teams.”  As a former enterprise architect at Charles Schwab, I struggled with what I saw as incredibly wasteful up-front architectural activities when I knew that developers would (sometimes) ignore my glorious ivory-tower plans!  Therefore, if you are still doing up-front architecture and forcing your teams to comply to that architecture, you aren’t Agile.  Therefore, as an individual, a team or an organization, you need to make a conscious decision to “BE” Agile or not… and if you decide not, then please don’t call yourselves Agile.
  2. The Agile Toolkit – There are many hundreds of distinct tools in the Agile toolkit including Scrum, OpenAgile and other “large” Agile methods, as well as the Planning Game, Product Box, Test-Driven Development and other “small” Agile techniques.  Any group of people trying to BE Agile, will need to use dozens or even hundreds of different Agile tools.  I call them tools because the analogy with construction tools is a very good one.  Scrum is like a hammer.  But you can’t do much with just a hammer.  Scrum is a great, simple tool.  But you always need other tools as well to actually get stuff done.  All the tools in the Agile Toolkit are compatible with the Agile Values and Principles.  Even so, it is possible to use the Agile Tools without being Agile.  A Scrum team that never gets together face-to-face is not an Agile team: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”  (Video conferencing doesn’t count.)
  3. The Agile Organization – When you start using a tool, there is a learning period.  We start by being conscious of our incompetence and as we persist, we become competent… but it isn’t natural or habitual yet.  Eventually, with continued use, we become unconscious of the tool.  IDE’s and version control are like this in most organizations: we don’t even think about them!  But getting through that initial stage requires us to change; to develop new skills.  This process usually requires discomfort or pain (including psychological pain).  An organization attempting to BE Agile and to use many of the tools in the Agile Toolkit will need to make many changes and often these will be difficult.  For example, incorporating the Product Owner role from Scrum into your organization requires new role definitions, new performance evaluation practices and criteria, new compensation systems, new communication and reporting mechanisms, new authority and accountability processes, etc. etc.  All of the changes required are about creating Enterprise Agility throughout the whole organization, beyond just software or IT.  These extensive changes are often started in a very ad hoc manner, but at some point they need to become systematic.  This is an important decision point for executive management: are we going to be Pragmatic about our Enterprise Agile adoption, or are we going to be Transformative about our Enterprise Agile adoption.

All of this is summarized in this graphic:

The Agile Framework [PDF]

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Super-Hard ScrumMaster Quiz – Test Yourself!

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!

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Project Lessons Learned vs. Sprint Retrospective – 17 Points of Comparison

Another fantastic article by Mike Caspar: Sprint Retrospective vs. Lessons Learned (a Generalization)

Mike says:

Consider reviewing these differences in your environment to determine if you are getting benefit from your Sprint Retrospectives and following their intent.

 

Here are a few other Agile Advice articles about Retrospectives.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Re-launch of Real Agility Newsletter

Hi Everyone!  Berteig Consulting is going to re-launch their monthly newsletter starting this month!  We’re excited about it because, although it is partly due to a legal change around commercial email here in Canada, we are considering this a great opportunity to change the style of our communication with our customers and our colleagues.  Like before, we plan to have a few regular segments:

  1. A message from me, Mishkin Berteig, that shares my personal experiences with Agile, with running an Agile consultancy, and other things that I hope will be interesting.
  2. A “Coaching Corner” article written by one of our coaches, or by a guest author, about how organizations, teams and people can become more Agile.  Topics will range from technical to people-oriented, practical to theoretical, cutting-edge to deeply retrospective.  We hope these articles will become a great resource – and they won’t be cross-posted here on Agile Advice.
  3. A listing of our upcoming training.  We’re excited that in the fall and in the new year we are going to start offering some things besides just ScrumMaster and Product Owner training including training on Agile Coaching, SAFe (and maybe even other enterprise agile frameworks), and topics closely related to Agile such as leadership, communication, etc.
  4. And of course, a “special offers” section that will promote new products or services from us or from close partners that we think will be helpful.

Please subscribe to our Real Agility Newsletter by clicking on the link:

SUBSCRIBE

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Retrospectives: A Quick Random Retrospective Generator

Thanks to my good friend Deborah Hartmann Preuss for showing me this great tool: Retr-O-Mat – Inspiration (and Plans) for Agile Retrospectives.  It’s a great way of generating a plan for your retrospective if you’re feeling a lack of inspiration!  Includes all five stages of a retrospective: set the stage, gather data, generate insights, decide what to do, and close the retrospective.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

The Three Fundamental Principles of Agile Estimation – The Third One Will Surprise You!

You probably already use an Agile Estimation technique such as the Planning Game or the Bucket System, but surprisingly few people understand the underlying principles of Agile Estimation.  This lack of understanding often causes confusion or stress for the people who try to use Agile Estimation techniques.  The discrepancy between traditional estimation techniques and Agile techniques is large and it is hard to bridge that mental gap without understanding the principles involved.  There are three fundamental principles of Agile estimation:

Principle One: Collaborative

Agile estimation methods are collaborative.  This means that multiple people work together to arrive at estimates for work in an Agile project or product development effort.  Traditional estimation techniques (such as those related to bottom-up or top-down) tend to focus on individuals estimating the work that they are responsible for doing and “trusting” those individual estimates.  Collaborative estimation means that most estimation is done by people in formally facilitated meetings where people are present in-person.

Collaborative techniques are generally used where there is some expectation that multiple minds are better than a single mind in discovering some new knowledge or solving a problem.  Teamwork and groupwork are based on this concept.  This idea of collaboration for problem solving is also applied to Agile Estimation and it has some interesting ramifications.

The most radical consequence of collaborative estimation methods is that there is no possibility to trace a particular estimate for a particular item to a particular individual person.  This lack of traceability is important to create a sense of safety on the part of participants in the estimation effort.  This safety is necessary to allow participants to be fully honest about estimates even if those estimates conflict with expectations of powerful stakeholders.  Another way of stating this principle is that no individual can be punished for a bad estimate.

Many Agile estimation techniques take this principle beyond just mere collaboration to the level of consensus-building techniques where everyone in a group doing estimation work must agree on the final estimate for each and every item being estimated.  This strengthens the idea of safety to the point where no participant in an estimation effort can ever say “I didn’t agree with that” and thereby leave other participants “on the hook” for a bad estimate.

Principle Two: Relative Estimation

Imagine you are shown a glass bottle with some water in it.  You can see the water sloshing around.  Someone asks you, “how much water is in the bottle?”  You might, at first, think about the overall size of the bottle and respond by saying “it’s 1/3 full.”  Or, if asked to provide a measure in units like millilitres or fluid ounces, you might mentally compare what you see in front of you to some container (e.g. a measuring cup) where you know the quantity.  In both cases, you are doing a relative estimate of the amount of water in the bottle.  You are comparing the amount of water to a known quantity.

Imagine a counter-example: someone walks up to you with a red pen ask asks you “what is the wavelength of the light being reflected from this red ink?”  If you are like most people, you have probably forgotten (if you ever knew) the wavelengths of light in the visible spectrum.  You have no basis for comparison.  You might take a wild guess, but it is just that.  Going back to our relative measure, you might be able to easily say if it is darker or lighter than another red colour, or you might even be able to tell what hue of red it is.  But those cases are, again, relying on our inherent ability to see relative differences.

So instead of ignoring this capacity, in Agile estimation techniques, we leverage it.  When estimating effort, we start by setting a clear baseline for what we are comparing: another piece of work.  The baseline piece of work is often given an “estimate” that is arbitrary and in some non-standard units.  For example, it is common to use “points” when estimating the effort for Product Backlog Items.

When doing relative estimates it is very important to ensure we are comparing “apples to apples”.  Both the piece of work to be estimated and the comparison piece should both be work items that are not yet done!  If you have already completed one of the pieces of work, you have prior knowledge that you don’t have for the work to be estimated.

This last point is subtle, but important.  If you have already done something, you know much more about it.  If you try to compare to something you haven’t yet done, you will be tempted to assume that the two things will be more similar than they may be when you actually get to work on it.  By comparing two pieces of work that you have not yet done, you become much more conscious of the risks of comparing, and that consciousness will help you make better relative estimates.

It is important to note that one side advantage of using relative units for estimation is that it makes it much more difficult to use estimates as a baseline for either measuring performance or for tracking schedule variance, both of which are essentially meaningless in a good Agile environment (which should be almost entirely results-oriented).

Principle Three: Fast

In Agile estimation we don’t care (!!!) about accuracy nor about precision of estimates.  Whoa!  Why is that?  Because estimation is waste.  You can’t sell estimates, and estimates don’t affect the “form, fit or function” of the thing you’re building.  Therefore, both Agile and Lean concur: do your utmost to eliminate that waste.  There are actually lots of Agile practitioners who think estimates are evil (and they have some good arguments!)

In order to do Agile estimation in a maximally non-evil way, we need to make estimation fast!  Really fast!!!  Many of the Agile estimation techniques allow you to estimate a product release schedule lasting as much as a year in just a few hours given a reasonably well-crafted Product Backlog.

There are really only two modestly good reasons for doing estimation in an Agile project or product:

  1. Estimates provide simplified information to the Product Owner to allow him/her to make sure the Product Backlog is ready for the next Sprint (ordered, refined).
  2. Estimates allow stakeholders, including the team doing the work, to generate high-level common understanding and expectations without dwelling on details.

As a business stakeholder, one can do a simple mental exercise.  Ask yourself, “how much money would I be willing to spend to accomplish those two objectives?”  Whatever your answer, I hope that it is a very small amount compared to what you are willing to spend on getting results.  If not, perhaps you haven’t really embraced the Agile mindset yet where “the primary measure of progress is working software” (the Agile Manifesto).

Bonus Principle: We Suck at Estimating

Most people doing estimation in traditional project management try to measure in units like person-days or dollars.  There is no doubt that these units are useful if you can get good estimates.  However, most of the people doing estimation are fundamentally and irredeemably bad at it.  How do I know?  Because they are not wealthy… and have thereby proven that they cannot predict the future.  If you can predict the future, even just in limited circumstances (like estimating effort or revenue), you can leverage that to generate almost untold wealth.  Given that, it is fruitless and wasteful to try to get better at estimating.  Instead, the principles of Agile estimation help us focus our attention on the right things: collaboration, comparative estimates and doing them fast so we can get to the real work, and most importantly: delivering valuable results now.  Understanding these principles helps teams overcome many of the struggles they have in using Agile estimation techniques.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail