Friday, April 29, 2016

Working towards my Personal Scrum

Two weeks ago I read an article that changed how I organize my life.

I have a problem. Despite teaching people and organizations how to organize their work effectively, how to prioritize, about the evils of multi-tasking and the importance of sustainable pace, I have never been able to get my own to-dos under control. By extension, my life has never really been under control either. So I often work late into the night, almost every night, and on the weekends as well.

I have experimented with the Pomodoro (I could never get myself to stop working after 25 minutes. I want something done before I can put it down) and Personal Kanban (post-its with waiting-working-done around the screen of my notebook (the problem wan't the WIP but the length of the backlog). The results of my attempts was always the same: I worked very hard, getting things done one after the other, but my work schedule always extended into the night and over the weekend.

An experiment with timeboxing tasks/goals

Two weeks ago, a read an article on linked in, Critical Things Ridiculously Successful People Do Every Day, by Travis Bradberry. His first recommendation: "[F]ocus on minutes, not hours." Enter your program in your agenda. A light went on. If I am going to do something, the first question I must answer is when am I going to do it? Then I block the time for that activity. What happens if I don't have time for it? Either postpone it, don't do it, or cancel something else.

So I decided to try an experiment. For one week, I would schedule every major activity I needed to accomplish. From Sprint Planing for the SBC website, to quotes I needed to send customers, a talk I needed to prepare, to packing for my trip to the Scrum Gathering. Everything went into my calendar. Looking back on it today, I see that I had 30 individual items over five days. Only once did I schedule work into the evening.

What happened? The good news: Friday morning, when it came time to leave, my wife said, "it's time." I said, "OK," put my suitcase in the car, and off we went. On the way, she said to me, "I have never seen you so organized and ready for departure before a trip like this!". (And I hadn't even told her about my experiment!). I accomplished every major goal I set for myself that week (except one). And I had time to watch 4 hours of amateur Star Trek videos on you tube without feeling guilty! Wow.

The bad news. My estimates suck. It starts with the assumption that 30 minutes every morning is enough to deal with routine emails. So I had to deal with that.

Having a schedule in my calendar, and new goal starting half an hour from now, has proven to be an interesting attractor. It reminds me to focus my attention on the right thing. I can look at my calendar and see what I should be doing.

If I get to the end one time box, and the goal has not been achieved,  I have to ask myself the questions, what do I do now? Do I keep working on my current goal? Or do I schedule the remaining parts for later? Or do I cancel or postpone the next goal?

Depending on the situation, I have already done all of these. Remember, I said there was one major goal I did not accomplish? Well, I got to the time when I was supposed to start it, but I was nowhere near finished the previous goal. I evaluated the importance of the two goals and decided that it was more important to finish the goal I that I was working on. So I finished it and dropped the other one (urgent but not important). So timeboxing individual goals enables me to prioritize and ensure that the most important things get done. After a week of this, I was pretty happy with my results.

What does this have to do with Scrum? 

For me, Scrum consists of 6 essential patterns:
  1. Inspect and Adapt at regular intervals
  2. Produce something that might be valuable at least once per interval
  3. Management leads and supports, and knows when to stay out of the way.
  4. The whole team solves the problem
  5. One voice speaks for the customer/maximizes the value of the work done
  6. A coach helps everybody achieve higher performance.
How does planning my time on my calendar in this detail get me closer to doing Scrum? Let's look at how this implements the patterns:

Inspect and Adapt at regular intervals.
Produce something that might be valuable at least once per interval

First, I have stopped calling it task planning. I allocate time to achieve a goal, not perform a task. So I keep focus on the fact that my work should produce value. At the end of a time box, I hope that the goal will have been achieved. If not, that is the moment to Inspect and Adapt. I allocate time in Pomodoros (units of 30 minutes, including a 5 minute break). Nothing takes less than one Pomodoro, and I never block more than 4 consecutive pomodori for a goal. Often I achieve my goal. Sometimes I don't. That is when inspect and adapt is really helpful!

The whole team solves the problem

This one is actually pretty easy. I am the whole team. 

Management leads and supports, and knows when to stay out of the way.

I don't think this is really relevant in my context. I am basically a one person company. Not much of a management layer. :-)

One voice speaks for the customer/maximizes the value of the work done

This one is a bit tougher. Can I effectively be my own product owner? I think so, but I am going to keep an eye on this one. I started to set longer term goals by allocating time further in the future to achieve them. Aside from managing time I am not yet managing a formal backlog. 

A coach helps everybody achieve higher performance

Is it possible to be my own Scrum Master? I don't think so. An essential aspect of being a Scrum Master a Scrum Master is the independent perspective. On the one hand, I don't feel like I have systematic impediments. On the other, how do I know that I am focussing on the right goals? How do I know that I am working effectively? I think there needs to be second person involved.

Next experiments

This week, I will continue with the approach. I have also asked my wife to play the role of Scrum Master and I'd like to add a Sprint Planning/Review and maybe even a retrospective. Hmm, that means scheduling time for it...

My Personal Scrum, v0.1

How am I doing Scrum for myself?
  1. When I decide I want to achieve a particular goal, I also decide when I will work on it, and block that time in my agenda
  2. If I have no time to work on a new goal, I have to either postpone the goal, reject the goal, or reschedule or renounce another goal
  3. I strive to work on / that which  is planned at any given time
  4. I know my estimates suck, so I leave slack in my agenda and forgive myself if things don't get finished when I hoped/expected.
  5. My agenda serves me, not the other way around. So if reality is different than plan, I adjust the plan to reflect reality.
Do you have a personal Scrum? How does it work? I'd love to continue an exchange on how I as an individual can organize myself.

Wednesday, March 2, 2016

What would a Teal contract look like?

As I started the Scrum Breakfast Club, I quickly realized that the SBC should be a Teal organization. Two reasons: First, we have an overriding vision to help people transform their worlds through Scrum and related practices, frameworks and mindsets. 2) The SBC should create value for all its participants, i.e. members, chapter hosts and yes, yours truly as founder of the club.

The SBC is at its essence a franchise model. Independent Chapter hosts organize workshops in their regions under the banner of the SBC. But it should be a Teal franchise not an Orange franchise. How is that different?

I discovered one aspect where things must be different: Contracts (or should I call them "Agreements"?) The first thing I created were simple terms and conditions for regular members. Then I needed an agreement between the chapter hosts and the club. Then, as the club grew, I discovered the needs to expand the members agreement.

The most challenging was the Chapter Hosts agreement, because it was very complex and well, money was involved. I used as a model another franchising agreement that I am familiar with. Unfortunately the language of this contract (probably like most contracts) is the language of Orange, which among other things means the language of command and control. This produced quite a dissonance between my goal and purpose of creating a collaborative organization and the language of control present in the contract.

My second iteration on the member terms and conditions went better. I realized the purpose of the T&C was to answer questions about the relationship between the members and the breakfast club. Why not phrase the T&C as and FAQ? So I used that as a format. And I think it produced a much friendlier agreement. (You can see the SBC Terms and Conditions here). Following the advice principle, I published it as a draft on our forum. I received some minor feedback as was able to publish it without further discussion.

We are no rolling out a bit more formalism on the Members Agreement - we now keep better track of when people accept it. One small innovation, if you don't accept the T&C, you can give us direct feedback about why not, with the T&C directly visible on the screen. While one still needs to accept the T&C to get access, we see the agreement as a dialogue.

What are my learnings so far? I believe:
  1. Teal organizations need Tealish agreements
  2. Contract language needs to be reinvented. And FAQ might be a suitable form. 
  3. Participants of Teal organizations need dialogue. With many to one relationships there are some challenges here, but I believe the first step is enabling a bi-directional communication.
What are your experiences with Teal and agreements? 

Monday, February 1, 2016

What's the difference Scrum or Kanban?

Scrum or Kanban, that is the question that keeps coming up! But is it really an either/or question? Some people would have you choose. I believe they are complementary approaches and a pragmatic approach is to use each when appropriate. Let's look at what is Kanban, what is Scrum, and how they are similar and different.

Here's the short answer:

Both are reflective and adaptive. Kanban is focused on limiting work in progress whereas Scrum limits the time you can spend on a problem before you have to produce a result. If your product were a car, Scrum would be saying check your oil and tire pressure every month, and Kanban would be the warning lights on the dashboard that turn red when something is amiss. Both the maintenance intervals and the warning lights have value, and it would be silly to ignore either one.

Here's the long answer:

If I remember David Anderson's Kanban course correctly: Every sentence has a subject, a verb, and an elbow directed towards Scrum! OK, I exaggerate slightly ;-) Let's look at this more closely...

What is Kanban?

The purpose of Kanban is to create a culture of continuous improvement aka a "Kai-Zen Culture".  Kanban does not define a destination, but rather strives to create a culture that is willing to improve.

This essence of Kanban can be summed up in three steps:
  • Don't change anything. Change causes fear. Respect people and their roles. So leave existing roles and processes unchanged.
  • Agree to get better.
  • As a first step to improvement, visualize your work flow.
Visualization will enable you to see where things are getting stuck. When people see things are getting stuck, intelligent people people will generally do something about it. Limiting WIP creates a signaling mechanism, which is usually missing in Waterfall, to limit requests upstream and smooth out the flow.

I believe Alistair Cockburn phrased it this way: Kanban is reflective and adaptive, with reflection and adaption primarily triggered by examining the state of work.

What is Scrum?

Scrum is a simple, team-based framework for solving complex problems. Scrum is based on successful patterns for developing products. Scrum implements a small set of patterns:
  • Inspect and Adapt at regular intervals
  • An interdisciplinary team solves the problem
  • The team produces something the customer might value at regular intervals
  • One voice speaks for the customers and stakeholders
  • A coach helps the team and the organization get better
In the words of Alistair Cockburn: Scrum is reflective and adaptive, with reflection and adaption primarily triggered by time-boxing.

How are Scrum and Kanban similar?

Both are reflective and adaptive. Kanban is focused on WIP whereas Scrum uses Time-boxing. If your product were a car, Scrum would be saying check your oil and tires every month, and Kanban would be the warning lights on the dashboard that turn red when something is amiss.

When I listened to David Anderson talking about his case studies, I thought a mature Kanban team is surprisingly similar to a mature Scrum team. What the Scrum Community call sprint planing and review takes on a strategic character, features get done during the sprint., not just at the end of the Sprint. Stories need to be trimmed to size. Scrum has sprints, Kanban has "cadence." You can even limit WIP in a sprint.

How has Kanban influenced my teaching of Scrum?

I have recognized a couple of things:
  1. The easiest route to change starts with an agreement of the parties involved.
  2. If people look at how they work today, its well represented by Kanban
  3. If people think back to their best projects, they find a lot of commonality with Scrum. This recognition creates often creates a willingness to try Scrum.
  4. As it is primarily an attitude and a visualization tool, Kanban is applicable in some contexts where Scrum is not.
  5. As it is primarily an attitude and a visualization tool, Kanban does not directly address the people issues, especially at the team level.
If we consider our goal is to reach some mountain top called "High-Performance," then both Scrum and Kanban represent (I wish I could find and quote the coach who first made this analogy in a video -- can someone help me?). I believe Scrum represents are higher base camp than Kanban, but Scrum is not the destination, just a starting point.

I have found it most effective to consider Scrum to be a "reference implementation." No one will ever do it exactly like it is in the book, but they should do their best to get as close they can to the reference at the beginning. As they master it, their local improvements may very well take the team away from pure Scrum (think Spotify), but if they are inspecting and adapting frequently, it's OK.

By considering Scrum a point of departure, rather than a Nirvana to be achieved, we take away much of the pressure for compliance. This concept of Scrum as a standard to optimize from rather than a process to adhere to brings it philosophically in alignment with Kanban.

So I don't see an either-or. I use Kanban. I use Scrum. Let's get some work done!

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.


Sprint

  • 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?

Vision

  • 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?

Retrospective

  • 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?