Friday, October 9, 2015

10 Warning Signs, that your team is not self-organizing

How do you know that self-organization is working? The Bern Chapter of Scrum Breakfast Club looked into this questions, and identified the following warning signs (which I have taken the liberty of translating).

  1. The team reports to the Scrum Master at the Daily Scrum
  2. People wait for instructions from the Scrum Master
  3. Team members don't hold each other responsible [for their commitments]
  4. The same impediment comes up twice
  5. "That's the way it is" => resignation
  6. "I" instead of "We"
  7. Flip charts are lonely
  8. Culture of conflict-avoidance
  9. Decisions processes are unclear, nor are they discussed
  10. Personal goals are more important than team goals

To this list I would add my a couple of my favorites:
  1. you don't see a triangle on the task board (not working according prioritization of stories)
  2. after the daily Scrum, people return directly to their desks (no collaboration)
  3. there are a least as many stories in progress as team members (no pairing)

P.S. You can join the discussion or solve your own challenges at a future event! And here is the original list (in German).

EDIT: Here is the second slide:

  • Retrospectives are superficial
  • Agile Mindset Not Present => No inspect and adapt
  • The Team has no influence on the backlog (order, content, priority)
  • The Team is not interested in improving their performance
  • Changes in Team Composition are not managed by the Team
  • New members are not introduced by the whole team
(Suggestions for improved translation are most welcome!)

Wednesday, August 12, 2015

10 tips for doing Scrum when you're decentralized, part-time or doing other stuff you're not supposed to do

How do you use Scrum when you're
  • integrating existing packages, not developing software
  • deploying a visual design
  • working with a decentralized team
  • working with a part-time team?
The new Scrum Breakfast Club portal is based on Wordpress and who knows how many plugins. My part-time "team" and I have been working on this project for about 6 months. Calling us a team might be a bit optimistic, because we were:
  • 5 part-time people, 
  • located in two countries (6 hours apart)
  • working no more than 40% on the project
  • working for five different companies, and
  • only 2 people have been involved for the entire project.
Despite these obstacles, we did produce a cool product (IMHO) and we enjoy working together (also IMHO)!

As we have gone through process of creating Wordpress-based web presences using Scrum, I have learned a couple lessons which I will carry forward.
  1. Produce something that works every week. This is a wonderful constraint which prevents both individuals and the project as a whole from wandering off.
  2. Do functionality first. It's easier to get the design right when you know what the system is supposed to do. You may even iterate on your target audience, which would cause the design to change.  A good design requires understanding the deeper why of your system or product and its customer and users. Especially in a startup context, it may take awhile for that to emerge.
  3. You can iterate on design. An excellent template architecture is a helpful, so most of the changes are in CSS. In our case:
    • Version 1 focused on functionality only. It had just enough design, standard templates really, so that we could work with the system. 
    • Version 2 was slightly embarrassing, but more or less attractive. People could work with it, but there was some stuff that was bad or downright evil in design or usability. 
    • Version 3 - what we are about to publish - is something for the public, and even here, we are implementing it in iterations 3.1, 3.2, 3.3 etc. We designed for the overall goal (market, usability). We started implementing and deploying with the most visible pages. Then polish and minor pages.
    • Don't break stuff that already works. 
    • Postpone activating design elements that require new functionality, until the corresponding functionality is present. For example, we want to do some fancy pop-open login and registration widgets, but those are going to wait until we can implement them.
  4. Trello is your friend for communication. Trello is nice lightweight Kanban board. Our workflow is basically: Backlog->Ready->Forecast->In Progress->Ready to Review->Ready to Deploy->Done. We use tags, columns and email notifications to enable rapid and effective communication throughout the team.
  5. Focus on getting things done. We agreed to always pull from the rightmost column on the board. Spillover, is almost always sign of something bad. The story might be too big; the acceptance criteria might not be clear; the team member might be working on something else. or the team worked on it at the last minute. 
  6. Grow up, then grow out. First we added functionality to Wordpress, often in the form of a new plugin. Then we discovered what we broke. Since many plugins are poorly documented, and the interactions between them even less so, we couldn't always prevent things from breaking. So we fixed everything we could find before moving on to new functionality. Basically a stop the line mentality. In Trello, we added a column "Bugs" and tagged the items in yellow. If a bug was present, it was handled with top priority. This is getting things really done!
  7. Definition of ready is your friend for getting things done. For each column in our Trello workflow, we created a permanent card with the definition of ready to enter that column. To enter the Ready column, each story had to have a how-to-demo checklist. This makes it much easier to know how to implement the story and how to confirm that we have achieved the goal during the Review. To leave Ready and enter the Forecast column, the team (member) had to be confident they could get the story by the end of the sprint.
  8. Do the work at the beginning of the sprint. Did I say get stuff done? Get it done early. The biggest danger with part-time staff is that they work on other things until they feel they can't postpone your stuff any longer. If they do their 20% on the first day of the sprint rather than the last, their chances of getting stuff done are much higher! Getting stuff done also removes a major source of tension between the players in the project.
  9. Wordpress is the friend I love to hate. There is plugin for that. Yes, and the interactions between those plugins can be quite unpredictable. It enabled us to get started quickly, but I suspect before our product is done we will have reimplemented all of the key plugins to suit our needs. I'm not complaining, because my site is live and I can generate potentially revenue to pay for that development.
  10. Automation is your dearest friend. This includes virtualization, backup and source code control. Yesterday, a system programming error during the sprint review managed to destroy all three instances of our system. Embarrassing, but...  We recovered the system by creating a new virtual machine on linode from the daily backup, restored the Wordpress configuration (database) from the daily Updraft Plus backup, and the current file configuration from the source code control. 45 minutes later we were back online and there was no impact on our schedule. If fact, we are actually deploying a week earlier than I had hoped! We will also get better reliability, because this incident convinced us to separate test and production on separate nodes.
As a final thought, for me as Product Owner (and entrepreneur), Sprint Planning is an opportunity to ask:
What is the best possible step forward for the business, given what I know today?

The answer might not be software development. I ask myself that question every week, and it really helps me to do the right thing!

Monday, July 27, 2015

Is your Scrum User Group really a user group?

Ken Schwaber recently chided the Scrum Alliance for having a trademark on the term "Scrum User Group." Man! There is something about the way divorced couples can fight forever through their kids. I'd like to ignore the couple for a moment, and talk about the children: What is the state of user groups in the Scrum and Agile community?

After a period of working too hard, I have been able to attend a few user group meetings this year. A couple of patterns have stood out for me. Patterns that don't feel right, but maybe I am exaggerating? Do you recognise any of these?
  • The user group is associated with an agile consultancy.
  • The user group event starts with some promotion of said consultancy.
  • The user group doesn't have a website or even a meet-up page.
  • The user group website is mostly promoting high-value courses.
  • Membership is free (just sign up for our mailing list).
  • The user group event is mostly attended by beginners 
  • The only really experienced Agilist present is the group's host.
  • The user group events are mostly talks by managers, coaches or trainers (in other words, they are a form of self-promotion).
Is a user group more than a marketing arm of a consultancy? Or am I being too harsh? What is your experience with Scrum user groups? What do you think a good user group should be?

Tuesday, July 7, 2015

What powerful questions does Scrum help you answer?

The video on powerful questions made me think about the deeper purpose of the various Scrum activities. Can I formulate Scrum as a series of Powerful Questions to be general enough, that they might be useful outside of software development? Here is the image I came up with and below are the questions I think each of the Scrum Activities and artefacts strives to help you answer.


  • The Sprint is a container to limit ourselves to setting reasonable medium-term goals. 
  • What can we reasonably expect to accomplish by the end of the sprint?


  • How will our efforts make the world a better place?
  • Who needs our product and why?
  • Why should we build it?

Product Backlog

  • What characteristics should our product have?
  • What goals must we accomplish to achieve our vision?

Backlog Refinement

  • What could we do to get us closer to our vision?
  • What small steps could take us nearer to our goal?
  • How can we make the steps smaller and more likely of success?

Sprint Planning

  • Part 1 - What is the best possible step forward, given what we know today?
  • Part 2 - How can we accomplish these steps?

Daily Scrum

  • What are our goals for the day?
  • How will we accomplish them?
  • What help do we need?
  • Who needs to talk about what?
  • What could be slowing us down?

Sprint Review

  • What have we accomplished or learned?
  • How does this change our vision?


  • How can we work more effectively?
  • What could be slowing us down?

Definition of Done

  • How do we know a step was successful?
  • How do we ensure the quality of our work?
  • How do we know that what was done in the last sprint is still done in this sprint?

Monday, July 6, 2015

What is a powerful question?

Have you ever noticed that some questions cause people to pause and think before answering, while others provoke an automatic, non-constructive response? What's the difference?

Powerful questions challenge you to think deeply and often help to get unstuck and find solutions to your difficult, challenging problems.

At the Product Owner Camp #POcampCH in Sursee Agile Filmakers extrrodinaires Karen Greaves and Sam Laing led our group through the creation of a short educational video on Powerful Questions.

In one hour, we learned about Powerful Questions, the 4-C's teaching method, (Connection, Content, Concrete Examples and Conclusions) and how to make an attractive educational video.

Thanks to Karen and Sam, plus Deb Hartmann, Véronique Hyde, and Yves Bertrand for a great collaborative learning experience!

Saturday, May 9, 2015

More tips for CST Aspirants

What does it take to become a Certified Scrum Trainer (CST)? Passion and Energy. You should stand out from the crowd!

Aspirant: How high do we have to climb?
TAC: What we really want is someone who can leap tall buildings in a single bound!
The Scrum Alliance Trainer Acceptance Committee held its first ever workshop for CST Aspirants last week at SGPHX, the Phoenix Scrum Gathering. This gave candidates a chance to ask questions and understand what is really expected of a CST to get through the final examination.

The answers to two questions really stood out for me in this workshop:

  • Why do I have to submit my own learning materials?
  • How many students must I have taught?

Why do you have to submit your own learning materials?

Many Aspirants today work for a company that has already created a "deck" for teaching Scrum. I am told that even requires their trainers to train to a standardized deck. Why reinvent the wheel? 

If an Aspirant is using someone else's materials, here is a typical conversation during the final interview:
  • Examiner: What does this diagram on page 35 mean?
  • Aspirant: <dances around the question without really answering it>
  • Examiner: Try again. What does it really mean?
  • Aspirant: I'm not sure. It's something the company put in, but I don't really use it in my course.
A CST must know their stuff! A CST should not be training materials that they do not understand or support fully. If you don't create it, it's almost impossible to learn it well enough to teach from it effectively and without blind spots.

How many students must you teach?

The Scrum Alliance requires an Aspirant to have taught at least 100 students in CSM-like context (2 day course). This should demonstrate that you are capable of doing the job of a CST. 

Does training 100 students guarantee that you will be accepted? No.

The Scrum Alliance wants its trainers to come from the top 1%. That top 1% are the people who motivate and convince others to want to do Scrum and do it well. You're job is to convince the TAC that you belong there already, so all they have to do is recognize your accomplishment!

A CST is not merely a trainer. A CST is an ambassador of Scrum. So the criteria on the Scrum Alliance website are perhaps best to be understood not as acceptance criteria, but as exclusion criteria. If you don't meet these criteria, don't bother applying. If your objective is simply to satisfy the absolute minimum requirements necessary, then you probably haven't understood what being a CST is really about, and are therefore unlikely to pass.

What does it take to become a CST?

Above all else, perseverance! Don't give up. Not everyone makes on the first try. I needed four tries, an extreme case, to be sure, but many need two tries to get through, and some very good trainers even needed three. Passion, energy, and perseverance! 

P.S. To my padawans who came up for evaluation in Phoenix: Congratulations and high fives to Joe Justice! Joe needed two tries to get through. And to Lizzie Morris, I say don't give up! Both of you are awesome trainers who deserve to be recognized as such!

P.P.S. Are you a CST Aspirant? If are on the path to becoming CST, check out our network

Tuesday, May 5, 2015

Tips for CST Aspirants

So you want to become a Certified Scrum Trainer? What does it take to become a CST? I facilitated a workshop at the Phoenix Scrum Gathering (#SGPHX) on the challenges of becoming a trainer. Several people shared their experiences, including current and former members of the TAC (Trainer Acceptance Committee) and Tirell Payton, a Certified Scrum Coach whose first attempt at passing the TAC was not successful. 

Tirell wrote the following summary, which I thankfully quote:

During the retreat Peter Stevens facilitated a session on the CST process and some of the potential pitfalls the aspirants encounter as they go through the process.

I acted as the scribe and town crier, and as such lots of people have come up and asked me for my list of items.  The items on the list follow 2 key dimensions:  The common items that lead to candidates not being accepted and advice for how to make it through the process with your sanity intact.

For those of you on the list, hopefully these items will be helpful to anyone you're mentoring through the process.  Tomorrow at the gathering if anyone has any questions on these items, I am willing to give advice and share my experiences.

Some of the items that are a challenge for applicants:
  • Knowledge.  Know your stuff backward and forward.  Even better, be able to communicate it clearly and succinctly
  • Community Involvement.  The TAC really likes to see a breadth of community involvement
  • In person techniques.  Context matters, be mindful of the fact that when you are in front of the TAC review, some techniques that work very well in the context of a 2 day training course may not work well at all in your TAC panel session.
  • Personal Statement.  The TAC wants to understand how you will make an impact as a trainer. Becoming a CST is just as much an affirmation of your passion and commitment as well as a platform for you to go on to greater heights.  How will you change people's lives in 2 days?
  • Co Training.  The TAC wants to see very good evidence that you have co-trained with CSTs.  Yes its difficult, yes its hard to coordinate schedules, but its very worthwhile.  Co-training depends your connection with your training community, spreads effective techniques, and provides an opportunity to observe stylistic differences.

Some of the advice from the session:
  • Don't give up.  If you don't get through on the first try, understand you are not the first person that this has happened to.  
  • Be accepting of feedback.  Listen.
  • Treat it like a job interview with the same level of professional discipline and focus
  • Ask and ye shall receive.  Make yourself visible in the community.  Help.  Enlist others to be co-conspirators in your success.