Tuesday, May 24, 2016

Looking for an Agile Developer

As Product Owner for the Scrum Breakfast Club, I want an Agile software developer,  At the Scrum Breakfast Club, our goal is to enable people and companies to become Agile. We need some software to help us make that happen. How do you find an Agile Developer?

When I have looked for a development partner in the past, I have always started what skills, passion and personality am I looking for. Here is what we hope to find for this project:

  •  We need to be able communicate in English. (I have tried working through an interpreter, but I have not found it to work well).
  • Our basic flow is Scrum and we do short sprints. We are not dogmatic, but we want to produce working software at least once per week. I would like you to know what Agile is about before we start.
  • As Product Owner, I care about quality and robustness. I would like someone who is into TDD, BDD or one of their cousins. 
  • Interest in the work (which is mostly about the plumbing right now!). The main goal is to complete the integration of our member management and event management components with the payment and accounting systems. This will make all of our stakeholders happy, especially me since I am doing this manually now! So we are looking at making WordPress plugins and other glue. This part of the project is not about sleek design, it's about rock-solid infrastructure.
  • Happy to work in a virtual team. Our team is based in locations from Europe to South East Asia. We use Skype, Hangout, Trello, and various cloud services. 
  • Happy with workloads of varying intensity. We have a clear project now, so you'll be pretty busy. I expect we are looking at a one to two month engagement. After that, we'll see. Maybe there will be phases where we are just in maintenance mode. We do expect a long life for our project and would like to come back to you when we need your skills again!
  • We would like someone is independent or in a small partnership. Someone who has control over their own time. You'll be dealing with Principals, and we'd like to deal with a Principal too.
  • Last but not least, we are looking for good chemistry. We want work to be fun!
Does this resonate with you? Would you like to be collaborate with an Agile team?

How to contact us

If you want to impress us, tweet a screen shot of your latest daily build or other evidence that you know what you're talking about! Just include @peterstev and @bindzus and #SBCDEV in the tweet, and we'll reach out to you!

Friday, May 20, 2016

Working toward Personal Scrum v.0.2

I have had a lot of great discussions around my post on Personal Scrum, and in the meantime, I have collected some hands-on experience. Four weeks later, what has changed? What's working well, and what still needs improvement?

What's gotten better since last month?

  • I was ready without drama to go to the Scrum Gathering
  • I have published a blog entry every week, something I've wanted to do but haven't done in years.
  • I followed up on my courses and Scrum Breakfast Club meetings promptly.
  • I succeeded in making a major revision in my CSM materials, something I've wanted to do for years. More generally, I am able to set and accomplish medium term goals.
  • I pushed back and said no to something that would have been a lot of work and little value.
  • I went for a 30 minute walk during the day.
  • I have time to waste on youtube and reddit. (Ask me about where we might find life in the solar system or some fan-made Star Trek films worth watching!)
It seems like this is mostly working. This would be a nice time to pat me on the back. Thank you. 

What hasn't gotten better?

I am still working too much on weekends. Perhaps not quite as late into the night. My idea of enlisting my wife as coach/ScrumMaster has not worked the way I'd hoped. She hasn't had time, sigh. But she got to sing in the Veitsdom in Prague and the KKL in Lucern last weekend, so she can be excused for having other priorities!

I don't always follow the plan. I have decided this is neither good nor bad, just a fact of life. So I forgive myself for when I don't follow the plan and celebrate when things go well.

Now, when I plan a goal, I mark it as either moveable or fixed. Movable is light green on the calendar. This is a goal I want to achieve, but whether I do it in the morning, the evening or perhaps even tomorrow, doesn't make that much difference. I plan around the capacity, not the time slot. Fixed is an appointment with someone or otherwise a hard deadline. In this case, I do plan around the time slot.

What doesn't really work?

Well, I don't always work on the items on my schedule, especially not in the order I had planned (thought I often achieve the goals for the day.) What happens when something spontaneous and important arises, like a course registration? Well I do it, even though it wasn't on the plan. What happens if I am in the middle of something when the allocated time ends? Often I finish it anyway, though this probably needs a break and a reflection before deciding do move on.

What have I learned about myself?

My inspiration was a collection of habits of highly effective people. One recommendation was to manage minutes, not hours. How can people's lives be so totally predictable? I have planned events with C-level executives of major corporations, and yes, their itineraries were planned down to the minute. As predictable as the machines their companies should be. 

Here are some of my key lessons:
  • I treat the plan as an attractor, not as a master. When I am wondering what I should do now, I look to my calendar to see what I have planned for the day, not the current minute.
  • It is important to celebrate what you did, and not to punish yourself for what you didn't do.
  • My estimates still suck. I am a hopeless optimist.
  • Even as I updated my estimates to reflect reality, I noticed something else. Doing the maximum every day that I can is not sustainable. I get tired, my mind starts to drift, and I might find I spend a whole day without even looking at my calendar. There is an important difference between peak performance and sustainable performance.
  • In a battle between planning and procrastination, procrastination has the upper hand. (The walk was both a victory and a defeat).
  • During periods of high uncertainty or where spontaneity is important, e.g. the Scrum Gathering, I only plan the most important activities and leave lots of time for surprises.
  • Planning time is not a replacement for a backlog. I have lost sight of some important goals that I set for myself.  I need a trello board.

What will Personal Scrum v.0.2 look like? 

  1. I will have a backlog and a trello board.
  2. I will review it weekly.
  3. A coach is on the backlog.
  4. So are breaks and a sustainable pace and a weekly planning & review cycle.
Inspect and adapt... life goes on.


Tuesday, May 17, 2016

When should you apply Scrum?

... and when not? I was really surprised to discover it is not easy to find an answer this question. Let's look at what Scrum is, then look at when Scrum is appropriate and when not.

What is Scrum?

Scrum is a simple, team-based framework for solving complex problems. Scrum is modelled on successful patterns for product development as identified in "The New New Product Development Game". I would summarize these patterns as follows:

  1. Inspect and Adapt at regular intervals
  2. Produce something that might be valuable for your customer at regular intervals
  3. One voice speaks for the customer
  4. An interdisciplinary team solves the whole problem
  5. A coach helps everybody involved to get better
  6. Management provides direction and support, and knows when it's best to stay out of the way
How is scrum different than traditional approaches? The principles of traditional management might be summarized as follows:
  1. Define a plan, follow the plan
  2. Check progress against milestones
  3. Maximize utilization of resources
  4. Managers, customers or stakeholders make key decisions
  5. Well-defined processes, carefully followed, ensure predictable results.
  6. Optimization should improve the efficiency of a process

When does Scrum make sense?


Scrum was created for solving complex problems. What is a complex problem? If you can't know the answer before you start, it's a complex problem. You may not even be sure you are asking the right question! What is the right feature set for this product? Will this product meet the needs of the market? Sure, you can answer these questions in advance, but only through validation do you know if you have gotten the right answer.

Scrum is a team-based framework. It's about people. Scrum works well when people want to do it.  

What happens when the people don't want to do Scrum? It doesn't work very well. Scrum does not lend itself to being imposed from above. You can do it, but you create huge internal resistance. A good Scrum implementation, even if top-level management wants it too, is pulled from below. 

When does classical management make sense?

Some people would say the answer to this is never. But I think it is more complicated than that.  The patterns of classical management, which was invented by the automobile industry at the beginning of the 20th century, were hugely successful. They are the foundations of most large enterprises, and even today, as Agile methods have made development projects much more successful, an increasing percentage of the wealth generated by society stays in hands of top layers of classical management. This is also a definition of success!

So when do the patterns of classical management make sense?

The key word is predictability. If you can define a process with known inputs that produce the desired outputs, it is probably economically advantageous to do so. This works well for production problems, but is not well aligned with the needs of creative tasks like product innovation.

Should you use Scrum?

I would encourage you to use Scrum (or another empirical process) for unpredictable contexts:
  • Your main objective is some kind of problem solving.
  • Multiple skill sets are needed to solve the problem ("a team")  
  • Validation from customers or stakeholders is important to getting the right answer 
  • The people involved want to do it. (I often get called in to help people decide they want to do it).
I would encourage you to use a defined process for more predictable contexts:
  • A known input can lead to a predictable output
  • The problem and the solution can be clearly defined
I would encourage you not to do Scrum if the people involved do not want to do it. 

Having said that, if you ask people for examples from their own experience of great projects they'd like to emulate moving forward, these projects often look a lot like Scrum. If you ask people how they would like to organize their work, they often come up with something that looks a lot like Scrum!
    Lastly, I would also encourage you to challenge whether the tasks that you think belong to the predictable group really do belong there! 








      Monday, May 9, 2016

      What's a good spike?

      Problem: Our forum has some unpleasant limitations. In particular, pasting formatted text into a forum post from Outlook (and possibly other sources) produces weird and wonderful results: the HTML gets converted so you don't see formatted text, you see the raw HTML A bit annoying.  So we decided to do a spike to evaluate an alternative:
      spike: evaluate TinyMCE / other options for editing text in forum
      We got to the end of the evaluation, and as PO, I had more questions at the end of this evaluation than at the beginning! Why?

      I think the answer can be found in the title of the spike. What's wrong with this title? First, it starts with an verb in the imperative. "Team, do this" It is not an invitation to think. Second how do we know if the we have satisfied the objective? It doesn't really say. It just says 'evaluate.'

      Here's an improvement:
      spike: can we eliminate our copy/paste problems by using TinyMCE?
      By formulating the spike as a question, it becomes clearer what is the objective of the spike. This in turn makes it easier to tell whether the spike is done.

      Of course, this still doesn't answer the question of whether it is a good thing to deploy it in our context. It's a closed question and assumes part of the answer, i.e. that TinyMCE is the best solution. How about:
      Which forum editor best satisfies the needs of our users?
      Of course, that might be a bigger spike, but the goal is clearest and most focussed on the people who really matter!

      In my Certified Scrum classes, I demonstrate using Scrum in the class by organizing the class with Scrum. The course topics are the product backlog. I used to define the product backlog as user stories, but I now express them as questions. My students ask questions; learning is the result of asking questions; and formulating the product backlog as a series of questions seems like a natural approach. I wonder questions as backlog items could be used for other kinds of story as well?

      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!