The top priority for a ScrumMaster should be to remove anything impeding his team to progress, in other words the impediments. In his article, Ilan Goldstein defines an impediment as “An event that impedes the ability of any of the team members to work to their estimated sprint capacity.” The post starts with a list of possible impediments that includes ungroomed product backlog, absent product owner holding up key decisions or broken build. The most interesting part of the post is however the six step approach to deal with Scrum impediments ...

Wozu Scrum? Die Antwort auf diese Frage variiert von Unternehmen zu Unternehmen – und dennoch geht es meistens um schnellere Auslieferungen, bessere Qualität, stärkere Kundeneinbindung, zufriedene Mitarbeiter.

 

All das ist wichtig und gut, doch beantwortet es nicht die Frage nach dem Wozu. Denn ich kann großartigen Code schreiben, alle zwei Wochen releasen, meine Kunden ständig dabeihaben und immer noch nicht wissen, welchen Zweck ich damit verfolge. Solange die Geschäftszahlen stimmen, mag das nicht weiter schlimm erscheinen. Gewinn ist ein täuschend echter Unternehmenszweck.

 

Verändern sich aber die Marktbedingungen (und das ist heute eher die Regel als die Ausnahme), ist die eigene Ausrichtung zu überprüfen: Ist das, was sich bisher blendend verkauft hat, auch heute noch das Richtige? Und spätestens da stellt sich die Frage nach dem Wozu. Um sie zu beantworten, muss ich erstmal verstehen, wie mein Produkt aussehen könnte und was es zum Produkt macht. Wir haben dafür eine eigene Rolle in Scrum: Den Product Owner. Ohne die Frage nach dem “Wozu” wären Product Owner überflüssig: Die Entwicklungsteams könnten direkt mit Kunden und Benutzer sprechen, seine Anforderungen aufnehmen und dann umsetzen.

Was ist das denn: ein Produkt?

Laut Wikipedia ist es das Ergebnis eines vom Menschen bewirkten Transformationsprozesses, in dem Produktionsfaktoren wie Güter und Dienstleistungen in einen Output umgewandelt werden. Das ist sicher nicht falsch, aber es zieht am Wesentlichen vorbei.

 

Ein Produkt ist für mich so etwas wie ein Leuchtturm in der Beziehung des Menschen zu seiner Umwelt. Ein Anker, eine feste Referenz, die unser Leben besser, schöner, einfacher, anspruchsvoller macht.

Ein Kunstwerk, ein Schlüssel, ein Zug, ein Studium, ein Hut, eine Tasse Kaffee. Das alles sind Produkte – feste Bestandteile des menschlichen Lebens, milliardenfach produziert und in Anspruch genommen, weil sie nützlich sind.

Ein gutes Produkt fügt sich ungezwungen in die Interaktion zwischen Mensch und Umwelt. Es wird nicht als Last oder Hindernis, sondern als Stärkung empfunden. Als etwas, das man gerne in die Hand nimmt, trägt, bedient, in Anspruch nimmt.

 

In der Softwareentwicklung fällt der Bau guter Produkte nicht leicht. Mit Software lässt sich sehr viel sehr schnell bauen. Diese Fülle an Möglichkeiten, die ja die Kraft von Software ausmacht, ist zugleich ihre Achillesferse. Benutzer wollen einfache, intuitiv bedienbare, gut aussehende und zugleich leistungsstarke Software. Zu oft fühlen sie sich jedoch überfordert und frustriert, haben eine vorbelastete Beziehung zu Software und würden am liebsten ohne sie auskommen, wenn sie die Wahl hätten. Da sie diese Wahl nicht haben, werden sie bisweilen stiefmütterlich behandelt. Es sollte niemanden verwundern, wenn die gleichen Benutzer bei der erstbesten Gelegenheit dem Konkurrenten in die Arme laufen und dem alten Produkt keine Träne nachweinen.

 

An welchem Produkt arbeitest du mit? Was macht es stark? Wie beeinflusst es die Interaktion zwischen Mensch und Umwelt? Wer sind diese Menschen? Die Antwort auf diese Fragen nennen wir Produktvision. Es lohnt sich, Zeit dafür zu investieren. Denn nur die Produktvision kann die Frage nach dem Wozu beantworten. Software wird nicht entwickelt, um fehlerlos zu laufen. Oder um möglichst viel Abfragen in möglichst geringer Zeit zu bearbeiten. Sie ist da, um Spuren im Alltag der Menschen zu hinterlassen. Du kannst bei dem, was du entwickelst, beim besten Willen keine Produkteigenschaften feststellen? Dann versuche es mit folgenden Fragen:

• Wer sind deine Kunden? Was haben sie davon, dass es euch gibt?
• Welcher Bedarf deines Kunden wird durch euer Produkt erfüllt?
• Welche sind die vier bis fünf kritischen Funktionalitäten, die den Erfolg des Produktes ausmachen?
• Wie wird das Unternehmen vom Produkt profitieren?

Nimm dir zum Schluss noch zehn Minuten, um deine Erkenntnisse in einen “Elevator Pitch” zusammenzufassen – einem Statement, das so knapp und prägnant ist, dass während einer Fahrt im Aufzug die Vision kommuniziert werden kann.

 

Unsere Produktvision bei bor!sgloger lautet übrigens wie folgt: Nach ihrem Arbeitstag sollen unsere Kunden nach Hause gehen und dorthin die Energie und Zufriedenheit mitnehmen, um mit ihren Kindern zu spielen.

Related posts:

1. Scrum Essentials: Die sieben Fragen der User Story
2. Warum wir eigentlich alle Freelancer sind
3. ScrumMaster vs. ScrumMasterin

The software industry has created a knowledge and expectation of product versions.  Previously the closest industry to create this mindset was the automotive industry - they had the model year concept.  Typically they added nice to have "bells or whistles", but rarely added true features each iteration of the auto model year.

Software was a new paradigm, back in the 1980s, this industry started using a version numbering scheme (major dot minor). For example, Windows 3.1, the first version to truly work and deliver value to the customer.

What happens when a company moves back to the model year concept of versioning in the software industry?  Does it help customer to understand the expectations of value being delivered?  Does it create more cognitive load for decision makers?

Here's an example, you tell me; it is May of 2013, is this the best move for Company X.

Coming Soon: SharePoint 2010
The long-awaited upgrade to SharePoint 2010 will soon roll out in phases across Company X, beginning in May. The full upgrade should be complete by the end of August, with some employees beginning to see changes to their SharePoint in the coming weeks.By my quick use of higher math (2013 - 2010 = 3 years), this is a very long awaited upgrade!  Perhaps so long as to just say, F*** IT, let's wait for SharePoint 2015.  The beta version should be out this summer.

Can someone please tell me how this version scheme helps our customers, users, purchasers, anyone?  What scheme do you use?  Does it set the expectation you desire with your customers?

Continuing with the 100 Things You Must Know to Be Effective In Software Development.   The Scrum Gathering starts in Las Vegas today where I am presenting a talk this afternoon.  Figured I should do a Scrum based lesson today.  I have been saying for years that the Chicken and Pigs story is counterproductive and is a symptom of an over-reaction to management.  I wrote a blog about this Is...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]

You may have a well-articulated, strategic roadmap BUT how, when and what value you deliver against that roadmap can fluctuate. A benefit of iterative delivery and deliberate learning cycles is that product teams can tweak or radically change output based on what is discovered. Build, measure, learn and change.

A high-performing product team will stop working on ideas when there is evidence that the value is not as high as projected, and start testing new ideas. Embracing this agility means recognizing change early and adjusting often. Any predictions you made one sprint ago should be questioned. Roadmaps created one quarter ago should be questioned. So how can we get better at encouraging and responding to change vs. the extreme: adhering to a fixed, top-down plan?

• Ensure visibility into product team initiatives, and that they roll up to strategic initiatives and roadmaps – as a tool to continuously align the organization from strategic initiative to team focus and back up the chain.
• Build flexible roadmaps that are outcome-driven while promoting change and innovation.
• Plan continuously at all levels in the organization, align, re-plan and align again. Quarterly planning may be too late to be effective.
• Consider roadmap changes regularly. Don’t miss an opportunity to pivot early.
• Recognize that a forecast may only be relevant for a moment in time, based only on today’s assumptions. Review, communicate and adjust often. Or don’t forecast.

Hopefully your organization has this problem, where your teams are learning and delivering value beyond what was planned for, despite being less predictable about it. If not, it may be that your organization has a fairly static plan based on what the teams can deliver, based on the current constraints.

Organizations like these that “go agile” recognize that stable teams and iterative delivery can produce output more predictably… perhaps stabilizing roadmaps. But, competitive value comes when we are able to respond to what we learn, change direction, and produce valuable differentiators which we could not have predicted. While these outcomes are less predictable, agile enterprise-level planning needs to be just as dynamic as the product teams in order to organizationally align and deliver against what is measured and learned.

Part 1: Does distance cancel out efficiency of internationally dispersed Teams?
Part 2: Should internationally distributed Teams be avoided?
Part 3: Scrum Spaces of internationally distributed Teams – the Do’s and Don’ts
Part 4: The Pros and Cons of Electronic and/or Physical Taskboards
Part 5: How internationally distributed Teams can improve their Daily Scrum
Part 6: How internationally distributed Teams can improve their Sprint Planning 1
Part 7: How internationally distributed Teams can improve their Sprint Planning 2

Stephanie G.: Having discussed Sprint Planning 2, let us continue with your experiences and advice for the Sprint Review. Would you say that the meeting becomes more complicated the more locations are involved?

Hélène V.: It does indeed get more complicated if the Customers live in different timezones. It would be truly inhumane to ask one of the Customers to get out of bed at 4am in order to participate at the Review. If that‘s the case, I would simply have more than one Review meeting. After all, Reviews are usually culturally pretty different anyway – for example, an Australian thinks differently than an Austrian. If you hold more than one Review, I think it would suffice to have one Dev.Team member and the Product Owner present. Of course, the Dev.Team member should vary.

Christof B.: I don‘t necessarily think that it becomes more complicated the more locations are involved. The thing is, even co-located Teams sometimes have international Customers, so the question of handling international Reviews is of interest to most Scrum Teams. The meeting very much depends on the kind of software that is presented – for example, it is more difficult to show a mobile app than a browser. However, generally one can say that it‘s simply a matter of having the right tool – Webex or TeamViewer are good options. If a telephone connection is unavailable, feedback via chat is also possible.

Bernd K.: I agree – from a technological point of view, the Review is quite easy. My Team members used to present all Stories by using Desktop Sharing and Skype.

Kristina K.: True! You can always send the product increment to the Customer in advance via a preview platform and then watch one of the Users click around via video conference. However, as Christof has already stated, this depends on the type of product. I also think it would be a good idea for the Product Owner and a Dev.Team member to fly to the Customer every now and again. Alternatively, a proxy User can be found in each location – a colleague, for example – who can try out the product increment. I usually vary these options – alternating internal and external Reviews. If the distance allows it, I would also recommend the whole Team coming together for every second Sprint change.

Hélène V.: On top of Kristina’s input, if you decide to hold a Sprint Review for each Customer, I would take the feedback from one Customer to the next. Meaning that I would ask whether the Australian is of the same opinion as the Austrian that i.e. there‘s a button missing in the upper left corner. If the budget allows it, I would even recommend to fly in the Customer directly every now and again.

Deborah W.: We never had any Customers present at our Sprint Reviews. Instead, we did what Kristina’s just mentioned and asked people from other departments to step in for them. It was very pragmatic – we had one person with an iPad who filmed the proxy User while handling the application and clicking around. The webcam also filmed what was shown on the screen, so that all locations could get the idea.

Bernd K.: Deborah, it was similar with my Team. Before I arrived as the new ScrumMaster, the User or Customer had never actually seen the product. It seemed that there was a real culture of criticism in the relationship between the Customer and the company. After three Sprints, we had a large Review to which I invited Managers and Customers. It was strange, because the fear in the air was truly tangible. In the end, only the Management and other interested people turned up. That was really nice, as the Team felt in a safe environment to present their work. If I could do it again, I would first address and work on the feedback culture before inviting the Customer.

Stephanie G.: Ina, what do you think?! Did you have a similar experience?

Ina K.: I find it rather funny that I‘m the only one here who found the Review to be one of the more difficult meetings with internationally distributed Teams. I always had these questions running through my head: How can you get the Customer or User properly involved if they‘re on a different continent?! Does using a person from an internal department suffice as a proxy for them? I love the fact that Scrum provides us with the Sprint Review, as it gives all parties concerned the opportunity to get involved in the making of the product. As a Manager, I can try out product increments that are ready to be delivered – how cool is that?! Even people who are not very technologically talented can participate. The Review enables the Scrum Team to interact with the Customer by way of feedback and arouse his interest in the product. When working with co-located Teams, I really enjoy turning the Review into a marketplace together with other Scrum Teams, where all stakeholders can try out different elements at the same time. I find that to be much more fun than simple presentations with frontal speakers. However, organising a marketplace is more complicated when working with internationally distributed Teams.

Bernd K.: Ina, you‘re not the only one who found it quite difficult. There really are certain aspects that need to be addressed when talking about Reviews and distributed Teams. For example, some of my Team members found it pretty stressful to present without knowing what the audience looks like or how they are reacting. They were also pretty scared of negative feedback. So we made sure that we had webcams pointing at the audience, so that the presenters would become more relaxed. As ScrumMaster, I began introducing a culture of positive feedback and of pushing performance into the foreground. After a while, even the Product Owner praised the Team during the Reviews.

Stephanie G.: Anything else that you would advise to keep an eye out for?!

Ina K.: The preparation is the most important element of the Sprint Review, as it is always better when different Team members from various locations present. This should become part of the routine. At the actual meeting, as a ScrumMaster, you should make sure that everyone is involved – always ask whether there are any more questions concerning a certain feature and make sure that the guests know how important it is for them to be involved.

Bernd K.: Particularly during the Sprint Review, I find it super embarrassing if the technological connection does not start. Keeping Murphy’s Law in mind, I would really recommend arriving even earlier than you normally would for a meeting in order to make sure that everything is up and running before the guests arrive.

Stephanie G.: True, Bernd. I‘m glad you mentioned the topic of preparation, as I can only second the importance of that! So summing up your points, one should consider the following when holding a Sprint Review with a distributed Scrum Team:

• Make sure that the technological set-up and the Team members are prepared 
• Make sure that the right tools are available for allowing the Customer to try out the product increments and filming it
• Vary the Review meeting: 
  • have more than one Review, but share the feedback across Review meetings i.e. different time zones, different Customers
  • PO and 1 varying Dev.Team member fly to the Customer
  • fly in the Customer or
  • ask colleagues or potential End Users at each location to try out the product increment as proxy Customers
• Work on a positive feedback culture

Related posts:

1. How internationally distributed Teams can improve their Sprint Planning 2
2. How internationally distributed Teams can improve their Sprint Planning 1
3. Should internationally distributed Teams be avoided?

In the Agile world, coaches and trainers are distinctions that were created in order to create different ways of making money. They have no useful business purpose outside of filling the pockets of consultants with cash.

How can I maintain this? Here’s how I see it now: I (used to) have friends who are trainers. They are normal people like you and me. They typically got their start as project managers and or scrum masters just like the rest of us. At some point they go through a process where they are vetted for the following:

1) An understanding of the vague terms used in the agile lexicon
2) Conformance to religiously held views regarding a process
3) Communication skills & attitude

Once they are hit with the golden hammer, anointed by the powers that be, given the blessings of the bishops, or certified, they can charge large amounts of money to provide the same training over and over…and over…

Or they can just go out on their own and do it without any such approval. Of course if they do that, then they have to survive based on whatever actual skills they may have. They have to come up with their own material that isn’t provided by some governing authority. They have to market their skills all by themselves, and it’s a cold and unforgiving consulting market out there.

Regardless of which path you choose to take, are you doing anything that a good scrum master or a project manager couldn’t do? No. Training is part of any good manager’s role. Many scrum masters that I know have actually given CSM training at one time or another – and done quite well. Furthermore, the agile training that I’ve seen isn’t rocket science. It takes only marginal presentation skills to successfully deliver agile training. It’s not original material. It’s not like you have to know how to write code. In fact, most trainers I know, can’t write code. Are these really the people who are going to tell software developers how to work?

It’s nice work if you can get it.

Filed under: Agile, Coaching, Scrum Tagged: Agile, Coaching, Scrum, Training

I recently was asked this question: Typically, does the ScrumMaster have stories in any given sprint that track for iteration planning, backlog refinement, or any other sprint/Scrum tracking activities? Or does the ScrumMaster's time fall outside...

  Continuing with the 100 Things You Must Know to Be Effective In Software Development.   I've been hearing two disparate views of estimation, and it does feel "camp" oriented.  The Scrum camp doesn't question estimation but is looking for better ways.  It takes much more time than it feels it should.  The reason for this feeling is that it takes much more time that it should.  Planning poker is...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]

In this post I want to talk about company culture. Every company has a culture. Some are outstanding, perhaps some are close to criminal, but I guess most are just mediocre.

How do you know where in this spectrum between star and rubbish your company’s culture is located?

I think a good way of telling is whether you were given the opportunity and the freedom to improve the way you work. Are you working on new projects that lead to a significant improvement of the processes you use and as a result significantly improved benefits for your customers?

Let’s look at a randomly made up example. A team is working on a product that is a combination of hardware, firmware, software and services. The product has not been introduced to the market yet. However you know that you need to finish the project by the end of the month. “Finish” does not mean that you have all features complete that you thought you must have. Instead it means a cross-functional effort between product management, hardware engineers, software developers, marketing, sales and probably a whole raft of others.

In that collaboration the team will understand that it may not be able to ship every single feature, but it will also understand the priority of each feature as each feature has a different business value to the company and to the customer. Let’s assume that in this given example a demo in the first week of the next month is highly likely to lead to receiving a significant order.

With the wrong culture the team would do it’s 8 to 5 job and then go home. No creativity would be invested and you may even see the occasional finger-pointing. Progress would be slow.

With a different culture the team would band together working towards that objective. A sense of excitement would be visible within the team. The team would collaborate, think beyond the boundaries of their “official” role (e.g. developer) and they would be very creative to find even simpler and faster solutions that would allow to stitch together a product that would be good enough for the purpose. They would throw in as many extra hours without the need to be asked or be instructed. The team would do whatever it takes to achieve the objective. They would know that they can make decisions and they would get the tools and the support to get the job done.

The leadership in both of these cases is quite different. It is very likely that the former breathes of micromanagement and bureaucracy. Maybe getting new hardware and software is close to impossible and always requires a lengthy process for ordering and procurement.

The leadership in the latter is most likely more hands-off. It’s management by exception or management by objective. If the team needs a new tool, hardware or software, the decision can be made within hours if not minutes rather than weeks or months. The leadership would embody trust towards the individuals in the team, willing to take the risk that things can go wrong when you push the envelope.

How do you know that you are in the right culture? First of all you need to decide for yourself what company culture you want to work in. Then ask yourself a few very simple questions that I believe are indicative of what the actual culture is in your company. Questions include:

• Am I working on a project that challenges me, the team and the approach we take>
• Is the project leading to improvements of the product, the processes you use, learning for yourself?
• How do you interact with customers? Do you have direct interaction or do you have ‘men in the middle’?
• How long does it take to get new tools like hardware or software? Is the duration measured in hours and days rather weeks or months? Do you see new tools arriving in your team on a regular basis, e.g. at least once per month?
• What is the attrition rate in your team? Are people replaced immediately? How easy is it to replace people?

I’m sure there are plenty of other indications that help. The important thing is that you do not judge your leadership by what they say but by what they do. Once you know what culture you are looking for and what culture your present company has, it’s easy to come to the right conclusion. Perhaps you like it. Perhaps the time has come to move on.

What if there was a significant change in culture? My recommendation in that case would be: Don’t make any quick decisions. I that case hang in there for a few more weeks or months. Sometimes things don’t turn out as bad as they might appear initially. You can still make a different decision once the new culture becomes clearer to you.

Here is a link with yet another set of aspects regarding a company’s culture. It’s a post by Grant Cardone.

Continuing with the 100 Things You Must Know to Be Effective In Software Development.   Relatively early in my consulting career, I realized that it’s not simply the low hanging fruit you go after, you have to attend how one thing sets up another.  As people learn, some lessons set up others.  I call this the “pick up sticks model for building curriculum.”  Some practices also change the...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]

Partnership & Possibilities: A Podcast on Leadership in Organizations
EPISODE 2: AN INQUIRY INTO QUESTIONS

“Leadership really comes from the nature of the questions you ask rather than the statements that you make.”

Running time 32:54

What questions have been particularly powerful for you? What questions have you asked or have been asked that have made a difference in your life or which have stimulated learning in others (and in yourself)?

Leave a comment on this blog or email us at leadershippodcast@gmail.com

Summary
Intro – What role do questions play in leadership? What does the process of asking questions look like?
3:32 – Using questions to help discern patterns as described in the Human Systems Dynamics model
9:00 – Leaders do not have to know all the answers – asking questions is not a sign of weakness, rather it opens the door to innovation, engagement and new learning opportunities for all agents in an organization
13:49 – Asking questions without judgment enables the asker to be open to receiving new information without preconception
18:34 – Having a holistic understanding of the approach you use to asking questions is essential
22:53 – Using a set of guidelines in asking questions can also lead to a greater depth of understanding and learning
30:19 – Change begins to occur from the moment the question is asked

Resources
HSD Institute Wiki
The 2R Manager: When to Relate, When to Require, and How to Do Both Effectively by Peter E. Friedes
Change Your Questions, Change Your Life: 10 Powerful Tools for Life and Work by Marilee Adams PhD
Insights You Can Use by Esther Derby
The Nature of Order by Christopher Alexander
Fearless Change by Linda Rising

What resources have you found useful as a way to think about improving your ability to ask good questions? Email us at leadershippodcast@gmail.com and we will share them with our audience.

Photo Credit: milos milosevic via Compfight cc

I am still making progress, although it’s more difficult to see my progress today. Why? Because I did not get as much to done.

One of my readers asked a question about the Urgent queue  and the relative ranking of my ever-growing left hand column. How did I determine what to do, and what was the rank of each?

The Urgent queue always trumps everything on the left hand side of the list. I was so frantic on Monday, I didn’t order anything when I put the list together. It almost didn’t matter what I worked on, as long as I made enough progress to get enough things to done. As you can see, I did pick and choose. When I rewrite my list for next week, I will reconsider what I need to do in order. I need to complete the workshops and talks first. Then do the writing. My list next week should be shorter, so I should feel less frantic and be able to finish it.

As for the ones I have added to the bottom of the list, trumping the older ones in importance? No, not really. They are there because I realized I needed to do them also this week. My todos are getting away from me. Putting them on the list means I don’t lose them. I can relax because they are there. Now, I have to focus and do them.

If you are wondering, will I continue this series next week? No. I will not. One week of this is plenty. I wanted to show you a number of things:

• Everyone has trouble every so often, with too much to do
• The best way to organize your work is to see it, not matter what you decide to do next
• I like personal kanban, where I finish one chunk of work and go on to the next
• If you keep your chunks of work small, you can finish one and continue on to the next one. If your chunks of work are too large, you can’t finish anything and you are tempted to multitask. (Don’t do that!)

If you want to see all the posts in this series, here they are:

• Personal Kanban and Iterations, Day 1
• Personal Kanban and Iterations, Day 2
• Personal Kanban and Iterations, Day 3
• Personal Kanban and Iterations, Day 4

To see a “real” personal kanban board, the way I suggest you do it in Manage Your Job Search, go to Personal Kanban for Your Job Hunt.

Read my Book Review of Personal Kanban for more information on how to do it right. And, Gil Broza will be interviewing me for his Individuals and Interactions virtual training May 15, 2013. My topic? “Focus Keeps You Going.” Surprised? I don’t think so!

There is no definite consensus on the need for risk management within the Agile method. This has led many to believe that risk management is irrelevant in an iterative model. Some follow the approach of ignoring risks until they manifest into issu...

This is the final issue of James Brett‘s 5 Questions. Issue 1 featured Ron Jefferies, Issue 2 featured Ken Schwaber, and Issue 3 featured Mike Cohn.

In issue 4 of the five questions series we hear from Alistair Cockburn.

Alistair is a leading agile evangelist and book author and recently presented a number of sessions at the Orlando Scrum Gathering, including the “panel of 5” open discussion with the likes of Ken Schwaber, Mike Cohn, Ron Jeffries and Jim Coplien.

Alistair is currently working alongside Ken Schwaber and Jeff Sutherland and absorbing their thoughts and ideas, some of which are un-written. Alistair is an excellent wordsmith and is hoping to articulate in more detail some of the details of Scrum and its implementation. An example of this is the term “Scrum is a mirror” which you will see Alistair refer to in his answers below. This term refers to Scrum acting as a mirror into your organisation and identifying impediments and issues that need resolutions. So without any more delay I give you Dr. Alistair Cockburn… A big thank you to Alistair for taking the time to respond so quickly.

Bio. Alistair Cockburn was voted one of the “The All-Time Top 150 i-Technology Heroes” in 2007. He is an internationally renowned project witch doctor and IT strategist, expert on agile development, use cases, project management, and object-oriented design, author of the Crystal agile methodologies, three Jolt-awarded books, co-author of the Agile Manifesto and the project management Declaration of Interdependence, and inventor of the Initial Response Technique massage form. He is known for his lively presentations and interactive workshops. His blog, poems, articles, and talks are available online at http://alistair.cockburn.us

Alistair’s answers..

Q1. Can you describe what you would consider the top Scrum enabler in an organization?

First, willingness to look into the Scrum mirror, and second, willingness to act on what it shows.

Q2. Where do you see Scrum in 5 years time?

With very many CSMs all over the world, and with an increasing bureaucracy inside the ScrumAlliance.

Q3. What has been your toughest Scrum challenge so far?

Getting people to look into the Scrum mirror.

Q4. What makes you passionate about Scrum?

I’m not particularly passionate about Scrum. I’m passionate about helping people do better. Scrum is one tool; other tools are also helpful and also needed.

Q5. What can we learn from you about Scrum?

I watch Ken and Jeff closely and try to interpret back to the community what they’re saying / doing.

Signup for the Scrum Addendum, our free online course with articles on: Keeping Daily Scrums short, Sprint Burndown Graph signatures, Release Burndown graph patterns, Eating one’s own dog food, Distributed Scrum and patterns for Success, Beyond Continuous Integration, The Principle of Postponement, Agile Contracts and more.

When you subscribe, you will receive an email every week for 13 weeks. You’ll also receive two white papers: "A Roadmap to Agile Development: A Strategy to Increase Adoption Success", and "The Top 13 Organization Challenges of Agile Development." This is some of our best material and it’s been re-edited especially for this email series. Signup here ... it's free!

Let’s say You have just finished to create the user stories for your product and, a bit proudly, your product backlog now counts two or three hundred of items. How can you estimate them, effectively? It is not always possibile to have all the items of the backlog estimated using the planning poker game. This [...]