Scrumorakel - Blog
http://www.scrumorakel.de/blog/
Ideen, Erfahrungen und Gedanken zu Scrumenhttp://www.scrumorakel.de/blog/templates/bulletproof/img/s9y_banner_small.pngRSS: Scrumorakel - Blog - Ideen, Erfahrungen und Gedanken zu Scrum
http://www.scrumorakel.de/blog/
10021The most misunderstood aspect of Scrum: Sprint Review
http://www.scrumorakel.de/blog/index.php?/archives/56-The-most-misunderstood-aspect-of-Scrum-Sprint-Review.html
Almost every team I have coached so far has made the same mistake. This was treating the Sprint Review as "demo" or "approval meeting". It is neither of those. The Scrum Guide says:<br />
<blockquote>A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value. This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration.</blockquote><br />
So the Sprint Review should be a informal, collaborative working session. Lot's of interaction with the stakeholders is sought for, not the passive acceptance of whatever drizzles down from the stage.<br />
<br />
A good Sprint Review could have the following format:<OL><br />
<li>The Product Owner welcomes all attendees (especially the stakeholders) and reminds everybody of the product vision and the value he is trying to achieve (he shows the "big picture")</li><br />
<li>Then, the PO shows the release target and the Sprint goal. He also states if the goal was reached or not, maybe even giving a reason in the latter case.</li><br />
<li>The the Product Owner passes the ball over to the Development Team. They show very briefly what they have accomplished. They do not show anything that isn't completely "Done".</li><br />
<li>After the short "demo" element, the true fun starts: The stakeholders get to try the product increment. They use it, touch it, feel it. Only then they notice if what they are holding in their hands (or clicking with their mouse) is what they actually wanted. The developers walk around and give a hand whenever needed. When new requirements are identified or changes to the Product Backlog are seen as necessary, the Product Owner records these.</li><br />
<li>Together, the Product Owner and stakeholders examine the Product Backlog and the impact of what they have just seen. If deemed valuable, the Product Owner adapts the Product Backlog</li><br />
<li>The Product Owner thanks everybody for their input and closes the meeting</li><br />
</ol><br />
This flow is not prescribed by Scrum. However, I personally find it very useful.<br />
<br />
You might still ask yourself when the work of the Development Team is formally accepted. Well, the Sprint Review is the <em>last </em>possible moment for this, not the only one. And it is a bad point in time to do it. After all, the stakeholders are present in the meeting - if the Product Owner is surprised by his Team's results, he is standing on the stage with his pants dropped. No chance at all to gather more information or rectify a mistake. So instead of accepting this huge risk, good Product Owners will accept or reject the team's results <em>during the Sprint</em>. Usually, Product Backlog Item by Product Backlog Item and on the day when the Team claims they are "Done". The PO works with the team on a daily basis, so this shouldn't pose a problem.<br />
Scrum does not define when the stakeholders formally accept the results of the Product Owner (he is the "single wringable neck", so he is on the line for his stakeholders), so it can be defined by each product/project. It can be done during the Sprint Review, but this usually diminishes the quality of the meeting because everybody is trying to look good instead of collaborating on what has to be done next. Smart Product Owners will try to detach formal acceptance from meetings and connect it to KPIs instead, e.g. the primary value KPI. If the primary reason why this project is conducted is a sales number (e.g. 1 million), then actually count sales. Who cares if the initial plan or certain "gates" are achieved when sales skyrocket?<br /><br />
Scrumorakel - Blognospam@example.com (Dominik Maximini)2015-09-01T14:04:02Zhttp://www.scrumorakel.de/blog/wfwcomment.php?cid=560http://www.scrumorakel.de/blog/rss.php?version=1.0&type=comments&cid=56Q & A on InfoQ
http://www.scrumorakel.de/blog/index.php?/archives/55-Q-A-on-InfoQ.html
Ben Linders reviewed "<a href="http://www.amazon.de/Scrum-Culture-Introducing-Organizations-Professionals/dp/3319118269/ref=sr_1_1?ie=UTF8&qid=1432562510&sr=8-1&keywords=the+scrum+culture" title="http://www.amazon.de/Scrum-Culture-Introducing-Organizations-Professionals/dp/3319118269/ref=sr_1_1?ie=UTF8&qid=1432562510&sr=8-1&keywords=the+scrum+culture">The Scrum Culture</a>" and published the results of our Q&A session on <a href="http://www.infoq.com/articles/book-the-scrum-culture" title="http://www.infoq.com/articles/book-the-scrum-culture">InfoQ</a>. Enjoy the read!<br /><br />
Scrumorakel - Blognospam@example.com (Dominik Maximini)2015-05-25T13:59:51Zhttp://www.scrumorakel.de/blog/wfwcomment.php?cid=550http://www.scrumorakel.de/blog/rss.php?version=1.0&type=comments&cid=55The Nature of Scrum Survey: Results underway!
http://www.scrumorakel.de/blog/index.php?/archives/54-The-Nature-of-Scrum-Survey-Results-underway!.html
If you participated in the "Nature of Scrum" Survey (see <a href="http://scrumorakel.de/blog/index.php?/archives/41-The-Nature-of-Scrum-Survey-awaits-you!.html" title="http://scrumorakel.de/blog/index.php?/archives/41-The-Nature-of-Scrum-Survey-awaits-you!.html">here</a>, <a href="http://scrumorakel.de/blog/index.php?/archives/43-Scrum-culture-study-extended.html" title="http://scrumorakel.de/blog/index.php?/archives/43-Scrum-culture-study-extended.html">here</a> and <a href="http://scrumorakel.de/blog/index.php?/archives/47-Nature-of-Scrum-Survey-Analysis-started.html" title="http://scrumorakel.de/blog/index.php?/archives/47-Nature-of-Scrum-Survey-Analysis-started.html">here</a> for more details), you just received an email with the survey results. In fact, you received a digital copy of my new book "<a href="http://www.amazon.de/gp/product/3319118269/ref=as_li_qf_sp_asin_il_tl?ie=UTF8&camp=1638&creative=6742&creativeASIN=3319118269&linkCode=as2&tag=scrumorakelde-21&linkId=JFTNX52OLLOYIZAZ" title="http://www.amazon.de/gp/product/3319118269/ref=as_li_qf_sp_asin_il_tl?ie=UTF8&camp=1638&creative=6742&creativeASIN=3319118269&linkCode=as2&tag=scrumorakelde-21&linkId=JFTNX52OLLOYIZAZ">The Scrum Culture</a>". Unfortunately, I received quite a few server errors, telling me people are working for different employers now or have misspelled their addresses. So if you did participate in the study but are still waiting for your email, first check your Spam folder and then ping me with your full name and current email address. I will double-check the result data and send you your copy right away.<br />
<br />
Enjoy the read!<br />
<br />
<br />
Scrumorakel - Blognospam@example.com (Dominik Maximini)2015-02-02T21:21:06Zhttp://www.scrumorakel.de/blog/wfwcomment.php?cid=540http://www.scrumorakel.de/blog/rss.php?version=1.0&type=comments&cid=54Scaling Scrum
http://www.scrumorakel.de/blog/index.php?/archives/53-Scaling-Scrum.html
During the last year, more and more customers asked about „how to scale Scrum“. Usually, what they wanted to say was: “We have many teams here, working on several products. How can we make sure they all do the same thing?”<br />
Generally, the term “scaling” applies to having multiple teams working on the same thing. Some nuggets for you right from the start:<br />
<br /><b>Three golden Rules</b><br />
<ol><br />
<li>No matter which scenario you encounter, there is one golden rule of Agile you always have to heed: Use your primary tool (which is the grey mass between your ears) to find a suitable solution for your specific context. You will have a hard time finding an out-of-the-box solution that really fits you 100%. There is no “one size fits all” when it comes to organizational development.</li><br />
<li>Start small and get it right first. Whatever you have when you start scaling will be scaled. That means, if you have a crappy “Scrum But” implementation for one team, you will get to an even crappier “Scrum But” implementation for 20 teams after scaling. If you have a well-working implementation of Scrum for one team, your chances are good to get to a well-working scaled situation.</li><br />
<li>Take one step at a time. While there are examples where changing 800 (and more) people at once actually worked, it usually doesn’t. If you have one well-working team, add one to three and get them to work as well. Once they do, add more teams or practices.</li><br />
</ol><br />
Unfortunately, people sometimes mean very different things when they talk about “scaling”. There are different scenarios you might encounter:<br />
<ol><br />
<li>One Team is working on several products at the same time</li><br />
<li>There are several sites involved in the development effort, no matter with how many teams (virtual teams)</li><br />
<li>There are 2-10 Scrum Teams working on the same product</li><br />
<li>There are >10 Scrum Teams working on the same product</li><br />
<li>There are 2-10 Teams (with Scrum or without) working on different products, with no dependencies</li><br />
<li>There are 2-10 Teams (with Scrum or without) working on different products, with dependencies</li><br />
<li>There are >10 Teams (with Scrum or without) working on different products, with dependencies</li><br />
<li>The development department is working Agile and now the rest of the organization should align</li><br />
</ol><br />
For all of these eight scenarios, I will give you some explanations and hints how to handle them. If you have additional examples, let me know. I will try to incorporate them.<br />
<br />
<strong>1. One Team is working on several products at the same time</strong><br />
<br />
Personally, I wouldn’t consider this a “scaled” scenario. It is plain multitasking. It is what we usually try to get rid of when we introduce agile methods. While this can be okay in service environments, it is not in development. Your people will lose focus and traction if they have to switch between tasks. The way to do this “properly” is to define several Sprints for one product and only start work on additional products later (e.g. three months product A followed by three months product B).<br />
<br />
<strong>2. There are several sites involved in the development effort, no matter with how many teams (virtual teams)</strong><br />
<br />
Yes, you can work with distributed (separate teams at separate locations) and dispersed (members of one team at separate locations) teams in Scrum. However, this is usually not cost-effective, if not managed properly (also see this for the reasons: http://scrumorakel.de/blog/index.php?/archives/32-The-reasons-why-distributed-teams-are-less-effective.html). If you refrain from just looking at the hourly rates and start calculating coordination time and result quality, chances are that outsourcing doesn’t pay off.<br />
So what you have to do is to reduce the virtual distance. This means you have to make sure infrastructure and technology fit the job and people know each other on a personal level. So, fly everyone to every location once in a while and use a month or two in the beginning of the project to have everybody work together in person. While they are not working together, send ambassadors over to each location and make sure technology is always working with a single click so people have their colleagues at their fingertips. The intensity of your measures depends on the degree of virtual distance you are facing and on the question if you are working distributed or dispersed (dispersed teams need more attention than distributed ones).<br />
<br />
<strong>3. There are 2-10 Scrum Teams working on the same product</strong><br />
<br />
Having more than one team working on a product is what usually is meant by the term “scaling”. Two teams rarely need special attention since people just talk – especially if they are sitting in the same room. Three to ten teams do need your attention in several areas:<br />
<ul><br />
<li>a. Roles</li><br />
<li>b. Knowledge sharing</li><br />
<li>Meetings</li><br />
<li>Artifacts</li><br />
<li>Quality</li><br />
<li>Architecture</li><br />
<li>Development tools</li><br />
<li>Coding guidelines </li><br />
<li>Team rules / charters</li><br />
</ul><br />
Mind the first golden rule: Use your brain and find your own way!<br />
You will have to decide if your Product Owner (there is one product, so there should be a single Product Owner) can handle 10 teams at once the way he used to. You will also discuss the need for “central” roles or hierarchies (“Chief Product Owner” or “Super Scrum Master”). My personal experience is that you should refrain from such hierarchies if at all possible. They introduce a command and control element you tried to get rid of earlier. Instead, let the teams self-organize around the problems that are introduced with scaling. Quite often, teams will just introduce a community of practice to solve the roles and knowledge-sharing aspects. They will also be able to find the right amount of meetings: Maybe one joint Sprint Planning and joint Sprint Review (instead of 10 individual meetings) is enough for all teams? Maybe you still need separate meetings, but can shorten them? Maybe people want to listen in on their respective Daily Scrums? Maybe they find this unnecessary? One thing is sure, however: There is one Product Increment, so there must be one Product Backlog, a common understanding of quality and an overarching architecture (not necessarily design). This might lead to a need for common development tools and coding guidelines. However, I have seen many teams that did not use the exact same tools or exact same guidelines and still succeeded. In fact, they made a conscious decision for the better – which you should do as well. Let the people having the problems figure out the solutions!<br />
<br />
<strong>4. There are >10 Scrum Teams working on the same product</strong><br />
<br />
For some reason, having more than 10 teams working on the same product seems to be a natural boundary of some sort. In my personal experience, the coping mechanisms described above did not work as well here as they did in smaller scaled environments. On top of that, I experienced a massive performance drop over and over again when more than ten teams were working in the same code base. Communication needs and coordination overhead seems to grow exponentially. Whenever I have the choice, I prefer 7 to 70 teams mingling in the same code base. My honest belief is that 7 teams can accomplish more in the same time than 70 do. If you do it anyway you will have to introduce some sort of structure. The exact nature of that structure is very specific to your context though – I cannot just draw you the silver bullet here. Just make sure to involve the people affected and try to replace controlling hierarchies with servant leaders, coaching the “subordinated” teams instead of incapacitating them. If you try to use defined frameworks for this scaling approach, make sure you don’t apply them without having reflected over every single aspect first. You might do more harm than good.<br />
<br />
<strong>5. There are 2-10 Teams (with Scrum or without) working on different products, with no dependencies</strong><br />
<br />
Well, if they do not have any dependencies, what do you want to scale? If there is actually an answer popping up in your head, try to figure out if this is just a relic from a time when you still could control everything. For example, some customers claim they need a “common architecture” across multiple products. However, when they take a closer look they usually figure out they neither have nor need this.<br />
<br />
<strong>6. There are 2-10 Teams (with Scrum or without) working on different products, with dependencies</strong><br />
<br />
Different products, but dependencies are what I encounter most often. So this is not about managing many teams on one code base, this is about managing interfaces. You probably have been doing this for years already. The difference with Scrum is that you no longer have silo groups of people but rather cross-functional teams. This can mean that every team having to interact with other products is allowed and capable to touch those products - if they make sure they don’t break anything (automated regression testing comes in handy here). Maybe coordination through communities of practice is enough. Maybe you need a “Scrum of Scrums”. Whatever you do, sit down with your teams and figure out what the problem is. Then use your primary tool (remember the grey mass?) to find solutions together with them. Try to keep it simple – scaling several products through several teams is not necessarily rocket science.<br />
<br />
<strong>7. There are >10 Teams (with Scrum or without) working on different products, with dependencies</strong><br />
<br />
Here the same rules apply. Usually, not all (say, 50) teams have dependencies with all other teams. Especially not if they are truly cross-functional. So it is not any more difficult than 6. <br />
I only encounter such huge unmanageable dependencies if there are remains from the past: A joint “framework” team, providing some stuff for all other teams, not letting them change it themselves. A “core product” team, servicing a huge pile of failure from the past, so messy only these few cracks still understand it – kind of. Or some sort of back-end / front-end separation, resulting in teams always waiting for one another, always claiming “we adhered to the interface specification” and still not achieving a truly “done” product increment. <br />
All these issues are symptoms that you didn’t do your homework. You scaled crap. No process on earth can make this work well without getting rid of the root causes first. This, however, is extremely hard work and not part of the “scaling” domain.<br />
<br />
<strong>8. The development department is working Agile and now the rest of the organization should align</strong><br />
<br />
Most often, IT middle management asks this question. They implemented some sort of Water-Scrum-Fall (meaning programming happened in Sprints, but analysis and QA happened in separate phases) and at some point realized that while they could code better, the other processes did not keep up with their pace and quality. This is natural to happen and a good thing! It is not what I would consider “scaling”, but it definitely is worth discussing. Changing parts of the organization is called “organizational development”. You can only succeed here, if all affected parties have an urgency to change and support your solution (in this case: Scrum). If you accomplished this, you have to develop solutions with all affected parties and generate wins that prove you are on the right track. Do this and stick to the golden rules above (and read more about the topic of organizational change, e.g. here or here).<br />
<br />
This article is just a brief overview on the topic of scaling, of course. To find appropriate answers for your specific situation, you will probably have to read and learn a lot (also see the reading recommendations below). In general, stick to the golden rules and always solve problems with your solutions rather than introducing some remedy without knowing your problem. <br />
Enjoy the transition!<br />
<br /><br /><br />
<strong>Reading recommendations:</strong><br /><br />
<a href="http://www.amazon.de/gp/product/3319118269/ref=as_li_qf_sp_asin_il_tl?ie=UTF8&camp=1638&creative=6742&creativeASIN=3319118269&linkCode=as2&tag=scrumorakelde-21&linkId=LAUC2LJ6VTAI3XCI" title="The Scrum Culture">Maximini – <em>The Scrum Culture</em>:</a> This explains what cultural impact Scrum can have, how this culture can scale and how to apply Kotter’s model on Scrum introductions.<br />
<a href="http://www.amazon.de/gp/product/1422186431/ref=as_li_qf_sp_asin_il_tl?ie=UTF8&camp=1638&creative=6742&creativeASIN=1422186431&linkCode=as2&tag=scrumorakelde-21&linkId=ETXIHR2D4MDLCEEN" title="Leading Change">Kotter – <em>Leading Change</em>:</a> Excellent book about how to go about organizational change.<br />
<a href="http://www.amazon.de/gp/product/B0046EDOYU/ref=as_li_qf_sp_asin_il_tl?ie=UTF8&camp=1638&creative=6742&creativeASIN=B0046EDOYU&linkCode=as2&tag=scrumorakelde-21&linkId=P2R46FJFFR2CMQSZ" title="Practices for Scaling Lean and Agile Development">Larman & Vodde - <em>Practices for Scaling Lean & Agile Development</em>:</a> – One of the best books about scaling Scrum. Be aware though that you are reading an opinion, not a silver bullet.<br />
<a href="http://www.amazon.de/gp/product/0470193956/ref=as_li_qf_sp_asin_il_tl?ie=UTF8&camp=1638&creative=6742&creativeASIN=0470193956&linkCode=as2&tag=scrumorakelde-21&linkId=AJAXQRMXQ6NR3JAA" title="Uniting the Virtual Workforce">Lojeski & Reilly - <em>Uniting the Virtual Workforce</em>:</a> Everything you ever wanted to know about virtual teams, including the virtual distance model<br />
<br /><br />
Scrumorakel - Blognospam@example.com (Dominik Maximini)2015-01-19T16:47:28Zhttp://www.scrumorakel.de/blog/wfwcomment.php?cid=530http://www.scrumorakel.de/blog/rss.php?version=1.0&type=comments&cid=53The Scrum Masters' Pyramid of Impediments
http://www.scrumorakel.de/blog/index.php?/archives/52-The-Scrum-Masters-Pyramid-of-Impediments.html
When working with different customers, I encounter a pattern over and over again. This pattern is closely connected to the Agile maturity of the Team (and organization). I call it the "Pyramid of Impediments":<br />
<!-- s9ymdb:22 --><img class="serendipity_image_center" width="692" height="406" src="http://www.scrumorakel.de/blog/uploads/PyramidOfImpediments.PNG" title="Pyramid of Impediments" alt="Pyramid of Impediments" /><br /><br /><br />
When I start working with a team, all impediments popping up are circling around the questions of what Scrum is, how it works and how it can be applied in the specific contexts encountered. For example, a distributed team might ask the question of how to conduct an efficient Daily Scrum. The questions vary, but they are always similar. They form the "base" of the pyramid.<br />
Often starting simultaneously, I as a Scrum Master have to forge a Team out of individuals. So while learning Scrum, they also learn to trust each other and to act responsibly as a team. This team level stuff forms the 2nd layer of impediments.<br />
Once the team is working together reasonably well and has understood Scrum, impediments often shift towards technology. Questions like, "Hey, we want to deliver every two weeks, but we do not have automated regression tests" or, "we need continuous integration facilities if we want to work together with these other teams" are usually coming up then. While I personally don't have a clue how to set these up, I still can coach the team to manage this themselves or escalate it throughout the organization. This is the third level of the pyramid and the first level visibly reaching out to other parts of the organization.<br />
Once technology works well, the impediment focus shifts toward adjacent teams / functions / departments. Basically, the team now can truly deliver "Done" product every Sprint but the rest of the organization can't. So while the Development Team delivers every two weeks, requirements might take eight weeks to reach the team and QA might need another six weeks to put something into production. Understandably, the Dev Team then starts to ask why they should deliver so frequently if the others don't - and good Product Owners ask why the realization of value is deferred that long. So at this level the Scrum Master starts to work along the value chain of creating the product (usually something along the lines of ideation - innovation - requirements elicitation - Product Backlog refinement - product creation (usually already fixed at this point) - quality assurance (if it still has elements separated from product creation) - integration (with several teams or big products) - releasing). Individual cases vary of course, but this is roughly how it works.<br />
Once the whole value chain is optimized, usually other process issues, affecting the whole organization, are hurting. Most often budgeting, career paths, compensation, portfolio management, etc. are focused on. Here, the Scrum Master has to fully act as a change agent throughout the whole organization.<br /><br /><br />
Certainly no impediment is "solved" by the sole competence of the Scrum Master. Instead, he/she coaches the involved and affected parties to find their own solutions and to inspect these regularly. These parties change naturally when moving up through the pyramid of impediments. An excellent Scrum Master can handle them all. If you don't have one, use a team of Scrum Masters with different skills (maybe you have one team forming expert and one change agent working hand-in-hand while facilitating their respective Scrum Teams and influencing the organization...) to supplement each other. Be aware that all "levels" of the pyramid will stay relevant throughout the whole lifecycle of your product/team and one will often "fall back" on a lower level for a time. This is normal. Of course you cannot work on the organizational level if the team is back to "storming" again - you then have to address this impediment first. However, the time being spent on higher level issues increases with time and the maturity of the team.<br /><br /><br />
While all models are wrong, some are helpful. Maybe this one supports you when you are looking for a Scrum Master, evaluating your Scrum implementation or being asked, what the "Scrum Master does all day". <img src="http://www.scrumorakel.de/blog/templates/default/img/emoticons/wink.png" alt=";-)" style="display: inline; vertical-align: bottom;" class="emoticon" /><br />
<br /><br />
Scrumorakel - Blognospam@example.com (Dominik Maximini)2014-11-17T06:37:14Zhttp://www.scrumorakel.de/blog/wfwcomment.php?cid=520http://www.scrumorakel.de/blog/rss.php?version=1.0&type=comments&cid=52"This is not Agile!"
http://www.scrumorakel.de/blog/index.php?/archives/51-This-is-not-Agile!.html
Did you ever argue with a "Scrum Coach" who told you that your Scrum introduction was proceeding too slowly? That solutions you fought hard for were "not agile"? And did you at the same time have the feeling that so many changes were happening at once that you were overrun by them? Or have you been the coach in a transition project and had the feeling that "everything is moving into the wrong direction"?<br />
If this is the case you are in the good company of most people who actively took care of a Scrum introduction.<br />
<br />
First, one insight is essential: Neither Agility nor Scrum are ends in themselves. Nobody should try to introduce Scrum just to "have it". That's not the point. Scrum is a tool which helps you to gain transparency and become agile. You only should pursue the goal of Agility if this solves existing problems and improves the whole system at the same time. This means that the purpose of a Scrum introduction is always and without exception the improvement of your organization's ability to compete.<br />
Therefore you have to ensure smoothly running regular operations during a Scrum introduction. This is especially important since such a big change can take months or even years to implement. No company can afford to stay unproductive for so long - and Agility does not just occur over night. As a rule of thumb you can say: The bigger the enterprise, the longer it takes to achieve Agility, as does every single step on this way.<br />
The reason for this high demand of time is that people change slowly. This is a good thing! Imagine a world where every human being fundamentally changes his attitude every five minutes. Chaos would reach a degree most of us shouldn't want to strive for... The same is true for organizations: These systems are usually in an equilibrium that is disturbed by the introduction of agile methods. Now it is important to retain a sufficient amount of stability while allowing some evolution at the same time. Thus there is nothing else for it but to accept the slow speed of change and to adapt to it. Change never happens against the people concerned - it can only be successful together with people. This leads to two conclusions:<br />
<br />
We have to make sure people involved in the change do not panic. Everybody will have to leave her comfort zone and move on into the "learning zone". The "panic zone" is then just a tiny step away and must be avoided since panicking people no longer think rationally and are not able to see or even value the positive aspects of this change.<br />
The affected parties must generate successes and realize that they are successful indeed in order to keep their spirits up.<br />
You only have a chance to successfully introduce Scrum and influence the organization's culture positively if both aspects are fulfilled.<br />
"Hybrid approaches" - mixes of traditional and agile processes or ways of thinking - can help to pick people up where they are and take them along while not overstraining them. In practice this means that such hybrids are okay as long as they help the organization and are seen as an intermediate solution on the path to Agility. The introduction of agile methods is a journey - every step into the right direction helps, it doesn't always have to be a quantum leap. Agile Coaches must be aware of this. View the coach as some sort of midwife: She supports the mother-to-be with farsightedness and experience to give birth to her child. But the midwife does not have to go through the pain herself. Demanding to "finish pregnancy faster" or "get the child out quicker" does not help, no matter how fervently it is stated.<br /><br /><br />
Scrumorakel - Blognospam@example.com (Dominik Maximini)2014-08-22T09:31:19Zhttp://www.scrumorakel.de/blog/wfwcomment.php?cid=510http://www.scrumorakel.de/blog/rss.php?version=1.0&type=comments&cid=51How to explain the Scrum Culture
http://www.scrumorakel.de/blog/index.php?/archives/50-How-to-explain-the-Scrum-Culture.html
While the new book on this topic is still awaiting its publication I will try to explain the cultural aspects of Scrum to conference attendees at the Scrum Day Germany (1st and 2nd of July) and at the Scrum Day Europe (3rd of July). But how is it possible to convey such a complex topic within 40 minutes? How to explain what culture is, how to identify and analyze its components, what critical aspects might lead to conflict? I have no clue and thus decided to tackle this impediment empirically with an A/B Test.<br />
<br />
The first approach (in Germany) will be the more traditional one. A fancy (well - more or less...) presentation following a clear path and not necessarily requiring any interaction with the audience. In Amsterdam (Scrum Day Europe) I will conduct a workshop on the topic. The participants will be heavily involved and won't be able to get away without collaborating. Only a couple of slides will set the stage before everybody gets to work. This workshop will be adapted and repeated on the same day.<br />
So while the German conference sets a baseline in participant satisfaction, the new approach will measure twice if the collaborative workshop approach is superior.<br />
<br />
The results will then help to improve the explanation method further. I will of course let you know how it went <img src="http://www.scrumorakel.de/blog/templates/default/img/emoticons/smile.png" alt=":-)" style="display: inline; vertical-align: bottom;" class="emoticon" /><br /><br />
Scrumorakel - Blognospam@example.com (Dominik Maximini)2014-06-13T15:03:27Zhttp://www.scrumorakel.de/blog/wfwcomment.php?cid=500http://www.scrumorakel.de/blog/rss.php?version=1.0&type=comments&cid=50Change Is Hard
http://www.scrumorakel.de/blog/index.php?/archives/49-Change-Is-Hard.html
Did you ever notice how hard it is for people to change? I constantly run into this phenomenon when introducing Scrum.<br />
You don't have to go that far though. Take a look around, you can see it everywhere!<br />
<br />
Last week I ate some breakfast at a hotel. The room was not crowded and a couple of other people shared my love for early food. At some point a couple came into the room and went into the direction of the table they supposedly had used the day before. Half way through they noticed that the seat was taken. They stalled and started a discussion about the fact that "their" table was taken. I listened and was kind of amused to see that such a thing could be the topic of a discussion. Interestingly, they did not stop. The couple continued to discuss this for the next 15 minutes. And they were not alone: Some more couples - probably all from the same party - encountered the same problem and reacted exactly the same way. I noticed three of those instances before I finished my breakfast and left.<br />
<br />
Using the table next from the one you used before is only a tiny change. It does not outlive breakfast or change your life. Still, it can cause you to leave your comfort zone and thus cause an uneasy feeling. People like their habits. People enjoy their comfort zones. This is human. You never know how the comfort zone of any individual looks like until you exceed it.<br />
<br />
If such small changes lead to (at least internal) conflicts you definitely should expect that introducing a cultural change trigger like Scrum (or Agile as such) causes a much higher level of uneasiness and conflict. Be prepared for this to happen and help people by showing them the urgency of the change and the strategy how to solve the riddle. Aid them through their journey. Help them find another - hopefully better - breakfast table!<br />
<br /><br /><br />
Scrumorakel - Blognospam@example.com (Dominik Maximini)2014-05-10T10:00:54Zhttp://www.scrumorakel.de/blog/wfwcomment.php?cid=491http://www.scrumorakel.de/blog/rss.php?version=1.0&type=comments&cid=49Nature of Scrum Survey: Analysis started
http://www.scrumorakel.de/blog/index.php?/archives/47-Nature-of-Scrum-Survey-Analysis-started.html
In case you are wondering about the status of the survey, here is an update for you.<br />
I just started to group and sort the data. Due to the open questions, this is a lot of work though. Please have a little more patience and do not expect a thorough result before late December or even early next year.<br />
<br />
Let me know if you have any questions.<br /><br />
Scrumorakel - Blognospam@example.com (Dominik Maximini)2013-10-30T16:43:05Zhttp://www.scrumorakel.de/blog/wfwcomment.php?cid=470http://www.scrumorakel.de/blog/rss.php?version=1.0&type=comments&cid=47AgileTour Stuttgart
http://www.scrumorakel.de/blog/index.php?/archives/46-AgileTour-Stuttgart.html
The <a href="http://agiletour.de/" title="http://agiletour.de/">Agile Tour comes to Stuttgart</a> (Germany) next week (16th of October 2013). We took special care in selecting <a href="http://agiletour.de/programm2013/index.php" title="http://agiletour.de/programm2013/index.php">excellent speakers</a> to provide you with an unmatched community conference experience. Ken Schwaber will join us for a virtual talk as well. The primary conference language is German (aside from Gunther's and Ken's talks); if that is fine with you and you haven't booked your ticket yet, you should do it right away. You most likely won't get more for your buck (72 EUR).<br /><br />
Scrumorakel - Blognospam@example.com (Dominik Maximini)2013-10-10T03:44:29Zhttp://www.scrumorakel.de/blog/wfwcomment.php?cid=460http://www.scrumorakel.de/blog/rss.php?version=1.0&type=comments&cid=46A critical view on SAFe
http://www.scrumorakel.de/blog/index.php?/archives/45-A-critical-view-on-SAFe.html
The <a href="http://scaledagileframework.com/" title="http://scaledagileframework.com/">Scaled Agile Framework</a>, developed by Dean Leffingwell, is getting more an more traction in Europe and the U.S. Many companies try to adopt the framework, or parts of it, in order to increase their Agility. However, there is a controversial discussion in the community whether SAFe is really Agile or not. This post describes my view on that.<br />
<br />
<strong>Agile Manifesto</strong><br />
<br />
<a href="http://agilemanifesto.org/" title="http://agilemanifesto.org/">The Agile Manifesto</a> says:<br />
“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:<br />
<br />
Individuals and interactions over processes and tools<br />
Working software over comprehensive documentation<br />
Customer collaboration over contract negotiation<br />
Responding to change over following a plan<br />
<br />
That is, while there is value in the items on the right, we value the items on the left more.”<br />
<br />
That means that Agile comprises of continuous improvement, people, collaboration, product delivery, customer collaboration and requirements change. If a framework calls itself “Agile”, it should fulfill those.<br />
<br />
<br />
<br />
<strong>SAFe</strong><br />
<br />
First of all, I like Dean and the notion of having a solution for big companies that aids them in becoming Agile. If you don’t know SAFe yet, I recommend you visit <a href="http://scaledagileframework.com/" title="http://scaledagileframework.com/">http://scaledagileframework.com/</a>. That website is very well designed and shows you detailed information on all aspects of SAFe in the so-called “Big Picture”. <br />
In short, SAFe divides product development into three levels: Team, Program and Portfolio. Along with that go a couple of artifacts, roles and responsibilities. The devil is in those details (as of 11th of September 2013).<br />
<br />
<br />
<u>Team level</u><br />
<br />
The Team level is basically standard Scrum. But wait: Not 100% standard I would say.<br />
<ul><br />
<li>The Product Owner is not necessarily responsible for the return on invest of the product. This is attributed to the “Enterprise Product Manager”. In addition, the PO should “participate” in the “extended product management team” and is usually part of the development organization, not of product management. This means that we are back to the good old days where there was a chasm between product management and development rather than working hand-in-hand as it is intended in Scrum.</li><br />
<li>The Scrum Master is described as “management/leadership proxy” as a part-time role (25%) for a developer. He should also focus on spreading technical practices throughout the company. While technical practices are certainly important, this strong focus, the limited time and the complete lack to mention the role of a change agent means to me that SAFe does not want the Scrum Master to help spread Agility throughout the enterprise. So the main benefit of this role is chipped away.</li><br />
<li>The Development Team is called “Developers and Testers”. This is good, but lacking other roles such as UX, Architecture, Database, etc. We will encounter those again on the Program level. SAFe does not explicitly say that those roles may not be on the Development Team, but people reading the chart and looking at their own org charts may be tempted to think so. </li><br />
<li>SAFe involves a “HIP”-iteration, meant for “Hardening, Innovation and Planning”. It also gives some reasons why HIP-iterations are necessary: 1) Some quality measures might not be economical every Sprint and have to be done once per Release. 2) “care must be taken to provide scheduled time for innovation, exploration and out-of-box thinking”. 3) Release planning must happen somewhere. It is true that some quality measures cannot be taken every Sprint and need specific time allocated for that. On the other hand, innovation and release planning should not just happen once a release, but continuously. Imagine somebody walking up to you, saying “be innovative now, you got 3 weeks!” Doesn’t have the right ring to it. On top of that, the name “hardening” is a concept often already known to enterprises. If they sense that this is a good thing and their “solution” [SAFe] has it as well, they might just stick with what they have and not change a bit. So inspection and adaptation goes out the window.</li><br />
<li>There are common Releases for all teams prescribed. While this is not bad or a violation of Agile, I don’t like the fact that it is prescribed. What if a company would be better off having one always working “release branch” and all teams constantly contributing to it at different points in time?</li><br />
</ul><br />
<br />
<u>Program level</u><br />
<br />
The program level is designed to manage the team level in SAFe. While this is an existing condition in many companies it is not what Agile aims at. Let’s take a deeper look:<br />
<ul><br />
<li>The roadmap contains the higher-level planning for the Teams' backlogs. The first sentence explaining the roadmap speaks for itself: “The purpose of the program roadmap is to establish alignment across all teams involved in the ART [Agile Release Train] while also providing predictability to the deliverables over an established timeline horizon.” So the teams are not allowed to self-organize their alignment and predictability is the goal rather than maximization of value? Hmm...</li><br />
<li>Product management does all the prioritization and value analysis. SAFe accepts the status quo in many enterprises and distinguishes between Product Owner and Product Management. Product Management also does the customer interaction. This does not help collaboration but is a tayloristic division-of-labor approach.</li><br />
<li>By the way: There is a team of “Business Owners” who have the last say on ROI etc. So who is responsible now: Product Management, Product Owner, Business Owner – or maybe even somebody at the portfolio level? I lost track.</li><br />
<li>There is an additional Release Management Team that is responsible for coordinating the outcomes from the teams in a release. It comprises of senior management of different departments. Again, the teams are not doing this self-organizing but there is a central authority doing this.</li><br />
<li>A funny thing exists in SAFe and is called “System Team”. It is described as follows: “The system team is often responsible for initially building some of the initial common development infrastructure and then moves on to other program level activities, including system-level continuous integration and end-to-end testing.” While I do understand the need for somebody providing and maintaining the development infrastructure, this system team can be easily mistaken for a central quality institution. SAFe does say that the responsibilities are shared between the development teams and the system team, so the developers are still responsible. Unfortunately, the structure can easily be mistaken for the System Team ordering the development teams around on what to do. I believe the concept of “System Team” needs some intense rework.</li><br />
<li>There is a “Release Train Engineer”, described as “Uber-Scrum Master” or “Agile Program Manager”. While I do like the idea of having a Scrum Master on the level of management, I do not enjoy some of the responsibilities attributed to this garbled role: "Escalates impediments" (so he doesn’t solve them), "Reports status to Release Management Team" (which might lead that role to fulfill the needs of the RMT rather than those of a Scrum Master), "provides input on moving team members to address critical bottlenecks" (here the resource-shuffling game starts and shows the taylorisitc mindset again). SAFe does describe the RTE as being a servant leader, but the responsibilities make it hard for anybody filling that role to comply.</li><br />
<li>The UX function is also outsourced to the program level. They are not part of the development teams but rather “provide Agile Teams with the next increment of UI design, UX guidelines, and design elements in a just-in-time [...] fashion.” Where is the team approach? Collaboration? Do we now have to wait a Sprint before we get our UI design? Maybe two? Or three?</li><br />
<li>There is a System Architect role as well. He is to “evaluate design alternatives, and perform cost benefit analysis”. He also – amongst other things – responsible for creating Architectural Epics and Features for the development teams to implement. So the teams do not self-organize in that regard and are not responsible for their own architecture. Further down, the Architect is described as not being allowed to dictate anything but rather being a mentor and coach. In my opinion, this description does neither fit the stated responsibilities nor the standard (by traditional managers) understanding of the role and thus is not helping Agility.</li><br />
</ul><br />
<br />
<u>Portfolio level</u><br />
<br />
On the portfolio level, “programs are aligned to the enterprise business strategy and investment intent.” I believe this level to be important and won’t criticize much here since most enterprises will be busy with the program level anyway. It’s just important to note that there are again a couple of roles (Enterprise Architect, Epic Owner, Program Portfolio Management) with differing responsibilities.<br />
<br />
<br />
<strong>Conclusion</strong><br />
<br />
While I do not approve of the style <a href="http://kenschwaber.wordpress.com/2013/08/06/unsafe-at-any-speed/" title="http://kenschwaber.wordpress.com/2013/08/06/unsafe-at-any-speed/">Ken used to criticize</a> SAFe or the “one is better than the other” <a href="http://www.djaa.com/kanban-anti-safe-almost-decade-already" title="http://www.djaa.com/kanban-anti-safe-almost-decade-already">comparison of Anderson</a>, I do believe SAFe to be Janus-faced. It most certainly can be interpreted and lived in an Agile way and will work like a charm then. However, the descriptions and corresponding interpretations of most readers/users will lead to nothing but the preservation of the status quo. SAFe does not help to instill a different mindset. On the contrary: people don’t have to change with SAFe – they can just go on as they always did and call themselves Agile now. Two questions arise:<br />
<ol><br />
<li>Why is this a problem? I don’t need/want to be Agile!<br />
Well, then go with traditional models and don’t use one that has “Agile” in it’s name. A tool called “Scaled Agile Framework” should be Agile and you should only implement it if you want to be Agile.</li><br />
<li>Are there alternatives? <br />
Unfortunately, not many. But you might want to take a look at <a href="http://www.crosstalkonline.org/storage/issue-archives/2013/201305/201305-Larman.pdf" title="http://www.crosstalkonline.org/storage/issue-archives/2013/201305/201305-Larman.pdf">this little article by Larman and Vodde</a>. They have written a book on the topic as well and it is much closer to Agile in my opinion.</li><br />
</ol><br />
We also looked at the Agile Manifesto at the top of this post.<br />
Agile comprises of continuous improvement, people, collaboration, product delivery, customer collaboration and requirements change. In my opinion, SAFe fulfills product delivery, [arguably] customer collaboration and requirements change. It falls short of fulfilling continuous improvement (Agile Masters are ripped of their balls), collaboration (of different functions) and people (self-organization is hampered). SAFe itself is very much process-focused and not aiming at being optimized itself.<br />
<br />
It all can be summed up the following way:<br />
<br />
SAFe believes that the world is good as it is and the existing companies, processes and structures created that world. So the status quo has to be accommodated.<br />
Agile believes that the world is not a good place (at least for people working in software development) and should be improved. The status quo – especially the tayloristic thinking - has to be changed.<br />
<br />
This doesn’t fit together. SAFe isn’t Agile. It could be a small step on the way to Agility, but it certainly is not the end state (if something like this even exists in Agile).<br /><br /><br />
Scrumorakel - Blognospam@example.com (Dominik Maximini)2013-09-11T10:03:23Zhttp://www.scrumorakel.de/blog/wfwcomment.php?cid=459http://www.scrumorakel.de/blog/rss.php?version=1.0&type=comments&cid=45Book Review: The Professional ScrumMaster's Handbook (Stacia Viscardi)
http://www.scrumorakel.de/blog/index.php?/archives/44-Book-Review-The-Professional-ScrumMasters-Handbook-Stacia-Viscardi.html
I just read <a href="http://www.amazon.de/gp/product/1849688028/ref=as_li_ss_tl?ie=UTF8&camp=1638&creative=19454&creativeASIN=1849688028&linkCode=as2&tag=scrumorakelde-21">The Professional ScrumMaster's Handbook</a><img src="http://ir-de.amazon-adsystem.com/e/ir?t=scrumorakelde-21&l=as2&o=3&a=1849688028" width="1" height="1" border="0" alt="" style="border:none !important; margin:0px !important;" />, written by Stacia Viscardi, a Scrum coach. While the book was certainly entertaining, it was not exactly educating for me as a Scrum Coach; that is, I didn't learn much from it. If you are just embarking onto your Scrum Master journey, however, the book is nevertheless very valuable for you. I am a critical reviewer - you will notice that when reading this article. <img src="http://www.scrumorakel.de/blog/templates/default/img/emoticons/wink.png" alt=";-)" style="display: inline; vertical-align: bottom;" class="emoticon" /><br /><br />
Now, here is what I think:<br />
<br />
The audience is stated as "This book is not for ScrumPuppets who simply do what they're told; rather, The Professional ScrumMaster's Handbook is for anyone who wishes to be a true ScrumMaster as the role was originally intended: a fearless, professional change leader."<br />
I liked that excellent intro, which set very high expectations for me. Unfortunately, the brilliant term "ScrumPuppet" only appears once in the whole 308-pages-book and didn't even make it into the index. I was a little bit disappointed about this. In addition to that, the topic of organizational change is not covered deep enough to live up to my expectations as advertised. The topic of how to be a change agent is covered, while the higher-level process of changing a organization's culture is not. On the other hand, the book goes into depth what a Scrum Master should do and not do, which characteristics and skills he needs and so on. The true value, however, lies in the described experiences of the author, which are quite beneficial for the reader.<br />
<br />
Chapters 1 to 3 dive into Scrum. I very much liked the description of the history of Scrum, including it's roots and the background of Ken and Jeff. Very comprehensive, very good! Unfortunately that's about what I liked in those chapters. There is a constantly alternating mix between the core elements of Scrum and value-adding best practices. While this is certainly a good idea, an unexperienced reader will not be able to discern between those two and might conclude that everything described is part of Scrum, which is not the case. In addition to that, the author uses her own terminology in several places (e.g. "Scrum Delivery Team" on page 18) and also displays her own interpretation of the application of Scrum, without making the deviations from the Scrumguide (I won't discuss the differences of the Scrumguide and the Scrumalliance's Agile Atlas Core Scrum, since it is not "blessed" by Jeff and Ken) transparent (e.g. "everyone is welcome to attend" [the Daily Scrum] on page 21). In fact I got the impression that the author didn't read the Scrumguide and might lack some knowledge about the most recent developments of Scrum (e.g. commitment vs. forecast).<br />
<br />
In chapter 4, the tide turned for me. The author comes up with very clever and colorful comparisons (e.g. comparing the sprint boundaries to castle walls or comparing stressful pace with writing to the very last second in an exam - which of course doesn't exactly raise quality). She also gives good practical advice for certain situations a Scrum Master will face sooner or later. This trend continues through the next chapters as well. Here is one especially nice tidbit, I want to share with you (page 136): "Just like the snake sheds its skin every so often to reveal shiny new scales, an individual, a team, and an organization must shed its old culture skin by creating new knowledge and sharing stories about the new way of doing things."<br />
<br />
Of especially high value is chapter 6, where Stacia shows different information levels and compares them brilliantly with different magnification levels of a microscope. 1x magnification is the product vision, 2x the product roadmap, 4x the release plan, 8x the product backlog, 16x the sprint, 32x the tasks, and 64x the team room. Each magnification is explained and augmented by best practices and examples. The average reader benefits greatly from that.<br />
<br />
The author discusses the values of Scrum in chapter 7. A good idea with many important hints. Unfortunately, some important studies are mentioned - but not named or referenced in the text (e.g. pages 186 and 188). This is very unfortunate since this critical information cannot be used to work with management or critics - especially since this information is correctly displayed throughout the rest of the book. So yes, the information itself in this chapter is helpful, but you will have to do your own research to validate some of the points.<br />
<br />
Chapter 8 - Everyday Leadership for ScrumMaster and Team - straightens chapter 7 out again. An excellent self-reflection exercise and the plea to push your boundaries beyond the comfort zone fire off your thoughts and are supported by all sorts of analyses about your Scrum Master personality. Very helpful, especially for the just-starting Scrum Master.<br />
<br />
Chapter 9 deals with shaping the Agile Organization. I expected instructions for organizational change here, but wasn't able to find a central theme. My impression was that of a collection of interesting puzzle pieces that are scattered around, not forming a clear picture. So while the individual sections are interesting and good, don't expect them to form a wonderful sculpture.<br />
<br />
This gets a little bit better in chapters 10 and 11, where at least some of the (new) puzzle pieces are fitted together, still not forming a clear picture yet. However, even though the borders are blurry, you still can see some of it. In other words, some very important facts are highlighted and explained. There definitely is a lot to be learned from those chapters (for a new Scrum Master); still, the big picture evades my grasp. The title of chapter 10 is "Scrum - Large and Small", which is then followed by some challenges, which apply to small Scrum implementations as well (at least in my opinion). So the challenges are great to learn from, but they don't specifically contribute to large-scale Scrum. Some other important aspects of scaling Scrum are not mentioned at all - so don't expect a scaling-Scrum-guide or something like that!<br />
<br />
Summing it up, there is a lot of useful information in that book. A new Scrum Master should read it to learn from Stacia's experience. However, the new Scrum Master should not read it as his first book, because he could get confused by the aforementioned statements. In addition, after you read about the history of Scrum, hop on to chapter four. Be aware that this book seems to be a "Minimum Viable Product" with still some room for improvement. I count on the second edition removing the shortcomings of this first one and raising the books value even higher!<br /><br /><br /><img src="http://vg01.met.vgwort.de/na/8d3d322fc2e54e8fbc5de1521fcfa067" width="1" height="1" alt="">
Scrumorakel - Blognospam@example.com (Dominik Maximini)2013-08-11T11:59:06Zhttp://www.scrumorakel.de/blog/wfwcomment.php?cid=440http://www.scrumorakel.de/blog/rss.php?version=1.0&type=comments&cid=44Scrum culture study extended
http://www.scrumorakel.de/blog/index.php?/archives/43-Scrum-culture-study-extended.html
You most likely will remember the start of our great study, the <a href="http://scrumorakel.de/blog/index.php?/archives/41-The-Nature-of-Scrum-Survey-awaits-you!.html" title="http://scrumorakel.de/blog/index.php?/archives/41-The-Nature-of-Scrum-Survey-awaits-you!.html">"Nature of Scrum Survey"</a>. The original idea was to collect 200 or more responses (so it is remotely statistically validate-able) and conduct the statistical analysis in August. Even though many people participated and offered their opinions, only 165 replies (74 for the Schneider questionnaire) could be gathered. This is not enough, as you can see in the burndown chart (yellow is the main study, blue the Schneider add-on):<br /><br />
<!-- s9ymdb:18 --><img class="serendipity_image_center" width="540" height="380" src="http://www.scrumorakel.de/blog/uploads/burndown_cw29.png" title="Burndown" alt="Burndown" /><br /><br />
To make this even worse, there was a break out of the summer holiday epidemic, so a simple extension by a week or two won't work. Instead I decided to extend the data entry period to end of September / early October. If you are waiting for the results, this means that you will have to wait a little while longer - sorry about that. I believe this to be necessary since the quality of the results is more important than a quick answer.<br /><br /><br />
In case you want to support the endeavor and haven't filled out the survey yet, visit <a href="http://scrumorakel.de/surveys/" title="http://scrumorakel.de/surveys/">http://scrumorakel.de/surveys/</a> and sacrifice some of your precious time. You are of course welcome to spread the link among your networks. The more replies we get, the better the results will be.<br /><br /><br />
<br />
<br />
Scrumorakel - Blognospam@example.com (Dominik Maximini)2013-07-21T12:46:08Zhttp://www.scrumorakel.de/blog/wfwcomment.php?cid=430http://www.scrumorakel.de/blog/rss.php?version=1.0&type=comments&cid=43Lean Startup is on the rise
http://www.scrumorakel.de/blog/index.php?/archives/42-Lean-Startup-is-on-the-rise.html
Have you already heard about Lean Startup? It's a valuable method to reduce uncertainty and reduce complexity. In my opinion, it's a tool every Product Owner should know. It's also a must-have for every startup and research project. I won't explain the method now since it is quite straightforward (if you want to learn more, read the book <a href="http://www.amazon.de/gp/product/0670921602/ref=as_li_ss_tl?ie=UTF8&camp=1638&creative=19454&creativeASIN=0670921602&linkCode=as2&tag=scrumorakelde-21">The Lean Startup: How Constant Innovation Creates Radically Successful Businesses</a><img src="http://ir-de.amazon-adsystem.com/e/ir?t=scrumorakelde-21&l=as2&o=3&a=0670921602" width="1" height="1" border="0" alt="" style="border:none !important; margin:0px !important;" />). <br /><br /><br />
What I am noting is the rise in Lean Startup events. The community seems to be growing significantly. A very interesting mix of people, consisting of entrepreneurs, big company people, "normal" Scrummers - they are all there. If this is an interesting piece of information for you, keep your eyes open for a LeanStartup Meetup or a LeanCamp. For example, soon there will be a LeanCamp in <a href="http://leancamp.co/stuttgart/" title="http://leancamp.co/stuttgart/">Stuttgart</a>. Looking forward to meet you there!<br /><br /><br />
Scrumorakel - Blognospam@example.com (Dominik Maximini)2013-07-11T20:44:34Zhttp://www.scrumorakel.de/blog/wfwcomment.php?cid=420http://www.scrumorakel.de/blog/rss.php?version=1.0&type=comments&cid=42The "Nature of Scrum Survey" awaits you!
http://www.scrumorakel.de/blog/index.php?/archives/41-The-Nature-of-Scrum-Survey-awaits-you!.html
What is the nature of Scrum? What are it's cultural characteristics? What are companies going to face if they introduce Scrum while trying to maintain their existing corporate cultures?<br />
<br />
I am going to find out - with your help!<br />
At <a href="http://scrumorakel.de/surveys/" title="http://scrumorakel.de/surveys/">http://scrumorakel.de/surveys/</a> you can find two surveys, each of which will take you around 30 minutes to complete. While this is quite a lot of time I am asking of you, you will help thousands of companies worldwide in their Scrum adoption. This might include your own as well at some point in time. If you have to make a choice, only do the first survey. They are ordered in terms of business value <img src="http://www.scrumorakel.de/blog/templates/default/img/emoticons/smile.png" alt=":-)" style="display: inline; vertical-align: bottom;" class="emoticon" /><br />
<br />
Be part of the Agile spearhead and help to make the world a better place to work in!<br />
In exchange for your effort, you of course will receive the results of the study as soon as they are available.<br />
<br />
The survey will only be available for a limited amount of time. Don't miss your opportunity.<br />
<br />
Note: If you are attending the Scrum Day in Berlin this year, I suggest you fill out the survey there. <br /><br />
Scrumorakel - Blognospam@example.com (Dominik Maximini)2013-05-15T14:42:43Zhttp://www.scrumorakel.de/blog/wfwcomment.php?cid=415http://www.scrumorakel.de/blog/rss.php?version=1.0&type=comments&cid=41Drowning in Spam
http://www.scrumorakel.de/blog/index.php?/archives/40-Drowning-in-Spam.html
As soon as I had more than 1.000 unique visitors a day, a massive Spam attack was launched on this Blog (or maybe it was unrelated). This basically means that many many people (or robots) wrote comments to my articles. They all went into the same direction: "Great Blog ... unspecific blablabla ... fantastic something generic ... blabla ... link to an website that wants to sell you porn/viagra/some-other-stuff-you-definitely-don't-need".<br />
Since I am not in the mood of deleting dozens of comments each day, I hardened the comment policy for this Blog: You now can only write a comment within 14 days after the post has been released. Afterwards, you will have to send me an email in order to publish your comment or to release the barrier for a restricted amount of time.<br />
<br />
Sorry for the inconvenience!<br />
<br />
Scrumorakel - Blognospam@example.com (Dominik Maximini)2013-05-10T16:02:51Zhttp://www.scrumorakel.de/blog/wfwcomment.php?cid=400http://www.scrumorakel.de/blog/rss.php?version=1.0&type=comments&cid=40Taylorism and Resources
http://www.scrumorakel.de/blog/index.php?/archives/39-Taylorism-and-Resources.html
Frederick Winslow Taylor wrote his Book "Scientific Management" back in 1911. His book is <a href="http://ia700208.us.archive.org/15/items/principlesofscie00taylrich/principlesofscie00taylrich.pdf" title="http://ia700208.us.archive.org/15/items/principlesofscie00taylrich/principlesofscie00taylrich.pdf">available for free online</a> - consider reading it. Taylor wanted to end the "waste of manpower" and stated that "In the past the man has been first; in the future the system must be first." (p. 7) Taylor quickly added: "This in no sense, however, implies that great men are not needed. On the contrary, the first object of any good system must be that of developing first-class men; and under systematic management the best man rises to the top more certainly and more rapidly than ever before."<br /><br />
While this sounds pretty good, his own work clearly shows that he did not regard workers as more than a cog in the machinery. His basic assumption was that workers didn't put all their effort into their work. "For every individual, however, who is overworked, there are a hundred who intentionally underwork - greatly underwork - every day of their lives, and who for this reason deliberately aid in establishing those conditions which in the end inevitably result in low wages." (p. 18)<br />
Taylor wanted to change this condition in order to increase the wealth of the United States by improving the situation for both workers and companies. His way to do this was: "to work according to scientific laws, the management must take over and perform much of the work which is now left to the men; almost every act of the workman should be preceded by one or more preparatory acts of the management which enable him to do his work better and quicker than he otherwise could." (p. 26) - <a href="http://en.wikipedia.org/wiki/Scientific_management" title="Scientific Management">Scientific Management</a> was born. It states that managers have to "gather together all of the traditional knowledge which in the past has been possessed by the workmen and then of classifying, tabulating, and reducing this knowledge to rules, laws, and formulae which are immensely helpful to the workmen in doing their daily work." (p. 36). In addition, manager have to "develop a science for each element of a man's work, which replaces the old rule-of-thumb method", "scientifically select and then train, teach, and develop the workman, whereas in the past he chose his own work and trained himself as best he could", "heartily cooperate with the men so as to insure all of the work being done in accordance with the principle of the science which has been developed" and "there is an almost equal division of the work and the responsibility between the management and the workmen. The management take over all work for which they are better fitted than the workmen [...]." (ibid.)<br /><br />What does this mean?<br />
It means that Taylor wants the worker to stop all thinking. He considers thinking something the manager has to do. The manager is the one who should know the job of the worker in all details and to spell out how this worker should do the work. It also means that the work should be simplified and atomized to an extend "that it would be possible to train an intelligent gorilla so as to become a more efficient pig-iron handler than any man can be." (p. 40)<br /><br />
Of course, I don't approve. While Taylor certainly had the best intentions, he created a tool that helps to make people obsolete and worsen their working conditions. While it may have been adequate back in 1911, it certainly is not in todays economy. However, there are some successors to Scientific Management that can be useful in certain situations: Operations Management, Operations Research, Cybernetics, Total Quality Management, Six Sigma and Lean Manufacturing (maybe some more). <br /><br />The first thing that is important to notice is that all tools have their use - but if you use them in the wrong context, you might hurt your goal. Ever tried to drill in a screw with a hammer? There you go.<br /><br /><br />
Closely connected with Scientific Management is the phrase "resource" for employees. You maybe have seen a situation where somebody just put "some more resources" onto a project. Let's look at the term resource: "An available supply that can be drawn on when needed. Often used in the plural." (<a href="http://www.thefreedictionary.com/resource">the free dictionary</a>). It is also defined as "The total means available to a company for increasing production or profit, including plant, labor, and raw material; assets" (ibid.)<br />So I am a "means" to my employer. We should check what "means" means in that context: "the medium, method, or instrument used to obtain a result or achieve an end" (<a href="http://www.thefreedictionary.com/means">the free dictionary</a>).<br /><br /><br />
Now we can see the connection between the term "resource" (used for an employee) and Taylorism: Both imply that the human being is merely an "instrument used to obtain a result".<br /><br /><br />
In today's world, people don't want to be just an instrument. They want to be valued for their personality, their resourcefulness (isn't it interesting how this word can also mean something tremendously positive?), their efforts and their learning. Some even want to find personal fulfillment in their work. This is especially true for well educated people in the western hemisphere, for example software developers, managers, Product Owners and Scrum Masters. So here is the 2nd thing we can learn from that: Never call your colleagues "resource"!<br /><br /><br /><br />
<img src="http://vg01.met.vgwort.de/na/6ccbc325df594d12ac0da9a27d229597" width="1" height="1" alt=""><br />
Scrumorakel - Blognospam@example.com (Dominik Maximini)2013-04-07T11:15:42Zhttp://www.scrumorakel.de/blog/wfwcomment.php?cid=390http://www.scrumorakel.de/blog/rss.php?version=1.0&type=comments&cid=39One Scrumguide is not enough
http://www.scrumorakel.de/blog/index.php?/archives/38-One-Scrumguide-is-not-enough.html
Yesterday I met my friend and fellow trainer <a href="https://www.scrum.org/User-Profile/userId/153" title="https://www.scrum.org/User-Profile/userId/153" target="_blank">Jean Pierre Berchez</a>. We discussed some concepts from the <a href="https://www.scrum.org/Scrum-Guides" title="https://www.scrum.org/Scrum-Guides" target="_blank">Scrumguide</a>. As you probably know, the principles of Scrum (like inspection and adaptation) are constantly applied on Scrum itself. That means, the Scrumguide is evolving in an iterative way. There are constantly some discussions going on, if some best practices (e.g. the DoD) should be declared "mandatory" in Scrum or if some other parts (e.g. the distinction between Sprint Planning 1 and 2) should be removed.<br />
<br />
We discovered that the answer to those questions depends on who is asking them.<br />
<br />
I am sure you are aware of Shuhari. It is a Japanese martial arts concept that describes different stages of learning. Shuhari roughly translates to "first learn, then detach, and finally transcend." The "shu"-state is about learning fundamentals, techniques and heuristics. Once one progresses, he/she reaches the "ha"-state, which means "detachment from the illusions of self". If one achieves mastery, he is in the "ri"-state, where "there are no techniques or proverbs, all moves are natural, becoming one with spirit alone without clinging to forms". I have <a href="http://scrumorakel.de/blog/index.php?/archives/31-Knowledge-as-impediment.html" target="_blank">previously</a> explained this concept slightly deeper.<br />
<br />
If we apply this concept to the Scrumguide, we quickly discover that it leads to some insights: Somebody reading the guide and being in the "Shu" state will need more guidance than somebody in the "ha" or "ri" state. So if you are just starting with Scrum, you will be very happy to find the three questions for the Daily Scrum, the distinction of Sprint Planning 1 and 2, maybe a guidance on how to do a Retrospective or even some standard items that can usually be found in a Definition of Done. Once you are in the "ha" state, you will want to get rid of the "rigid cage" that is being imposed on you by the "shu" rules. However, you will still need some unmovable boundaries to help you not to go astray (at least not too far). When you finally have reached the "ri" state, you don't need any framework at all. All you need are the values and basic principles of Scrum - everything else will come naturally to you and you will be able to taylor the framework to your needs without losing agility (which most often happens if somebody not in the "ri" state starts tayloring Scrum).<br />
<br />
For this reasons I hereby pledge for three different versions of the Scrumguide:<br />
<ol><br />
<li>The Shu Scrumguide should be more like a compendium, including very strict orders on what to do. It should also include best practices. It is important, however, to make transparent to the reader what are best practices and what really belongs to Scrum. Whoever reads the Shu Scrumguide should be able to set up a Scrum Team right away with clear guidance on how to do it.</li><br />
<li>The Ha Scrumguide should be quite similar to the current version. It should include a lot information on what to do, but no more details on how to do it. So this is basically a guide that includes the information about what is included and mandatory in Scrum. No best practices are shared here.</li><br />
<li>The Ri Scrumguide will be a short one-pager and only include the fundamental principles and values.</li><br />
</ol><br />
Along with their normal content, the three guides should give some hints on how the reader can self-assess his/her knowledge level in order to decide which guide is the right one for him/her. It has to be made sure that "shu" people stay with the "shu" guide, otherwise we will face a myriad of dysfunctional Scrum-But implementations. After all, apprentices always try to circumvent their masters, because learning something new is difficult and painful. However, if you don't go through this pain, you will never become a master yourself.<br />
<br />
What do you think about this idea? Rain comments on me!<br /><br /><br /><br />
<img src="http://vg01.met.vgwort.de/na/0f0445a484cd431b937d19d618119010" width="1" height="1" alt="">
Scrumorakel - Blognospam@example.com (Dominik Maximini)2013-02-28T08:53:57Zhttp://www.scrumorakel.de/blog/wfwcomment.php?cid=383http://www.scrumorakel.de/blog/rss.php?version=1.0&type=comments&cid=38Book review: Succeeding With Agile (Mike Cohn)
http://www.scrumorakel.de/blog/index.php?/archives/37-Book-review-Succeeding-With-Agile-Mike-Cohn.html
I just read <a href="http://www.amazon.de/gp/product/0321579364/ref=as_li_ss_tl?ie=UTF8&camp=1638&creative=19454&creativeASIN=0321579364&linkCode=as2&tag=scrumorakelde-21">Succeeding with Agile: Software Development Using Scrum (Addison-Wesley Signature)</a><img src="http://www.assoc-amazon.de/e/ir?t=scrumorakelde-21&l=as2&o=3&a=0321579364" width="1" height="1" border="0" alt="" style="border:none !important; margin:0px !important;" />, written by Mike Cohn. It was absolutely worth the money and I enjoyed the reading. However, it is - what a surprise - not a "silver bullet". Here is what I think: <br /><br /><br />
The book is quite lengthy. If you want to read it from start to end, you will have to go through 444 pages. The intended audience is described as "manager, developer, coach, ScrumMaster, product owner, analyst, team lead, or project lead". While this is not completely wrong, I perceived the different chapters as very different in regard to the target audience. No matter what role you would grab for yourself, not all parts of the book will be equally relevant for you. The first part of the book is called "Getting Started" and consists of the sections <em>Why Becoming Agile Is Hard (But Worth It)</em>, <em>ADAPTing to Scrum</em>, <em>Patterns for Adopting Scrum</em>, <em>Iterating Toward Agility</em>, and <em>Your First Projects</em>. Cohn goes into the field of organizational change here and tries to explain, how such an endeavor should be undertaken. However, I felt in reading it, that he focuses very much on the developers and clads a developer's position whenever possible. This is not bad, but might be hard to follow for a manager. In addition, Cohn creates his own model for organizational change while going with established ones (e.g. John Kotter) might have been sufficient and less confusing. This first part of the book will be especially helpful for Scrum Masters new to organizational change and people striving to become coaches. In addition, managers with a development background will benefit from it.<br /><br /><br />
The second part of the book focuses on Individuals. It includes the chapters <em>Overcoming Resistance</em>, <em>New Roles</em>, <em>Changed Roles</em>, and <em>Technical Practices</em>. I liked this part of the book very much, because the roles (both Scrum and traditional ones) are described in depth. Cohn also shows attributes of "good" Scrum Masters and Product Owners, which is helpful if you want to find appropriate people to fill those roles and haven't extensive experience, yet. Of special interest for the reader are the hints about tech leads or programmers as Scrum Masters. They are worth a read for managers as well. This reading group will also benefit from the section about the changed leadership role. The last chapter focuses on technical practices (as the name implies), which marks a shift of the audience focus away from manager / Scrum Masters into the direction of developers.<br /><br /><br />
Consequently, the third part of the book "Teams" deals with <em>Team Structure</em>, <em>Teamwork</em>, <em>Leading a Self-Organizing Team</em>, <em>The Product Backlog</em>, <em>Sprints</em>, <em>Planning</em>, and <em>Quality</em>. Those chapters are a treasure for Scrum Masters and developers. Here, the author describes in detail how Scrum works and provides some best practices as well. Basically, this part helps somebody setting up a new Scrum team to make less mistakes. Some paragraphs are interesting for Product Owners as well, but those might decide to let the Scrum Master educate them about it.<br /><br /><br />
In the last Part ("The Organization"), Cohn goes into <em>Scaling Scrum</em>, <em>Distributed Teams</em>, <em>Coexisting With Other Approaches</em>, and <em>Human Resources, Facilities and the PMO</em>. Personally, I didn't like this part. In my opinion, Cohn doesn't dive deep enough into those topics. However, they will be of great value for people starting with Scrum and Scrum Masters who haven't done that several times already. In any case, it is worth to take a look at those chapters.<br /><br /><br />
Finally, Cohn gives a brief look into the "Next Steps" where he tries to cover metrics and agility assessments. Well, don't expect too much from that - I wasn't impressed at all. It is not more than a brief glance at the wide field of metrics. Again, this will be helpful for Scrum Masters trying to get an overview or starting with that topic.<br /><br /><br />
In summary, again, I liked the book a lot and recommend you to read it. However, it is entry literature - not an advanced guide to organizational change. If that is okay with you, go for it!<br /><br /><br />
<img src="http://vg01.met.vgwort.de/na/c34b4d3f7f374707a58286252d49ce8f" width="1" height="1" alt="">
Scrumorakel - Blognospam@example.com (Dominik Maximini)2013-02-17T13:47:41Zhttp://www.scrumorakel.de/blog/wfwcomment.php?cid=373http://www.scrumorakel.de/blog/rss.php?version=1.0&type=comments&cid=37Experience in writing a Scrum book
http://www.scrumorakel.de/blog/index.php?/archives/36-Experience-in-writing-a-Scrum-book.html
Just recently, my first book <a href="http://www.amazon.de/gp/product/364234822X/ref=as_li_ss_tl?ie=UTF8&camp=1638&creative=19454&creativeASIN=364234822X&linkCode=as2&tag=scrumorakelde-21">Scrum - Einführung in der Unternehmenspraxis: Von starren Strukturen zu agilen Kulturen</a><img src="http://www.assoc-amazon.de/e/ir?t=scrumorakelde-21&l=as2&o=3&a=364234822X" width="1" height="1" border="0" alt="" style="border:none !important; margin:0px !important;" /> was published (it's only available in German so far). I decided to share some of the experience I gathered in the course of that endeavor. Please be aware, that those are just my personal insights; you might face different issues and different learnings when going for your next publication. You should also note that I am only talking about Germany - other countries might be different.<br /><br /><br /><br />
Before we dive into details, let's say that publishing a book is not exactly easy. I mean, it's up to you if you can <em>write</em> a book, but it's completely up to others, if you will manage to <em>publish</em> one. Of course, you could use a print-on-demand supplier or just put it on infoq, but this is not what I am talking about. I am talking about renowned publishers like Springer, Wiley, Jossey Bass - you name them. In my case, it took more time to get published than to write the book. Here is why:<br /><br /><br />
Before I started, I decided that I wanted to publish my book with a well-known publisher. In my opinion, it means less money but greater respect. I made my first mistake shortly after, just before I really started the project (oh yes: writing a book is a project, and a large one at that): I decided to write the book before contacting publishers. What I know now is, that some (not all!) publishers prefer to get a well-designed abstract and discuss it with the author. That way, they have greater influence. Well, I assumed that editors (those are the people who read your work, sometimes help you adjust it, and decide if it's published) didn't have deep knowledge about Scrum. Especially not about changing organizations with/towards Scrum. So how should an editor be able to judge my abstract? On top of that, I had never written a book before. I didn't know if I was able to and how long it would take. In addition, I am not a "guru" person like Ken or Jeff. So people wouldn't buy my stuff because of the author's name. Which again is difficult, if you want to partner with a publisher. After all, they want to earn money with what you write - a good name certainly helps. Why should they waste time with a less-known person?<br /><br />
So I wrote the book. This took quite some time (I estimate the effort to approx. 500 hours). Once I was 95% done, I decided to contact a publisher. What you usually do is to send them an exposé. That is a summary of your book with important information for the publisher. Many publishers have their own format and templates for that - you are well advised to use them. I discovered that I had to do a great deal of market research and self-marketing in order to fill in those forms. The reason for me to write the book was to get a short and easy to understand "bible" of how to transform an organization to Scrum. I didn't know of such a publication, so I wrote it myself. However, I had not conducted a full market research. Of course I read a lot - but I don't know every book out there! This gap had to be closed, so I lost several weeks reading books of other people (and I still didn't read <strong>all</strong> relevant books). Once I had a good enough market evaluation, I sent my exposé to the first publisher and - waited. Waited some more. And even more. After six weeks, I got a reaction: "This looks interesting, send us the manuscript." Darn - six weeks are an awful lot of time for an agile practitioner like me. But what could I do? So I waited. After another six weeks, they told me that they needed just a little more time. Four weeks later (hooray, the Sprint length was reduced!) they told me, that this topic would not fit their program. At this point in time, I had already waited three months to get a simple "no" - this was frustrating. So I went to the second publisher on my list, who immediately (after three weeks) declined the offer. Number three was more like a dejavu: Three months total waiting time to get a response. Somewhere during the waiting for that publisher, I was furious and changed my approach: I contacted four publishers at the same time. Two of them personally (one at a conference, one with an appointment after they had signaled basic interest). While this finally led to success (two publishers were honestly interested), it led to some conflict as well: A third publisher signaled interest and even arranged for a place in their books lineup, which I had to decline because I already had agreed on the offer of another publisher. I learned the hard way that it is not common in the publishers' branch to contact several publishers at once. I certainly feel sympathetic with the disappointed editor - but what could I do?<br /><br />
One of the other two highly interested publishers took quite some time and asked a number of Scrum people to review my manuscript. After three months without much communication from the publisher's side, I told them that I would not proceed with them. 11 hours later (this is like the speed of light for this branch) I received a friendly email, phrasing joy that I found a publisher (but not trying to change my mind) and sharing the comments from the Scrum reviewers with me. I then understood, why they had been so silent: The reviews were mediocre. Praising style and some ideas, smashing other details. Before contacting any publisher, I of course had asked several professionals to review my work - and it had improved the quality quite a bit. However, those "other" reviewers had verbally ripped some parts of the manuscript to shreds. On a second glance I noticed that they had not read it completely (none of them!). One demonstrated clearly a lack of Scrum knowledge in his/her answer - but dared to provide a bad review anyway. On top of that, some important information - like the target audience - had not been distributed to them. The main content-related feedback point was about missing pictures (I had none in there - it was the 95% version) and missing depth for the target audience (which was not known to them). From those reviews I got the impression of a development team delivering too fast at the end of a release - incomplete, unsatisfying quality and low motivation. Of course some useful thoughts were in those reviews and I adapted the script accordingly. The names of the reviewers are not known to me, so I could not get back to them and discuss their thoughts in detail. This made me fully understand Dean Leffingwell's remark: "Writing a book is the least agile thing you can possibly imagine!" - Bad communication, huge feedback cycles, a gigantic batch size (there is just one batch with everything in there), hardly any chance for inspection and adaptation, no transparency. If by any chance you were one of the reviewers of my manuscript, please get in touch with me. I would be happy to discuss your thoughts and learn for my next book project!<br /><br />
Another notable experience concerns the quality you have to deliver as an author. When I started I had the idea that I would write some 80% version and then would work together with my editor to make it perfect. I was mistaken. You have to provide the 100%, including the elimination of all typos. Even the pictures have to be provided by you (but they will be recreated by the publisher). Only one editor actually made recommendations to me how to improve the book. Those were good, but too late: I already had spotted and corrected those taints myself.<br /><br /><br />
When the contract was finally signed, I had to fill in a couple of forms again (I love administrivia). The publisher took care of the rest and I only had to double-check the final version going into print. The whole process speeded up a lot and I got my first copies a day before Christmas, two months earlier than anticipated. That's where we are now today: 11 months after I finished the 95%-version of my book, three weeks after I received the first copies of my book, one week after Amazon started delivering orders.<br /><br /><br />
As always, I am happy to discuss your thoughts with you. Just post a comment here or drop me an email. Let me know once you have read the book - I yearn for your feedback! <img src="http://www.scrumorakel.de/blog/templates/default/img/emoticons/wink.png" alt=";-)" style="display: inline; vertical-align: bottom;" class="emoticon" /><br /><br /><br /><br />
<img src="http://vg01.met.vgwort.de/na/120f094a79fb433582df0430b0207c3f" width="1" height="1" alt=""><br />
Scrumorakel - Blognospam@example.com (Dominik Maximini)2013-01-08T14:54:45Zhttp://www.scrumorakel.de/blog/wfwcomment.php?cid=360http://www.scrumorakel.de/blog/rss.php?version=1.0&type=comments&cid=36Using burndowns for management meetings
http://www.scrumorakel.de/blog/index.php?/archives/35-Using-burndowns-for-management-meetings.html
Scrum tools are useful in many situations, not only for their original purpose. For example, you can use the burndown-tool to track meetings and make them more efficient. In addition, the participants of the meeting get a feeling for Scrum and it's focus as well as its transparency.<br />
This is, how it works: You of course have to plan the goal and the agenda of the meeting, including rough time estimates for each agenda point. then take two flip-charts and draw a "task board" and a standard burndown. Write one sticky note for each agenda point (write legibly!) and put them in the first column of your task board. Choose a "iteration length" of five minutes (you can extend or shorten it after you tried it once). This is the timebox after which you draw the burndown and check if one of the agenda-points has to be moved from one column to the next.<br />
When the meeting starts, take three minutes to briefly explain what those sheets of paper mean and how they relate to Scrum. If questions arise, answer them quickly, but don't go into depth - you can still do that after the meeting once you have reached it's goal. Draw the burndown line (and move the "tasks") without any comment during the meeting, but make sure everybody sees the board(s). You will notice that people get nervous and keep themselves shorter if the actual progress deviates from the "ideal line". When the meeting is over, take five minutes for a quick retrospective about this experience for management.<br />
<br />
It helps, if you don't have to moderate and track the progress at the same time. Furthermore, you can color-code the sticky notes according to your needs. In any case, make sure you have inserted the "ideal line" - otherwise the focus is lost for your management colleagues.<br />
<br />
When I did this (at a big automotive company), the meeting participants were enlightened. They experienced instant focus on the topic, full transparency within five minute slices, and they met the goal because they could adapt to changes (note the sudden drop after minute 35 - this agenda point was shortened due to the delay). On top of that, they felt the pressure they put on themselves. This helped very much in persuading them afterwards, that they do not have to exert control over the Scrum teams, because those are pressured already and the transparency is real (in opposition of the melon status they usually get - green on the outside, but squishy red on the inside).<br />
<br />
Here is an example from one meeting where I did this:<br />
<br />
<!-- s9ymdb:17 --><img class="serendipity_image_left" width="478" height="640" src="http://www.scrumorakel.de/blog/uploads/Burndown.jpg" title="management burndown" alt="" /><br />
<br /><br /><br /><img src="http://vg03.met.vgwort.de/na/3f2cca05b9f94138942308e13b969bde" width="1" height="1" alt="">
Scrumorakel - Blognospam@example.com (Dominik Maximini)2012-12-18T07:14:39Zhttp://www.scrumorakel.de/blog/wfwcomment.php?cid=350http://www.scrumorakel.de/blog/rss.php?version=1.0&type=comments&cid=35Can you change Scrum?
http://www.scrumorakel.de/blog/index.php?/archives/34-Can-you-change-Scrum.html
Quite often people come up to me in training or coaching and ask me if it is possible to "tweak" or "alter" Scrum. Well, the answer to this is quick: Sure you can. Just go to <a href="https://www.scrum.org/Scrum-Guides/Change-the-Scrum-Guide" title="https://www.scrum.org/Scrum-Guides/Change-the-Scrum-Guide">https://www.scrum.org/Scrum-Guides/Change-the-Scrum-Guide</a> and continue from there. Changing Scrum is like changing any other rule book: You can do this, but you need the approval of the authors. Imagine you want to change the rules of chess: If you want to change the walking-path of the king to match that of the dame, you will need to persuade quite a community. It's easier with Scrum though, because Scrum lives continuous inspection and adaptation and there is a process for it (see the link above).<br />
<br />
What people really mean is, if they can leave out certain Scrum elements in their specific Scrum implementation. Well, it's their company, so of course they can - but then they are no longer doing Scrum and have to rename their process to something else. Besides, they will most likely miss the benefit of the element they are ditching.<br />
<br />
But do you have to follow Scrum forever, even after you have truly mastered Agility in your enterprise? Of course not.<br />
<br />
Scrum is a tool, like a hammer. Once it served it's purpose (the nail was driven into the wall), you can put it away (stop using Scrum).<br />
I mean, our goal is after all to improve the profession of software development (or of all knowledge workers in my case), increase the job satisfaction of the people and increase the return on invest for our companies. In my opinion, this means to transform organizations to become agile from the heart. Once they are there (and sustainable!), they are like grown children and can make their own decisions. So, sure: If they really know what they are doing, they can abandon Scrum.<br />
<br />
BUT: None of my customers has reached that sustainable state so far. They usually are in a advanced learning stage (or even early beginners) when they decide to abandon some practice and tend to fail once they do so. Therefore, whatever they want to change, I never allow them to drop retrospectives and analyze with them what happened after they altered something. So far, they always went back to Plannings, Daily Scrums and so on.<br />
<br />
Usually, if somebody wants to deviate from Scrum, that person is trying to cover some dysfunction instead of solving it's root cause. Let's take an example: A short while ago a development Team came up to me and told me that they had decided to stop doing Retrospectives. I asked them to come together the same day and worked with them on the root causes for their decision (so yes, I did a Retrospective with them even though they had decided to stop doing those - I apologize, guys!). The result was a deep frustration with their organization because everything that had to be changed outside the Team took ages and always got watered down to tastelessness. The Developers felt that the organization was not appreciating agility, or even their employees. "We are just numbers," one colleague said. And he was right.<br />
In the end we continued to do retrospectives and tried to work harder on the corporate culture. This process is still going on and will most likely take another 7-10 years.<br />
<br />
Whatever problem set we are talking about, you have to use the right process for it. Scrum is an empirical framework made for complex problems. If you try to apply it on simple problems, there is a mismatch. The same is true when you try to deploy predictive processes on complex problems. It just doesn't work the way it should. The same is true for corporate and personal values: Some value sets (or "cultures") will produce better suited solutions for specific problem sets than others. You can find out if there is a mismatch by looking at the success rate of your projects. If you encounter a bad yield rate (<90%), try to reflect on your problems, solutions and culture. Maybe you are using the wrong process. Maybe you are looking at your problem from the wrong angle. Maybe you should get up, spit into your hands, and solve your root causes without trying to apply the tools that led to the high failure rates in the first place.<br /><br /><br /><img src="http://vg03.met.vgwort.de/na/a191f12a85ed44edb6f6c2bf5bbbc156" width="1" height="1" alt="">
Scrumorakel - Blognospam@example.com (Dominik Maximini)2012-09-15T10:18:35Zhttp://www.scrumorakel.de/blog/wfwcomment.php?cid=340http://www.scrumorakel.de/blog/rss.php?version=1.0&type=comments&cid=34Agile Tour goes Germany
http://www.scrumorakel.de/blog/index.php?/archives/33-Agile-Tour-goes-Germany.html
Finally, the <a href="http://agiletour.de/">Agile Tour</a> comes to Germany. It's a community event, aiming at creating interest in agility and lowering the barrier to participate. The participation fee will be as low as 50 Euro (incl. VAT). The venue for up to 75 guests takes place at a very pretty building in Stuttgart (I'm sure you'll like it!) on the 22nd of November this year. We will offer a variety of talks, starting at the beginner level ("e.g. What is Scrum?") and ranging up to the experts ("e.g. Enterprise agility"). However, the final agenda will be fixed at the end of September - this means you can still give us some input, if you like.<br />
Any questions? Shoot me (or the other organizers) an email.<br />
<br />
All information can be found at <a href="http://agiletour.de/" title="http://agiletour.de/">http://agiletour.de/</a><br /><br />
Scrumorakel - Blognospam@example.com (Dominik Maximini)2012-08-31T17:06:06Zhttp://www.scrumorakel.de/blog/wfwcomment.php?cid=330http://www.scrumorakel.de/blog/rss.php?version=1.0&type=comments&cid=33The reasons why distributed teams are less effective
http://www.scrumorakel.de/blog/index.php?/archives/32-The-reasons-why-distributed-teams-are-less-effective.html
There is an agile myth out there: Collocated teams are at least 40% more productive than dispersed (same team on different locations) or distributed (different teams on several locations) ones. I recently did some study on that topic and found a model that very neatly explains the reasons behind the drop in performance. Maybe this knowledge will aid you in your daily work.<br />
The model I am talking about is the "virtual distance model", invented by Karen Sobel Lojeski and Richard R. Reilly. The model is fully described in their 2008' book <a href="http://www.amazon.de/gp/product/0470193956/ref=as_li_ss_tl?ie=UTF8&camp=1638&creative=19454&creativeASIN=0470193956&linkCode=as2&tag=scrumorakelde-21">Uniting the Virtual Workforce: Transforming Leadership and Innovation in the Globally Integrated Enterprise</a><img src="http://www.assoc-amazon.de/e/ir?t=scrumorakelde-21&l=as2&o=3&a=0470193956" width="1" height="1" border="0" alt="" style="border:none !important; margin:0px !important;" />.<br /><br />
<!-- s9ymdb:16 --><img class="serendipity_image_center" width="775" height="520" src="http://www.scrumorakel.de/blog/uploads/VirtualDistance.png" alt="" /><br /><br />
The authors state that virtual distance applies for every human interaction with another human being. It consists of three dimension: Affinity distance, physical distance and operational distance. While many other authors focus on "geographic distance", Karen only sees it as a fraction of physical distance. It is supplemented by temporal distance and organizational distance. Let's look at it more closely and see, if you have met those before.<br />
Geographic distance means that people are physically apart - 15 meters or more. So as soon as there are stairs involved, a wall or too many steps to walk, you are faced with geographic distance (Thomas J. Allen did a study in 1977 and published it in his book <a href="http://www.amazon.de/gp/product/0262510278/ref=as_li_ss_tl?ie=UTF8&camp=1638&creative=19454&creativeASIN=0262510278&linkCode=as2&tag=scrumorakelde-21">Managing the Flow of Technology</a><img src="http://www.assoc-amazon.de/e/ir?t=scrumorakelde-21&l=as2&o=3&a=0262510278" width="1" height="1" border="0" alt="" style="border:none !important; margin:0px !important;" /> - you can read more about the exact distance and classification there.)<br /><br />
Temporal distance means that people are working asynchronously. This can either happen if people are working in different time-zones (that's obvious, of course). But this can also happen if people start and end working at different times. For example, if somebody starts work at seven and finishes at three while somebody else comes in at 11 and stays until eight in the evening, you are faced with temporal distance.<br />
Organizational distance basically means that there usually is a distance between different departments and organizations. You can spot this when people start talking about "us" and "them". Did you ever condemn "those stupid marketing people"? Well, there you go...<br />
You can see, that physical distance is far more complex than just "being in different countries". This is similar with "operational distance", which basically means that the tools and frame conditions can pose a problem, contributing to virtual distance. Communications distance is pretty obvious: You can send less information via email than you can in a face-to-face interview. Unfortunately, most people don't mind this knowledge and communicate most of the day via email. I could name many instances on the spot, where just the communication channel contributed to a major conflict in an organization... All media can be considered according to it's "media richness". The media mix must fit the needs of your team and environment. If it doesn't, you increase your operational distance.<br />
In our Professional Scrum Master courses we teach our students that multi-tasking is a bad thing. Of course I know this from my own experience and lean teaches it as well. But here comes the interesting bit: Multitasking contributes to operational distance due to a lack in focus. Or easier put: People don't feel as close to one another if they are working on different things and they are walking on edge due to the stress involved in task switching.<br />
Even if you heed those lessons, "readiness distance" can break your neck. It describes the "readiness" of your IT infrastructure. Imagine that you have a beautiful communication strategy which involves video conferencing. Then you have your first meeting, switch on the equipment - and nothing happens. People grow inpatient while you try to fix it, call in your IT expert only to be told that "there is a license missing". If you are lucky, people won't give up on you just yet...<br />
Distribution Asymmetry is the last part of the puzzle to complete operational distance. It means an unbalanced distribution of your workforce. For example, if two of your people are working in the satellite and five are in the group headquarters, you instantly get "them" and "us" again. By the way: This happens the other way around as well.<br /><br />
The most important distance is the "affinity" distance. You can have it even if your people are sitting right next to each other. It comprises of cultural distance, social distance, relationship distance and interdependence distance. You probably know cultural distance - it happens if people have different cultural backgrounds. This can be true within a country as well: In Germany for example there is a slightly different culture in "East" and "West" as well as between the different states. A Bavarian has a certain cultural distance when interacting with a "northern light" coming from Hamburg (any other state could have been chosen here as well). Social distance means the status within society, that might oppose that of a team mate. Imagine an "Earl of Winchester", honored with an phd and teaching at university, working together on a project, formally equal, with John Doe, who just has finished high school. Can you imagine any conflicts arising from that constellation? While this constructed example is quite obvious, there are many social nuances that have to be considered and addressed in a team if you want to keep the social distance low.<br />
Relationship distance is described as "the extent to which you and others lack relationship connections from past work initiatives". Flatly: People don't know if they can trust each other, because they don't know their new colleagues. It manifests as a "sense of unfamiliarity".<br />
Interdependence distance happens mostly when there is no shared vision. People don't walk into the same direction and therefore don't commit to each other. Maybe you have spotted sentences like "well, my part is working, it's <put a name in> who has to fix his code, not me".<br /><br /><br />
As you can see, there are many dimension you have to consider when forming a virtual team. All of the aforementioned distances will occur, it's up to you to make them transparent and to address them. They are not bad in themselves - they are natural. They are one of many reasons why you desperately need Management - you will fail if you try to solve this immense problem by yourself. It's easier of course, if you stay with collocated teams. It reduces your project complexity. Unfortunately, 65% of the teams in our industry are not collocated but distributed or dispersed. Those teams will be (on average) less productive than the collocated ones. But they can be of strategical importance and there usually are reasons why the companies go for them. Don't condemn them too quickly. And then get back to your work, make the different dimensions of distance transparent, measure them and reduce them.<br /><br /><br />
Good Luck!<br /><br /><img src="http://vg03.met.vgwort.de/na/ab5c07a40b4e4e0b912ae10abb085193" width="1" height="1" alt="">
Scrumorakel - Blognospam@example.com (Dominik Maximini)2012-08-12T14:01:38Zhttp://www.scrumorakel.de/blog/wfwcomment.php?cid=322http://www.scrumorakel.de/blog/rss.php?version=1.0&type=comments&cid=32Knowledge as impediment
http://www.scrumorakel.de/blog/index.php?/archives/31-Knowledge-as-impediment.html
Experience is <a href="http://www.thefreedictionary.com/experience" title="http://www.thefreedictionary.com/experience">defined</a> as <blockquote>knowledge, skill or wisdom gained through practice in some activity, or the doing of something</blockquote>Well, at least that is one definition. In contrast to knowledge, which is <a href="http://www.thefreedictionary.com/Knowledge" title="http://www.thefreedictionary.com/Knowledge">defined</a> as <blockquote>the state or fact of knowing</blockquote>So somebody with experience has actually applied his wisdom. Recently I have come across several people where the gap between knowledge and experience created impediments.<br /><br /><br />
I am sure you are aware of <a href="http://en.wikipedia.org/wiki/Shuhari" title="http://en.wikipedia.org/wiki/Shuhari">Shuhari</a>. It is a Japanese martial arts concept that describes different stages of learning. Shuhari roughly translates to "first learn, then detach, and finally transcend." The "shu"-state is about learning fundamentals, techniques and heuristics. Once one progresses, he/she reaches the "ha"-state, which means "detachment from the illusions of self". If one achieves mastery, he is in the "ri"-state, where "there are no techniques or proverbs, all moves are natural, becoming one with spirit alone without clinging to forms".<br /><br /><br />
Well, this is pretty abstract. You could maybe summarize it as "First you obey the rules, then you deviate a bit and finally you no longer think about them, it all feels natural." Personally, I prefer the <a href="http://en.wikipedia.org/wiki/Dreyfus_model" title="http://en.wikipedia.org/wiki/Dreyfus_model">Dreyfus-model</a>.<br /><br /><a class="serendipity_image_link" href='http://vitorpamplona.com/wiki/Modelo%20de%20Dreyfus%20para%20aprendizado' target="_blank"><!-- s9ymdb:15 --><img class="serendipity_image_center" width="663" height="483" src="http://www.scrumorakel.de/blog/uploads/dreyfus_model.jpg" alt="" /></a><div align="center"><em>Dreyfus Model - Credits: vitorpamplona.com</em></div><br /><br />As you can see in this picture, the Dreyfus model knows five stages of skill acquisition: Novice, Advanced Beginner, Competent, Proficient and Expert. While the Beginner is just able to "follow the rules", the Expert "just does what works". In between, rules first have nuances and become conditional. Once competent, the person learns the rules behind the rules shaping context and conditions. Finally, intuition comes into play.<br />As far as the skills stretch, the sense of responsibility grows as well. But what does this have to do with Scrum? Well, a lot actually.<br /><br /><br />
You know of course, that your team members will go through all of those stages and that the rest of the team should help each individual to proceed as quickly as sensible. But have you ever thought about yourself? In what stage are you? Don't be too hasty in your decision. Many people have a differing self-perception from other people's views. Especially Scrum Masters, who are usually quite self-confident and need a thick fur to enforce the rules of Scrum tend to consider themselves "Experts" once they start to see the principles behind Scrum. In truth, they are just Advanced Beginners, but they proclaim proudly to have mastered the art of Scrum. It is quite interesting to discuss nuances and the practical application with them (I admit that I like heated discussions). Unfortunately, quite often you quickly reach the point where the Advanced Beginners resort to the "because Scrum says so" argument. That's the minute where the discussions grow stiff and awkward, depending on the individual character.<br /><br /><br />
Nobody can be an expert in all fields. On top of that, Scrum is just a framework with many holes. You need vast additional expertise to fill those professionally. Just think about things like:<ul><li>Coding practices</li><li>Requirement elicitation</li><li>Leadership</li><li>Software deployment</li><li>Organizational development</li><li>Process engineering</li><li>Moderation techniques</li><li>Analysis methods</li><li>And many more...</li></ul><br />
Now, if an Advanced Beginner starts discussing Scrum with experienced managers (who tend to be Competent or Proficient in their area of expertise), those quickly spot the lack of context and depth. Credibility and trust are lost. Sometimes Scrum is blamed for the incompetence afterwards (which usually just helps in political plays or fears for change, but nevertheless is harmful for the company's transition). This is a severe impediment. Without trust, Scrum cannot work.<br /><br /><br />
I strongly recommend to create transparency for yourselves and the people you work with. Clearly state where your skills lie - and where you consider yourself a Novice. Don't rely on your own perception but ask others about their opinions. In each area of expertise, there are only few experts out there. Don't consider yourself one too light-headedly. Help others with less experience to develop themselves - for example by coaching them. Strive to improve yourself at every opportunity as well. Whenever you catch yourself not being able to explain something or resorting to "because ... says so"-answers, investigate further and look at the Dreyfus model again. Accept that there is always a "bigger fish" out there (which means a "better expert" of course). That's actually good, because otherwise you couldn't learn anything new anymore - what a boring life. If you believe yourself being a Scrum Expert, start filling in the holes. Trying to become an expert in all the fields will keep you busy a lifetime. <img src="http://www.scrumorakel.de/blog/templates/default/img/emoticons/smile.png" alt=":-)" style="display: inline; vertical-align: bottom;" class="emoticon" /><br /><br />One last piece of advice: You can never become a Scrum Expert just by reading books. You have to apply your knowledge to real projects on a daily basis. Get your hands dirty!<br /><br /><br /><img src="http://vg03.met.vgwort.de/na/7ee91ef99cd645e68258ff42c843bac8" width="1" height="1" alt="">
Scrumorakel - Blognospam@example.com (Dominik Maximini)2012-07-12T17:32:03Zhttp://www.scrumorakel.de/blog/wfwcomment.php?cid=310http://www.scrumorakel.de/blog/rss.php?version=1.0&type=comments&cid=31How to prepare for the Professional Scrum assessments
http://www.scrumorakel.de/blog/index.php?/archives/30-How-to-prepare-for-the-Professional-Scrum-assessments.html
<br />Since there are quite many people asking me about the scrum.org assessments, it's time to shed some light on how to prepare for them. What you find here is my personal experience from completing PSM I, PSM II, PSPO I and PSPO II all with more than 95%.<br /><br />
<br />
Before we talk about preparation, you should understand what those exams are all about. Certificates don't have much meaning when it comes to being a good Scrum Master (see <a href="http://scrumorakel.de/blog/index.php?/archives/26-What-good-are-certificates.html" target="_blank">this post</a> and <a href="http://scrumorakel.de/blog/index.php?/archives/27-How-to-become-a-good-Scrum-Master.html" target="_blank">that post</a> for more on the topic). However, some companies think there is some value to that paper. Some people feel proud for passing difficult exams.<br /><br />
<br />
The Professional Scrum Master (PSM) line of assessments tries to figure out if you understood the basic concepts (PSM I) of Scrum as described in the Scrum Guide and if you have some intermediate knowledge in being a Scrum Master (PSM II). The same is true for the Professional Scrum Product Owner (PSPO) line of assessments, but those focus on the Product Owner of course. More about pricing and how to obtain a key to give those assessments a shot can be found on the scrum.org website.<br /><br />
<br />
To prepare for the entry-level exams (PSM I and PSPO I), you should know the Scrumguide very well. You will be asked around 80 questions in 60 minutes, which is plenty of time. The questions are taken from a pool and vary, so don't believe all questions will be the same if you try it several times. This is pretty unnecessary as well: around 80% of my course participants pass this assessments on the first attempt. Due to language and understanding (of Scrum) issues, 20% fail on the first try. Those usually make it on the second one after studying some more.<br />
So here is how you should prepare:<ul><li>Read the <a href="http://www.scrum.org/scrumguides" Target="_blank">Scrumguide</a></li><li>Understand the Scrumguide</li><li>Gather some experience in a real Scrum Team</li><li>Know something about Scrum Best Practices, which are not part of the Scrumguide. This covers burndowns, planning poker, test driven development and more. This is not strictly necessary to pass the test, it's good to know nevertheless.</li><li>Visit a Scrum course, if you like. That's no prerequisite for the assessment but some people find it helpful.</li><li>Try the Scrum Open assessment as often as you like on the Scrum.org website. If you don't achieve skyrocketing scores here, don't go for the real assessment.</li></ul><br />
<br />
To prepare for the intermediate-level exams (PSM II and PSPO II), you should know everything you did for the entry-level exams (They have to be passed before you try the difficult ones. The reason is mainly to make sure you have a basic understanding and don't get completely lost.). Most people fail the 2nd level assessments, so prepare well! You will need to have truely understood Scrum. Reading the Scrumguide alone will not help you here. You will get some multiple-choice questions again (different ones than in the first assessment), but the main part consists of essay questions. If you really nail it down, one or two sentences suffice to answer. Most people go to some length though. Time is tough on the intermediate assessments. Don't count on having time to look anything up (except some English words if your aren't a native speaker).<br />
Here is what you should do to prepare:<ul><li>Do everything you did for the first level assessment</li><li>Read every Scrum and leadership book you can lay your hands on. This won't help you directly but can broaden your horizon.</li><li>Make yourself aware of what the job of a Scrum Master / Product Owner is. A PSM / PSPO course can definitely help you there.</li><li>Acquire experience. I am not talking about visiting a Scrum Team for a week, I am talking about walking through the mud with them. Simply be a Scrum Master for a while. Especially difficult situations can help you acquire expertise. I usually recommend people to gather at least three years of experience before doing the 2nd level assessments. It's up to you of course, if you want to do it. <img src="http://www.scrumorakel.de/blog/templates/default/img/emoticons/wink.png" alt=";-)" style="display: inline; vertical-align: bottom;" class="emoticon" /></li></ul><br />
<br />
By the way: Trying to google the answers won't take you very far. A hand full can be found on the net, but the majority is not publicly available. They are changed from time to time as well. You will have to use the primary Scrum tool instead: The grey mass between your ears.<br /><br />
<br />
One last piece of advice: If you aren't sure about a question take a note during the test (during does not mean afterwards). Go to a local Scrum user group then and ask the folks there to discuss that question with you. This most often gives you some insight if you are on the right road or not.<br /><br />
<br />
Is some information missing? Let me know by commenting this blog post.<br /><br />
<br />
Good luck!<br />
<br />
<br /><br /><img src="http://vg03.met.vgwort.de/na/84ad4ee5dfc543ef9a7848f34b5b203e" width="1" height="1" alt="">
Scrumorakel - Blognospam@example.com (Dominik Maximini)2012-05-15T16:34:50Zhttp://www.scrumorakel.de/blog/wfwcomment.php?cid=302http://www.scrumorakel.de/blog/rss.php?version=1.0&type=comments&cid=30External developers in Scrum Teams
http://www.scrumorakel.de/blog/index.php?/archives/29-External-developers-in-Scrum-Teams.html
Today it is quite common to have external "resources" within your teams. I have hardly come across any company which doesn't have at least some specialists on their teams who are not on their regular payroll. While external developers are not a problem in themselves, the way how those are implemented can cause problems. This blog focuses on external collocated developers on the customer's site (so dispersed and distributed teams are excluded).<br />
<br />
Here are two examples:<br />
<ol><li>The customer bought resources from all over Germany and asked them to work on one single site from Monday to Friday. They were not introduced to the existing teams but rather appeared suddenly. Their skill profile was not compared to the needs of the teams. Nor were the teams asked, if they needed additional manpower. Since the existing team members were surprised by the appearance of new colleagues, they were reluctant to introduce the new guys to their processes and tools. Planning was inaccurate as well - they never knew, what they had to deal with. For a new member to be fully productive, it took about nine months. Most external people stayed between one and one-and-half year with the company. This meant quite high costs. Those were not transparent though: For controlling, the people worked eight hours a day. Nobody cared to measure the benefit for the company. Thought was lacking anyway: On one instance, the company brought in 50 new people within a month and didn't even care if the project could absorb those.</li><br />
<br />
<li>Another customer found that they lacked certain expertise in one specific area of their business. So they went looking for the right specialists on that topic. They found them half way across the country, concentrated in a single company. Both firms decided to partner and started to work together. Two teams were formed, each consisting of employees of both companies. During the first months, they all worked on the same site (later, they worked distributed). They all tried hard to get to know each other. Sponsored events (usually involving lots of beer and pizza) added their share. The teams were allowed to self-organize all aspects of their work: Team constellation, core working hours, location of work (including traveling to both sites, if necessary) and so on. When a need for additional expertise surfaced, the teams brought that up themselves. New members were productive after three months. The average member stayed three to five years. Velocity soared up and stayed high.</li></ol><br />
So what was different between those two companies? Apart from the methodologies (who organizes whom, how is productivity measured and so on), there was only one major difference: The first company looked for resources, the second looked for people. They were treated accordingly. <br />
People tend to like being treated as such. There is nothing like "human resources", even though many departments carry that name (It's not "legal resources" or "manufacturing resources" either. So why don't you try something different? "Human affairs" maybe. Or "People Development". Think about it.). Especially in a knowledge worker environment, you cannot easily replace any given person. People have complex relations. While you can tick of their JAVA-skills, you cannot evaluate in advance, how the team will work together. Treat your team with respect and trust so they can prove you right. You will like the results.<br />
<br /><br /><br />
<img src="http://vg01.met.vgwort.de/na/5ccded3722404d46970ba3a2cf387864" width="1" height="1" alt="">
Scrumorakel - Blognospam@example.com (Dominik Maximini)2012-04-09T08:27:25Zhttp://www.scrumorakel.de/blog/wfwcomment.php?cid=290http://www.scrumorakel.de/blog/rss.php?version=1.0&type=comments&cid=29Pride and the will to win
http://www.scrumorakel.de/blog/index.php?/archives/28-Pride-and-the-will-to-win.html
In well working Scrum Teams one will experience extremely high motivation, very high collaboration and above-average productivity. Where does that come from? If you have worked with such Scrum Teams in the past, you might have asked yourself the very same question. At least I did - and came up with an interesting answer:<br />
People are productive, when they are motivated. People are motivated when they are proud. Pride only develops if people are treated like human beings, not like resources. They must be allowed to manage themselves, but also shown respect for their work. They must be allowed to deliver high quality work. (You might argue now, that "every Team is allowed to deliver, that's what they are paid for!". Let me assure you, that this is not the case. I have worked with Teams who were so bound by technical barriers and mandatory processes, that they could hardly move an inch. Of course, they weren't able to use full Scrum either and therefore didn't get the benefits out of it. We first had to remove the impediments, which took quite a while). <br /><br />
Have a look around you, especially at open source projects: Why do those people put so much effort into something they aren't even paid for? Every single one of them has his/her own specific reason, but they have one thing in common: They want to <b>make a difference</b> and put their ideas to practice. That is something they often are not able to do during their working time. This potential should not be wasted! As a Scrum Master it is your job to find out what motivates each individual Developer in your Team and find a way that those needs are satisfied. Usually that shouldn't be too hard, because people tend to come in a "motivated" state by default. Just remove everything that impedes this intrinsic motivation.<br /><br />
If you succeed here, meaning the Team takes pride in what they do and are highly motivated as well as productive, you get something very important for free: <b>The will to win</b>. If your Team has a strong will to win, they will overcome difficult times by themselves and they will tackle every problem that arises. If this will to win is missing, you find the Team accepting almost everything without argument. If you have ever heard a Developer say that "this takes awfully long, but that's how it is done around here" you know what I am talking about.<br /><br />
The above described concept is valid and essential for the management of a company as well. Only if they have the will to win, they will be able to solve systemic problems of the organisation. Without it, you (as Scrum Master / Scrum Coach) will have to do everything yourself, go on their nerves, push them further and finally leave the company out of frustration (or because they are fed up with your attitude) - which is the point in time when everything falls back into place as it was before you even started. Does your management keep their promises?<br /><br />
Let your people create high quality work which makes them proud and you will get an unstoppable winning Team.<br /><br /><br /><img src="http://vg01.met.vgwort.de/na/ec3f71437070425da40ab0b209d4c730" width="1" height="1" alt="">
Scrumorakel - Blognospam@example.com (Dominik Maximini)2012-01-24T21:00:21Zhttp://www.scrumorakel.de/blog/wfwcomment.php?cid=280http://www.scrumorakel.de/blog/rss.php?version=1.0&type=comments&cid=28How to become a good Scrum Master
http://www.scrumorakel.de/blog/index.php?/archives/27-How-to-become-a-good-Scrum-Master.html
This is a translation of my second-most visited German <a href="http://scrumorakel.de/blog/index.php?/archives/2-Wie-wird-man-ein-guter-ScrumMaster.html" title="http://scrumorakel.de/blog/index.php?/archives/2-Wie-wird-man-ein-guter-ScrumMaster.html">article</a>. Please note, that this is the last translation of one of my German articles for now. If you want to see another one translated, just let me know.<br />
<hr /><br />
You have read my opinion about certification in my last Blog entry. But what can you do to become a good Scrum Master, if a certificate doesn't really help you? Well, here is my opinion:<br />
<ul> <br />
<li>Start. Only who is fully grounded in experience can understand why and how Scrum works. </li> <br />
<li>Learn from your (own) mistakes (inspect and adapt). Everybody who starts doing something will make mistakes. No worries - but learn from them. Reflect yourself regularly. Especially reflect every single item that comes up in the retrospectives. Check if you could have avoided or anticipated it. Also ask yourself, if you had a share in this impediment coming up. As I said: This is not a problem, as long as you learn from it.</li> <br />
<li>Participate in a training. On the one hand, you can learn from a professional how Scrum works. On the other hand you can meet interesting people and keep in touch with them.</li> <br />
<li>Exchange your thoughts with other Scrum-users frequently. No matter if you choose UserGroups, Scrum Tabels, a beer with friends or a Community of Practice in your company - go looking for the exchange. If you can't find anything similar to the aforementioned, create something yourself.</li> <br />
<li>Read much. Even though reading alone does not make you a professional, it broadens your horizon. This gives you some ideas in real situations, which you might not have had without reading. Books, Blogs and forums should be consumed in exactly this priority.</li> <br />
<li>Improve your skills far beyond Scrum. Management practices, psychologies, moderation, mediation, creativity techniques, sociology and so on are at least as important as the hard Scrum knowledge.</li> <br />
<li>Use every opportunity to put to practice whatever you have learned. You are planning a private project? Good - why don't you try a Backlog and Iterations on this one? Your girlfriend cannot decide where to go for the holidays? Well, take the role of the PO and write down the relevant criteria. Your private project has ended? How did it go and what can you learn from it for the future? Of course you are allowed to use your skills on projects from your professional live as well. <img src="http://www.scrumorakel.de/blog/templates/default/img/emoticons/wink.png" alt=";-)" style="display: inline; vertical-align: bottom;" class="emoticon" /></li> <br />
<li>Take aid. If your Team is stuck, it needs an expert - so do you. Nobody can be perfect in all areas - this is valid for you as well. Look for somebody who is a professional in the area you are lacking the most skill (Psychology? Process? Organizational development?) and learn as much as possible from this person. Maybe you can solve related problems alone next time.</li> <br />
<li>Consider that you can strengthen your strengths and weaken your weaknesses. You won't ever become a hero in your weak spots though. Usually it's better to acknowledge your weaknesses and take some aid there, while you develop your strengths to a point where you are a true expert.</li><br />
</ul>Did I forget something or am I wrong somewhere? I am happy to learn about your opinions.<br /><br /><img src="http://vg01.met.vgwort.de/na/bd801d5cc62d4185a8ee7f87604e6f11" width="1" height="1" alt=""><br />
Scrumorakel - Blognospam@example.com (Dominik Maximini)2012-01-15T10:31:32Zhttp://www.scrumorakel.de/blog/wfwcomment.php?cid=270http://www.scrumorakel.de/blog/rss.php?version=1.0&type=comments&cid=27What good are certificates?
http://www.scrumorakel.de/blog/index.php?/archives/26-What-good-are-certificates.html
This is a translation of my most visited German <a href="http://scrumorakel.de/blog/index.php?/archives/1-Was-sagen-Zertifizierungen-aus.html" title="http://scrumorakel.de/blog/index.php?/archives/1-Was-sagen-Zertifizierungen-aus.html">article</a>. Since it seems to spark quite some interest, here is a English version:<br /><br /><br />
<br />
I am often asked which Scrum certificate is "the right one" for Scrum users. To cover this topic in depth, I wrote this blog.<br />
<br />
<ol><li>You do not need any certificate to be skillful at any topic. Certificates only very rarely prove skill, but rather state a level of knowledge tested by the certificate at a certain point of time. Only because somebody carries a certificate with him he is not necessarily the right person for the task ahead. Think back to the time when you did the exams for your diploma, your a-levels exam or your driving license: Would you be able to correctly answer all questions, you passed back then? How much did your university degree help you when you finally hit the real world? In my case, I could use around 10% of everything I had learned - the rest taught me the job itself...<br /><br /></li><li>There are three organisations that are known worldwide whose certificates are worth mentioning: PMI, Scrumalliance and Scrum.org<br /><br /></li><li>The <a href="http://www.pmi.org/Certification/New-PMI-Agile-Certification/PMI-Agile-Certification-Pilot-Program.aspx" title="http://www.pmi.org/Certification/New-PMI-Agile-Certification/PMI-Agile-Certification-Pilot-Program.aspx">PMI-Agile</a> certificate is nearing the end of its pilot phase. I did not do it myself, so I cannot be sure about its quality. However, it is worth noting that a candidate needs 2.000 hours of "General Project Management Experience". In my experience, a good "classical" project manager still has to go a long way to become a good Scrum Master or Product Owner.<br /><br /></li><li>The <a href="http://scrumalliance.org/pages/scrum_certification" title="http://scrumalliance.org/pages/scrum_certification">Scrumalliance</a> certifies that you sat through a course. There is a multiple-choice test at the end of the Certified Scrum Master course, but it is too simple to be taken serious and your score doesn't count towards your certificate. You could even answer everything wrong and still get the certificate. I did the test just for fun and was impressed to see not only the correct answer for each question (after I hit the "Next" button), but to see that Scrumalliance links for further studies to external sources like Scrum.org, Mountain Goat Software, etc. You can only try this exam after you have taken a CSM course.<br /><br /></li><li>You will sweat quite a bit with <a href="http://www.scrum.org/assessments/" title="http://www.scrum.org/assessments/">Scrum.org</a>. The exams are difficult to very difficult and have to be taken online as well. To become a "Professional Scrum Master I", you do not have to visit a course (so far, only the PSM assessments are openly available. For PSD and PSPO you have to take a course). Instead, you can pay 100 $ for every try. 80 multiple-choice questions and one hour of time then stand between you and your PSM I certificate. You have to to right on 85% of the questions to pass. If you want to become a trainer later, you even have to reach 95%. About 80% of the applicants passes the PSM I, the rest fails. If you acquired the PSM I certificate, you are allowed to try the PSM II. This costs 500$ per try (300$ if you have previously visited a PSM course), takes 2 hours of your time and is a mixture of multiple-choice and essay questions. Again, you have to score 85% to pass and 95% to become a trainer. So far, only 106 people worldwide passed that one. Some of them not with their first try. The most difficult part here is to exactly understand what the scrum.org is asking. Sometimes you have to read between the lines. Not so nice is, that you do not get to know which questions you did wrong. This way it's really hard to prepare for this exam (which is a good thing in my opinion). It is not possible to learn questions by hard or answer them beforehand. Those certificates do not have to be renewed every two years, as opposed by those of the PMI and Scrumalliance. So you only have to pay your fees once.<br /><br /></li><li>Who needs which certificate? First, some hints: Whoever wants to obtain a certificate should think hard what he wants to "prove" with it. If he wants to show that he has been to a course, all providers have good options. If you already hold a PMI certificate, you might want to look into the "PMI Agile". If you want to prove professional knowledge (at the point of time when you take the exam), then the Scrum.org is your only alternative so far. It helps that everyone can do the assessment and 100 $ are quite affordable.<br /><br /></li><li>Developers (Coder, Tester, etc.): Usually professional skills are far more important than process knowledge. You should question yourself if you really need a certificate. If you do, look at the Scrumalliance and the Scrum.org, both offer developer courses with certificates. When you go for the Scrum.org you will be presented with a 3-day or 5-day course, depending on your level of knowledge. This one is streamlined, so you will receive the same quality all over the world. Both the scrumalliance and the scrum.org teach you process and developer skills.<br /><br /></li><li>Product Owner: Usually, a Scrum Master course is not the right place for a Product Owner, because his main duty is Return on Invest (ROI), not the Scrum flow. You should go for a Product Owner course instead - with the attached certificates. PMI does not offer this option.<br /><br /></li><li>Scrum Master: If you already are experienced and think you could pass the assessment, go for the Scrum.org. If you want a certificate but do not want to do an exam for it, go for the Scrumalliance. IMHO the PSM II certificate is the only one out there meaning anything. Only the PSM II creates some sort of "unique selling point" for you, if that is what you are looking for.<br /><br /></li></ol>I still do not believe that anybody needs a certificate to be a good Scrum Master. I also do not believe that a certificate "proves" much. Yet it feels good to hold one <img src="http://www.scrumorakel.de/blog/templates/default/img/emoticons/wink.png" alt=";-)" style="display: inline; vertical-align: bottom;" class="emoticon" /><br /><br /><img src="http://vg01.met.vgwort.de/na/75e777c3d1fa45a9952aba2309884221" width="1" height="1" alt="">
Scrumorakel - Blognospam@example.com (Dominik Maximini)2011-12-30T16:23:42Zhttp://www.scrumorakel.de/blog/wfwcomment.php?cid=260http://www.scrumorakel.de/blog/rss.php?version=1.0&type=comments&cid=26Standard equipment for Scrum moderations
http://www.scrumorakel.de/blog/index.php?/archives/25-Standard-equipment-for-Scrum-moderations.html
This is a not exactly a Scrum topic, but it IS quite useful to every Scrum Master. In addition, when coaching new Scrum Masters I often find that they don't have a clue about what they need to get started. That's why I let you peek into what I usually use.<br /><br />
<!-- s9ymdb:14 --><img class="serendipity_image_center" width="640" height="478" src="http://www.scrumorakel.de/blog/uploads/koffer.jpg" title="moderation suitcase" alt="moderation suitcase" /><br /><br />
What you can see here is a standard moderation suitcase filled with all the good stuff I usually use during my meetings. The contents last for about a week, depending on the amount of moderated workshops. Let's take a closer look at what you can find in there:<br /><br />
<!-- s9ymdb:13 --><img class="serendipity_image_center" width="640" height="478" src="http://www.scrumorakel.de/blog/uploads/koffer_nr.jpg" title="description of suitcase contents" alt="description of suitcase contents" /><br /><ol><li>Invisible tape. Always helpful for tying stuff to other stuff or fixing sticky notes permanently to a sheet of paper.</li><li>Magnets. Useful, if you want to pin paper charts to a whiteboard.</li><li>Planning poker cards. For this customer, we could not use Story Points, so I switched to T-Shirt sizes. Whatever the metric, you should always be ready to estimate some Product Backlog items.</li><li>Needles for pinning cards or paper sheets to a pin board. Note that the needles are ready-to-use and not in some plastic casing.</li><li>A glue stick. Hard to see on this picture. You never know if you want to glue something to something else. I rarely use it, but I am glad to have it when I do.</li><li>Pens. Those pens are whiteboard-pens, so they are easily wipeable. I never use flipchart pens, because sooner or later they end up on the whiteboard and I have to struggle to get it off again. The colors I use are black, green, blue and red. I always have at 20-25 pens with me.</li><li>Scissors. You never know when you want to trim something. It happens more often than one might think.</li><li>Very small sticky notes. They are good to mark off stuff.</li><li>Painers' tape. You need it to fix bigger paper charts (flipcharts, brownpaper and so on) to the wall.</li><li>Points in different colors. I use them for voting and sometimes for highlighting.</li><li>Small round moderation cards. I rarely use moderation cards, but sometimes I need them.</li><li>My lovely sticky notes. The size is 127x76 mm. You should find some that last for more than 4 weeks on the wall. I prefer bright colors, because they can be seen and draw attention.</li><li>A kitchen timer. You actually can't see it, but I always have a timer with me. I usually timebox every single assignment during a workshop.</li></ol>With such a suitcase you are well equipped for any moderation task that might arise. You of course will need a whiteboard, flipchart and/or large sheets of brown paper - but those don't fit into a suitcase...<br /><br /><img src="http://vg01.met.vgwort.de/na/f60426d782df45d19c645b25110a5a73" width="1" height="1" alt="">
Scrumorakel - Blognospam@example.com (Dominik Maximini)2011-12-10T09:11:23Zhttp://www.scrumorakel.de/blog/wfwcomment.php?cid=250http://www.scrumorakel.de/blog/rss.php?version=1.0&type=comments&cid=25Language Change
http://www.scrumorakel.de/blog/index.php?/archives/24-Language-Change.html
Due to popular demand, I change my "blogging language" to English from now on. I will translate some of the older Blog entries as well, depending on how many people actually read them. If you find an entry you would really like to have in English, let me know. Drop me an Email and I will put your request into my "Blog backlog".<br /><br />
Scrumorakel - Blognospam@example.com (Dominik Maximini)2011-12-03T14:29:59Zhttp://www.scrumorakel.de/blog/wfwcomment.php?cid=240http://www.scrumorakel.de/blog/rss.php?version=1.0&type=comments&cid=24Sprachenwechsel
http://www.scrumorakel.de/blog/index.php?/archives/23-Sprachenwechsel.html
Ab sofort werde ich Blogbeiträge auf Englisch verfassen. Hintergrund sind die vielen Anfragen internationaler Kollegen. Für die Zukunft gilt: Ist ein Beitrag besonders interessant, aber verursacht durch die Sprache Verständnisprobleme, schickt mir einfach eine Email. Ich übersetze ihn dann ganz oder in Teilen.<br /><br />
Scrumorakel - Blognospam@example.com (Dominik Maximini)2011-12-03T14:27:57Zhttp://www.scrumorakel.de/blog/wfwcomment.php?cid=230http://www.scrumorakel.de/blog/rss.php?version=1.0&type=comments&cid=23Scrum-Chimären
http://www.scrumorakel.de/blog/index.php?/archives/22-Scrum-Chimaeren.html
Was ist eine Chimäre? Und was hat das mit Scrum zu tun? Fangen wir vorne an und sehen mal, was <a href="http://de.wikipedia.org/wiki/Chimäre" title="http://de.wikipedia.org/wiki/Chimäre">Wikipedia</a> dazu sagt:<br />
<blockquote>Chimäre, Schimäre, teils Chimaera, Chimaira, Chimera (Eindeutschung bzw. Transliterationen von griechisch: Χίμαιρα Chímaira „die Ziege“) steht für:<ul><li>Chimäre (Mythologie), ein Geschöpf der griechischen Mythologie</li><li>Mischwesen, allgemein mythische Zusammenfügungen von Lebewesen</li><li>Chimäre (Genetik), Organismen mit Erbinformationen verschiedener Individuen</li><li>Trugbild, eine Einbildung, Täuschung</li></ul></blockquote><br />
Jeder kennt die Sphinx (Chimäre aus Frauenkopf und Löwenkörper), den Greif (Löwenkörper und Vogelkopf sowie Flügel), den Pegasus (Pferd mit Flügeln) und den Mantikor (Löwenkörper, Menschenkopf, Skorpionschwanz und in manchen Darstellungen auch noch Drachenflügel).<br />
<br />
Es gibt eine ganze Menge Scrum-Implementierungen, die ich als "Scrum-Chimären" bezeichne. Auch die Bezeichnungen "Frankenstein-Scrum" und "Hybrid-Scrum" sind durchaus gängig. Einfach erklärt: Es werden ein paar Elemente aus Scrum angewendet und mit anderen, meist bestehenden, Prozessen vernäht. Es gibt Fälle, in denen das wunderbar funktioniert. Das sind die Fälle, in denen das Unternehmen alle vernähten Teile vollständig durchdrungen sowie verstanden hat und erst danach beginnt, Anpassungen vorzunehmen. Solange diese Unternehmen ihr "Customizing" nicht Scrum nennen, spricht nichts dagegen.<br />
99,9% der angepassten Prozesse werden allerdings sehr schnell zu einem Untier, wie die griechische und mittelalterliche Mythologie sie beschreiben: Meist Menschenfresser, gegen die nur absolute Helden überleben. Erfolgreiche Projekte sind hier eher unwahrscheinlich.<br />
Scrum passt auf 16 Seiten (siehe aktueller <a href="http://www.scrum.org/scrumguides/" title="http://www.scrum.org/scrumguides/">Scrumguide</a>). Eigentlich sind es sogar nur 13, wenn man Deckblatt, Inhaltsverzeichnis und Danksagungen abzieht. Das ist nicht viel - aber genug für ein effizientes Framework zur Produktentwicklung (zählen Sie mal, wie oft das Wort "Software" im aktuellen Scrumguide steht...). Mit diesen relativ einfachen Mitteln erzeugt man Transparenz durch alle Bereiche des Projektes und stattet jeden Bereich mit einer Möglichkeit zur Inspektion und Adaption aus. Lässt man jetzt eines der wenigen Scrum-Elemente (3 Rollen, 3 Artefakte und 5 Events) weg, dann fällt damit automatisch die dazu gehörige Transparenz zusammen mit der Anpassungsmöglichkeit weg. In aller Regel ersetzt der stattdessen angenähte Prozess den entsprechenden Punkt, ohne eine vergleichbare Transparenz zu erzeugen. Meist werden die Teile von Scrum weggelassen, durch deren Transparenz am meisten Schmerzen entstanden sind (Was übrigens lächerlich ist: Wenn der Arzt bei Ihnen Krebs diagnostiziert - haben Sie den, weil Sie beim Arzt waren, oder hatten Sie den schon vorher, haben den Umstand jetzt aber transparent und können endlich etwas dagegen unternehmen?). Was dann noch übrig bleibt ist der alte Prozess, bei dem die bestehenden Mechanismen neue Etiketten aufgeklebt bekommen haben. Nach einiger Zeit stellt man dann fest, dass eigentlich alles noch genauso ist wie früher - oder sogar noch schlimmer, weil die hohen Erwartungen an Scrum "nicht erfüllt" wurden. Oft gehen dann einige Mitarbeiter - die Besten zuerst. Also wird das "Monster" umgebracht. Das klingt dann so:<blockquote>Scrum funktioniert nicht! Bei uns ist außer Kosten nichts gewachsen.</blockquote><br />
Man sucht dann nach dem nächsten Etikett, dass man aufkleben kann - das alte hält schließlich nicht mehr.<br /><br /><br /><br />
Fazit: Es ist Ihr Unternehmen. Arbeiten Sie mit den Prozessen, die für Sie am Besten sind. Wenn für Sie Teile von Scrum in Frage kommen, aber nicht das Komplettpaket, nennen Sie es auch nicht Scrum. Machen Sie sich außerdem - wenn nötig mit Hilfe von echten Spezialisten - klar, welche Folgen Ihre Anpassungen haben. In 99,9% aller Fälle gilt: Mit dem Komplettpaket fahren Sie erheblich günstiger und effektiver. Zumindest, bis Sie das Thema durchdrungen haben und die Auswirkungen von Änderungen mit ihrer ganzen Tragweite begreifen. Chimären sind nicht ohne Grund seit der Antike ausgestorben.<br /><br /><br /><img src="http://vg01.met.vgwort.de/na/e7e6dbfe60724ec6bf3666d335f8a071" width="1" height="1" alt="">
Scrumorakel - Blognospam@example.com (Dominik Maximini)2011-11-20T11:28:11Zhttp://www.scrumorakel.de/blog/wfwcomment.php?cid=220http://www.scrumorakel.de/blog/rss.php?version=1.0&type=comments&cid=22PM Forum 2011
http://www.scrumorakel.de/blog/index.php?/archives/21-PM-Forum-2011.html
Auf dem diesjährigen <a href="http://www.pm-forum.de/" title="offizielle Seite des PM Forums">PM Forum</a> in Nürnberg war ich mit dem Vortrag "Planung in Softwareprojekten? Das brauchen wir nicht, wir sind agil!" vertreten (wer nachlesen will, kann das z.B. <a href="http://www.novatec-gmbh.de/nc/aktuelles/nachrichten/detailansicht-nachrichten/article/pm-forum-2011/" title="Vortragsfolien">hier</a> tun). Das Event war von 840 Personen besucht, knapp 200 davon durfte ich in meinem Vortrag begrüßen. Aus Scrum-Sicht ist eines klar geworden: Wir Scrumies haben uns in der Vergangenheit nicht gut genug um das Management gekümmert. Wie kann es sein, dass die triviale Botschaft "auch mit Scrum muss man angemessen planen" für fast alle Teilnehmer neu war? Wieso mussten wir am Stand immer wieder die gleichen Anfängerfragen klären? Und wie kann es sein, dass bei anderen Vorträgen - von selbsternannten agilen Experten - teilweise falsche Informationen weitergegeben werden? Es wundert mich immer weniger, dass ich häufig auf die Haltung treffe, dass "Scrum ja eh nicht funktioniert". Wie soll es denn auch, wenn das Know-How dazu nicht an allen Stellen vorhanden ist?<br />
<br />
Mein Vorschlag ist, dass wir uns ab sofort viel intensiver um das Management kümmern. Nicht nur die Entwickler, sondern auch das Management benötigt Schulungen, Zuwendung und Klarheit!<br /><br /><br />
<br />
Scrumorakel - Blognospam@example.com (Dominik Maximini)2011-11-05T10:21:45Zhttp://www.scrumorakel.de/blog/wfwcomment.php?cid=210http://www.scrumorakel.de/blog/rss.php?version=1.0&type=comments&cid=21Die Rolle des Managements in Scrum
http://www.scrumorakel.de/blog/index.php?/archives/20-Die-Rolle-des-Managements-in-Scrum.html
In Scrum haben wir ein Entwicklungs-Team, einen Scrum Master und einen Product Owner - vom Management redet aber kaum jemand. Im Gegenteil: Viele Scrummer vertreten die Ansicht, man bräuchte mit Scrum kein Management mehr. Das ist natürlich grundlegend falsch. Diese Meinung wird aber unglücklicherweise sogar noch durch eine Frage aus dem PSM I Assessment und ihrer Antwort gefördert:<br />
<blockquote>What is the role of management external to the Scrum Team? - Management has no role in Scrum</blockquote><br />
Meist wird diese Antwort so gedeutet, dass man kein Management bräuchte. Was sie aber aussagt ist lediglich, dass "Management" keine Rolle nach Scrum ist. Scrum allein kann nicht das gesamte Unternehmen "am Leben" erhalten, es ist nur ein Teil des großen Ganzen.<br />
Besser ist da schon die folgende Frage aus dem Open Assessment:<blockquote>What is the role of Management in Scrum? - Management supports the Product Owner with insights and information into high value product and system capabilities. Management supports the Scrum Master to cause organizational change that fosters empiricism, self-organization, bottom-up intelligence, and intelligent release of software</blockquote><br />
Demnach hätte "Management" also im Hinblick auf Scrum die Aufgabe, Product Owner und Scrum Master zu unterstützen. Das ist aber in den meisten Fällen zu vage. Bringen wir es also lieber auf den Punkt:<br />
<br />
Das Management eines Unternehmens muss...<ul><li>die Unternehmensstrategie vorgeben</li><li>an der Produktvision und -strategie mitwirken</li><li>strategische Möglichkeiten im Markt erkennen und kommunizieren (zusätzlich zum PO)</li><li>Ressourcen für die Produktentwicklung bereitstellen</li><li>dafür sorgen, dass die Mitarbeiter sich wohl fühlen und optimal arbeiten können</li><li>strategische Personalentwicklung forcieren</li><li>jedem einzelnen Mitarbeiter ständig Feedback zu seinen Leistungen geben und mit ihm gemeinsam sein volles Potential erschließen</li><li>die Organisation selbst entwickeln</li><li>systemische Probleme (Impediments) in der Organisation beseitigen</li></ul><br />
Das Management ist der wichtigste Unterstützer eines jeden Scrum-Projektes. Ohne Management geht es nicht (wie z.B. schonmal <a href="http://scrumorakel.de/blog/index.php?/archives/11-Wozu-braucht-Scrum-das-Management.html" title="http://scrumorakel.de/blog/index.php?/archives/11-Wozu-braucht-Scrum-das-Management.html">hier</a> beschrieben). U-Boot-Implementierungen von Scrum können mittelfristig nur dann erfolgreich sein, wenn sie das Management mit ins Boot holen. Nur wenn diese strategischen und "machtvollen" Aufgaben wahrgenommen werden, können wir die Organisation verändern und erhebliche Wirkung erzielen. Das dürfen wir nie vergessen!<br /><br /><br /><br />
<img src="http://vg01.met.vgwort.de/na/f22e37e45ee447cda0de04ba3039689f" width="1" height="1" alt="">
Scrumorakel - Blognospam@example.com (Dominik Maximini)2011-10-16T13:14:06Zhttp://www.scrumorakel.de/blog/wfwcomment.php?cid=200http://www.scrumorakel.de/blog/rss.php?version=1.0&type=comments&cid=20Wie Scrum Digital Natives helfen kann
http://www.scrumorakel.de/blog/index.php?/archives/19-Wie-Scrum-Digital-Natives-helfen-kann.html
Auf dem Scrum Day 2011 habe ich einen Vortrag zu "Digital Natives und Scrum" gehalten. Wegen des äußerst positiven Feedbacks, möchte ich euch diesen Vortrag zum <a href="../Dateien/SD2011_Maximini_small.pdf" TARGET="_blank">Nachlesen</a> zur Verfügung stellen. Die Kerninformationen gibt es hier auch nochmal in der Management-Zusammenfassung:<ul><li>Die echten Digital Natives sind die nach 1980 geborenen Menschen, die äußerst versiert im Umgang mit den digitalen Techniken unserer Zeit sind</li><li>Diese Menschen werden bis 2020 mehr als 50% der gesamten arbeitenden Bevölkerung stellen - es führt also kein Weg an ihnen vorbei</li><li>Digital Natives sind sehr gut ausgebildet und haben einen starken Drang, sich ständig weiterzubilden. Auch sind sie sehr kreativ (Blogs, Youtube, Bildbearbeitung, Webseiten, ...) - es lohnt sich also, sich mit ihnen zu befassen.</li><li>Digital Natives wollen partizipieren statt nur zuzuschauen. Sie ignorieren Hierarchien und beurteilen Menschen nach ihren Leistungen und nicht nach ihrem Rang. Das kann schwierig sein.</li><li>Für diese Generation existieren weder zwischen Internet und "Real Life" noch zwischen Ländern ernstzunehmende Grenzen. Es ist ihre Welt und ihr Leben. Sie sind entsprechend flexibel und mobil.</li><li>Sie versuchen sich auch im Berufsleben selbst zu verwirklichen und unterscheiden daher oft nicht zwischen Job und Privatleben. Entsprechend ist es wichtig, ein Arbeitsumfeld zu schaffen, in dem man sich "zuhause" fühlt und Freunde finden kann.</li><li>Im Internet ticken außerdem die Uhren anders: In "Internetzeit" ist ein Jahr ewig und 3 Tage schon lang. Digital Natives erwarten daher alles "sofort und gleich".</li><li>Scrum verflacht Hierarchien, weist klare Verantwortlichkeiten zu, verlangt Selbstorganisation und Teamwork. Alles Faktoren, die Digital Natives anziehen. Scrum alleine wird zwar nicht reichen, aber es ist ein guter Anfang. Gerade auch die kurzen Iterationen mit schnellem Feedback sind attraktiv.</li></ul>Wer mehr Details möchte ist gerne dazu eingeladen, den Kontakt mit mir aufzunehmen und/oder den Vortrag nochmals anzuschauen.<br /><br /><br />
Scrumorakel - Blognospam@example.com (Dominik Maximini)2011-10-03T09:37:11Zhttp://www.scrumorakel.de/blog/wfwcomment.php?cid=190http://www.scrumorakel.de/blog/rss.php?version=1.0&type=comments&cid=19Professional Scrum Product Owner Kurs
http://www.scrumorakel.de/blog/index.php?/archives/18-Professional-Scrum-Product-Owner-Kurs.html
Letzte Woche habe ich PSPO-Kurs in Frankfurt teilgenommen. Die Eindrücke möchte ich mit euch teilen.<br />
<br />
Der Kurs folgt der neuen Linie der Scrum.org, dass alle Kurse auf den "Professional Scrum Foundations" (PSF) aufbauen. Das ist gut, denn so spielt Scrum im Kurs nur eine untergeordnete Rolle und wir konnten uns intensiv mit den wirklich wichtigen Dingen beschäftigen. Hauptthema des Kurses ist die Aufgabe des Product Owners: Nämlich Return on Invest (RoI) und Total Cost of Ownership (TCO) zu optimieren. Das Bild des POs hat sich seit der Einführung von Scrum entwickelt: Während einige Autoren diese Rolle oft als "User-Story-Schreiber" gesehen haben, ist mittlerweile glasklar, dass wesentlich mehr dazu gehört. Am PO hängen Wohl und Wehe des Projektes, ja der Wert (Value!) des Produktes hängt von dieser Rolle ab. Daher ist es auch nicht in jedem Projekt notwendig, dass der Product Owner die User Stories selbst schreibt. Manchmal können das Entwickler (besonders wenn es Analysten oder technische Schreiber sind) einfach besser. Das entbindet den PO natürlich nicht von seiner Aufgabe, dem Entwicklungsteam im erforderlichen Maße darzulegen, was er sich im Sprint erwartet. Auch die Priorisierung des Product Backlogs wird er nicht abgeben können.<br />
<br />
Den Kurs kann ich nur jedem PO (und auch jedem interessierten Scrum Master) empfehlen. Ahnung von Scrum muss man eigentlich nicht dazu haben (allerdings ist das wünschenwert) - wer sich intensiv um RoI und TCO kümmert, wird ein besserer PO als jemand, der diese Begriffe nicht kennt, aber dafür mit der Scrumterminologie um sich wirft.<br />
<br />
Der logische nächste Schritt ist jetzt, den PSM-Kurs so umzuarbeiten, dass alle "Einsteigerthemen" entfernt werden. Dafür gibt es schließlich den PSF-Kurs. Dann können wir uns im PSM-Kurs noch intensiver um die fortgeschrittenen Themen kümmern. Mal sehen, was Ken sich dazu einfallen lässt...<br />
<br />
<br /><br />
Scrumorakel - Blognospam@example.com (Dominik Maximini)2011-10-01T19:04:31Zhttp://www.scrumorakel.de/blog/wfwcomment.php?cid=180http://www.scrumorakel.de/blog/rss.php?version=1.0&type=comments&cid=18versteckte Impediments
http://www.scrumorakel.de/blog/index.php?/archives/17-versteckte-Impediments.html
Jeder hat wohl schon die ein- oder andere Retrospektive erlebt. Als Scrum Master ist es eure Aufgabe, den Prozess ständig zu verbessern und die Produktivität sowie die Zufriedenheit zu erhöhen. Klingt soweit einfach. Jeder wird auch in seiner Retrospektive aktuelle Impediments finden - aber was ist mit den "vergrabenen" Problemen, an die sich die Kollegen schon gewöhnt haben? Gerade in großen, stark tayloristisch geprägten Unternehmen oder bei "Scrum"-Implementationen, die nur ein Deckmantel für das Beibehalten der alten Wasserfallvorgehensweisen sind, machen diese oft den weitaus größten Teil der Impediments aus. Gerade Implementationen von Scrum, die keine ausreichende Management-Unterstützung haben, leiden mit großer Wahrscheinlichkeit darunter.<br />
Wenn ihr den Verdacht habt, dass die Produktivität eurer Teams schlechter ist, als es nach der Meinung der Teams der Fall ist, versucht doch mal eine Retrospektive, die auch die versteckten Aufwände ans Licht bringt. Zunächst solltet ihr mit einer Analyse der vergangenen Retrospektiven ein paar Impediment-Kategorien ermitteln (z.B. Impediments durch das eigene Team, durch fremde Teams, durch die Infrastruktur, usw.). Diese sollen ruhig grob sein, damit die Teams genügend Spielräume behalten und nicht zu sehr in ein Korsett gezwängt werden. In der Retrospektive selbst sollte die Aufmerksamkeit des Teams dann darauf gelenkt werden, dass es versteckte Impediments gibt, an die man sich bereits gewöhnt hat. Ein konkretes Beispiel hilft hier meist bei der Kommunikation. Dann sollen die Teams selbst (Sub-)Kategorien entwickeln und mit Zahlen (Personentage oder Stunden) hinterlegen - nach Bauchgefühl, aber im Konsens. Nachdem das Team damit fertig ist (ca. 30 Minuten) sollte es eine kurze Pause machen und dann die aufgeführten Kategorien daraufhin prüfen, ob Aufwände doppelt aufgeführt sind - wir wollen die Zeiten ja nicht mehrfach erfassen.<br />
Diese absoluten Aufwände sind noch nicht vergleichbar. Daher sollte man sie ins Verhältnis mit der verfügbaren Zeit (Kapazität) setzen. Heraus kommt eine Prozentzahl, die besagt, welchen Anteil der Zeit das Team wirklich produktiv arbeiten kann bzw. welche Kosten das Unternehmen durch unvollkommene Prozesse und Tools verursacht.<br />
Natürlich sagt die Velocity im Endeffekt das Gleiche aus. Allerdings hat sie nicht die Signalwirkung wie zeitliche Schätzungen. Will man ein Management ohne ausreichendes Scrum-Wissen von der Notwendigkeit zu handeln überzeugen, helfen harte Zahlen meist mehr als eine relativ weiche Velocity. Das krasseste Beispiel, das ich bislang hatte, war ein Team mit 79% versteckten Impediments. Kein Wunder, dass die Zufriedenheit äußerst gering war...<br />
SO ermittelte Prozentquoten entsprechen in etwa dem "Fokus Faktor", den Henrik Knieberg in seinem Buch "Scrum and XP from the trenches" beschreibt. Ich favorisiere grundsätzlich die normale Velocity, weil sie schneller und leichter zu ermitteln ist, aber manchmal braucht das Management andere Zahlen.<br />
<br />
Achja: In gut funktionierenden Scrum-Teams mit hoher Produktivität ist die oben beschriebene Form der Retrospektive meistens nicht sonderlich ergiebig, da diese Teams ganz genau wissen, woran es hakt und diese Missstände nicht hinnehmen. Da kennt und liebt normalerweise auch das Management Scrum.<br /><br /><img src="http://vg01.met.vgwort.de/na/5b1b8d798a76463782cfd41caea9efcb" width="1" height="1" alt="">
Scrumorakel - Blognospam@example.com (Dominik Maximini)2011-09-06T05:12:24Zhttp://www.scrumorakel.de/blog/wfwcomment.php?cid=170http://www.scrumorakel.de/blog/rss.php?version=1.0&type=comments&cid=17deutscher Scrum Guide 2011
http://www.scrumorakel.de/blog/index.php?/archives/16-deutscher-Scrum-Guide-2011.html
Letzten Freitag sind wir endlich die Übersetzung des <a href="http://www.scrum.org/storage/scrumguides/Scrum%20Guide%20-%20DE.pdf#view=fit" title="http://www.scrum.org/storage/scrumguides/Scrum%20Guide%20-%20DE.pdf#view=fit">Scrum Guide</a> abgeschlossen. Die fleißigsten Helfer waren dabei Andreas Schliep, Ulf Schneider, Wolfgang Wiedenroth und ich. <br />
<br />
Was hat das im Blog verloren? Nunja: Wir hatten eine recht aufwändige Definition of Done, daher hat es etwas länger gedauert. Im Einzelnen bedeutet das<ol><li>Alle Scrum-Begriffe wurden intensiv diskutiert und dann einheitlich übersetzt</li><li>Das Dokument wurde nach Fertigstellung nochmals daraufhin reviewt, ob alle Scrum-Begriffe durchgängig überall korrekt übersetzt waren</li><li>Das Dokument wurde abschließend einmal inhaltlich und einmal auf Rechtschreibfehler kontrolliert</li><li>Jeder übersetzte Satz wurde von mindestens 4 Augen überprüft</li><li>Die finale Version wurde von einem Haufen erfahrener Scrum-Anwender nochmals überprüft</li></ol><br />
Erst damit haben wir den Zustand "Done Done" erreicht. In dem Zusammenhang kann ich euch übrigens <a href="http://www.systematic.com/Files/IS%20files/Downloads/Articles/Articles%20in%20English/Scrum%20and%20CMMI%20-%20Going%20from%20Good%20to%20Great.pdf" title="Ready Ready to be Done Done">diesen Artikel</a> empfehlen. Wir sind der Meinung, dass die Qualität des deutschen Beitrags den anderer Länder übertrifft. Muss er auch - unsere Nation ist sehr kritisch <img src="http://www.scrumorakel.de/blog/templates/default/img/emoticons/smile.png" alt=":-)" style="display: inline; vertical-align: bottom;" class="emoticon" /><br />
<br />
Ich wünsche euch viel Spaß beim deutschen Schmökern und freue mich auf viele konstruktive Rückmeldungen zur Übersetzung.<br />
<br />
<br /><br />
Scrumorakel - Blognospam@example.com (Dominik Maximini)2011-09-05T04:52:31Zhttp://www.scrumorakel.de/blog/wfwcomment.php?cid=160http://www.scrumorakel.de/blog/rss.php?version=1.0&type=comments&cid=16Versagen bei der Definition of Done
http://www.scrumorakel.de/blog/index.php?/archives/15-Versagen-bei-der-Definition-of-Done.html
Diese Woche hatte ich ein interessantes Erlebnis. Ich hatte den Vorschlag im "Scrum of Scrums" gemacht, unternehmensweite DoDs einzuführen, welche auch die Bereiche der Organisation einschließen sollten, die aktuell immer wieder zu Problemen wegen mangelhafter Qualität führen. Dieser Schritt hätte auch zu einer "Definition of Ready" der POs führen können - was dem Unternehmen gut tun würde. Soweit kam es aber nicht. Nach einer relativ langen und äußerst lebhaften Diskussion stellte sich heruas, dass einige der insgesamt 8 Teams ihre DoD nicht kannten. Noch schlimmer: Sie wussten nicht einmal, was genau das ist. Natürlich habe ich direkt Gegenmaßnahmen ergriffen - trotzdem kann es vielleicht dem ein- oder anderen Leser helfen, wenn er versteht, wie es dazu kam.<br />
<br />
Vor etwa einem halben Jahr begann ich ein Engagement bei einem Kunden. Damals gab es keine Definition of Done, auch andere Grundelemente von Scrum waren nicht vorhanden. Im Grunde wurde Wasserfall gemacht, man hatte es nur neu gelabelt. Ich führte zunächst ein "Scrum of ScrumMasters" ein und brachte als erstes Thema die DoD auf den Tisch. Wir beschlossen, diese einzuführen. Von unseren Anstrengungen scheinbar entkoppelt, fiel unmittelbar danach eine DoD als Weisheit des "Test-Teams" (ein weiteres Scrum-But) von oben herab und wurde als verpflichtend deklariert. Diese DoD war mit keinem Team abgesprochen und schoss meilenweit am Ziel vorbei. Meine Reaktion auf diese DoD war kurz: Ich bat meine Teams, diese Email zu löschen und wie geplant selbst eine DoD zu entwerfen und mit dem PO zu verhandeln. Dies setzte ich auch gegenüber dem Test-Team durch und coachte die übrigen ScrumMaster darin, eine DoD zu entwickeln, einzuführen sowie kontinuierlich zu verbessern. Die Kollegen vermeldeten kurz danach Erfolg. In der (ebenfalls neu eingeführten) Retrospektive wurden die DoDs überarbeitet und eingeführt, in den folgenden Reviews wurde jedem Team die Frage gestellt, ob die DoD auch bei allen fertigen Stories eingehalten wurde. Dies wurde meist bejaht.<br />
Klingt doch soweit in Ordnung. Wie konnte es trotzdem zu solchen erheblichen Defiziten kommen?<br />
<br />
Es stellte sich heraus, dass einer der Scrum Master Kollegen es versäumt hatte, seinen Teams zu erklären, was eine DoD ist und wofür man sie braucht. Stattdessen wurde eine DoD per Email an das Team geschickt ("das ist jetzt eure DoD") und natürlich sofort vom Team ignoriert und vergessen. In der Folge einigte man sich auf den "Daumen des Product Owners" als Definition of Done - hop oder top wie im alten Rom. Nur leider hatten dadurch weder das Team noch der PO auch nur den Hauch einer Ahnung, wie gut die Qualität der gelieferten Features war. Auch unterschied sich die Qualität von Story zu Story stark. Jetzt sind es genau diese beiden Teams, die in einer Flut von Bugs versinken. Der Scrum Master dieser Teams hat auf ganzer Linie versagt - und ist leider nicht mehr verfügbar, um ihn zu coachen (er hat sich anderen Herausforderungen gestellt).<br />
<br />
Was haben wir aus diesen Fehlern gelernt? Wie lösen wir das Problem?<br />
<br />
Zunächst habe ich den Teams erklärt, was eine DoD ist und wofür sie gut ist. Auch habe ich die Folgen der fehlenden DoD transparent gemacht. Anschließend tat ich das Gleiche mit den Product Ownern und stieß sofort auf Zustimmung und Verständnis. Zum Nachlesen habe ich diese Informationen auf einer kleinen Wikiseite dokumentiert. Die POs werden zusammen mit ihren Teams und dem in Kürze verfügbaren neuen Scrum Master sinnvolle DoDs definieren.<br />
Als weitere Maßnahme werden sich die Scrum Master in Zukunft gegenseitig coachen. Neben dem "Scrum of ScrumMasters", wird es ein intensives Pairing geben. Immer zwei Scrum Master werden sich in wechselnden Paaren gegenseitig unterstützen und von einander lernen. So wird hoffentlich verhindert, dass uns erneut entgeht, wenn ein Kollege Hilfe braucht.<br />
<br />
Einen erneuten Anlauf für unternehmensweite DoDs wird es wohl in den nächsten paar Sprints nicht geben...<br />
<br /><br /><img src="http://vg01.met.vgwort.de/na/2dd040b330984530a6cdf2bb568b0574" width="1" height="1" alt="">
Scrumorakel - Blognospam@example.com (Dominik Maximini)2011-08-27T06:10:17Zhttp://www.scrumorakel.de/blog/wfwcomment.php?cid=150http://www.scrumorakel.de/blog/rss.php?version=1.0&type=comments&cid=15Die Geschichte von Scrum aus Jeff's Perspektive
http://www.scrumorakel.de/blog/index.php?/archives/14-Die-Geschichte-von-Scrum-aus-Jeffs-Perspektive.html
Es gibt viele Mythen und Geschichten darüber, wie genau Scrum eigentlich erfunden wurde. Jetzt ist mir ein <a href="http://devnology.nl/nl/podcast/10-content/151-jeff-sutherland" title="http://devnology.nl/nl/podcast/10-content/151-jeff-sutherland">Podcast</a> in die Finger geraten, der Licht ins Dunkel bringt. Jeff erzählt darin, wie alles begonnen hat. Einige der bemerkenswerteren Punkte möchte ich hier herausgreifen.<br />
<ol><li>Jeff war Kampfflieger in der AirForce - unter anderem auch in Vietnam. 11 Jahre seines Lebens hat er in diese Tätigkeiten investiert. Irgendwann hat er realisiert, dass seine Kameraden in diesem gefährlichen Beruf ihre Leben verlieren und er hat sich dazu entschieden, in die Privatwirtschaft zu wechseln. Ken war übrigens bei den Marines - aber dazu ein andermal mehr.</li><li>Jeff wechselte in den Medizinbereich und hat dort auch seine Doktorarbeit zur Krebsforschung geschrieben ("Was bringt eine Zelle dazu, zu einer Krebszelle zu werden?").</li><li>Ein Schlüsselerlebnis war damals, dass er mit einigen Leuten aus dem Krankenhaus einen Flugzeugträger im aktiven Dienst besichtigt hat. Jeder an Deck - auch der Rangniedrigste auf dem untersten Deck - konnte ihnen jederzeit sagen, was die Mission des Schiffes war. Die Leute im Krankenhaus konnten das nicht von sich behaupten - nicht einmal die Ärzte kannten die Mission.</li><li>Die ersten tiefen Berührungen mit Projektmanagement gab es danach im Bankensektor. Von diesen wurde er angeworben, um ein eher technisches Problem zu lösen.</li><li>Er musste feststellen, dass es <blockquote>so many projects that were crashing and burning</blockquote> gab - genau wie damals im militärischen Flugdienst mit seinen Kameraden.</li><li>Er begann diese Situation mit den Methoden, die er auch im Rahmen seiner Doktorarbeit genutzt hatte, zu analysieren. Das Ergebnis war erstaunlich: Die Projekte waren immer zu spät; Druck kam von oben; Todesmärsche wurden angeordnet; die Leute hatten einen Hang zum Burnout und definitiv keinen Spaß an der Arbeit; Je größer der Druck wurde, desto mehr Verspätung bekam das Projekt; auch Conways Law ("an organization's structure will reflect in the code") war offensichtlich</li><li>In der Arbeit mit jungen Startups versuchte Jeff dann, Gegenmittel zu entwickeln. Das begann mit einer ausführlichen Recherche von 30 Jahren Harvard Business Review.</li><li>Fündig wurden sie schließlich im Aufsatz <a href="http://www.sao.corvallis.or.us/drupal/files/The%20New%20New%20Product%20Development%20Game.pdf" title="http://www.sao.corvallis.or.us/drupal/files/The%20New%20New%20Product%20Development%20Game.pdf">New New Product Development Game</a> von Nonaka und Takeuchi. Darin wurden sechs Erfolgsfaktoren der erfolgreichen Unternehmen genannt: <ul><li>Eingebaute Instabilität</li><li>Selbstorganisierende Projektteams</li><li>Überlappende Entwicklungsphasen</li><li>Multilearning</li><li>sanfte Kontrolle / Selbstkontrolle</li><li>Organisationsweiter Lerntransfer</li></ul>Die Überschrift über diesem Absatz war "Moving the Scrum downfield", da nach Ansicht der Autoren diese sechs Punkte auch zu einem Rugby-Team in der Spielsituation Scrum passten.</li><li>Jeff übernahm diese Punkte als Basis und entwickelte sie mit Hilfe anderer Erfolgsgeschichten (zum Beispiel von Borland) weiter. Den Namen behielt er bei.</li><li>Irgendwann während dieses Prozesses entschlossen sich Jeff und Ken - der zu diesem Zeitpunkt bereits ähnlich weit in seinen Überlegungen und Bemühungen gekommen war - zusammenzuarbeiten.</li><li>Kurz danach gab es dann die OOPSLA - auf dem es quasi den offiziellen Kick-Off für Scrum gab.</li></ol><br />
<br />
Ich finde diese Einblicke spannend und hoffe, dass ihr euch auch daran erfreuen konntet. Ich werde mal sehen, ob ich von Ken eine ähnlich detaillierte Sicht finde. Sonst frage ich ihn, wenn ich ihn das nächste Mal sehe.<br /><br /><br /><img src="http://vg01.met.vgwort.de/na/d79e2583face4096988d030144ace4f2" width="1" height="1" alt=""><br />
<br />
<br />
Scrumorakel - Blognospam@example.com (Dominik Maximini)2011-08-22T17:34:36Zhttp://www.scrumorakel.de/blog/wfwcomment.php?cid=140http://www.scrumorakel.de/blog/rss.php?version=1.0&type=comments&cid=14Meinungen und Hintergründe zum ScrumGuide
http://www.scrumorakel.de/blog/index.php?/archives/13-Meinungen-und-Hintergruende-zum-ScrumGuide.html
Einige Punkte aus dem ScrumGuide 2011 werden in der Community heiß diskutiert. Während man die Art und Weise kritisieren kann, mit der einige Kollegen <a href="http://borisgloger.com/2011/08/10/scrum-guide-2011-forecasten-wir-das-ende-des-commitments/" title="http://borisgloger.com/2011/08/10/scrum-guide-2011-forecasten-wir-das-ende-des-commitments/">"um sich schlagen"</a>, so sind einige der Argumente durchaus diskussionswürdig. <ol><li>Die hinter Scrum stehenden Werte (Mut, Offenheit, Vertrauen, Fokus...) tauchen nicht im ScrumGuide auf</li><li>Forecast ist "schwächer" als Commitment</li><li>Das "Team" heißt jetzt "Development Team"</li><li>Burndowns sind verschwunden</li><li>Es gibt keine Releaseplanung mehr</li></ol><br />
Die meisten Diskussionspunkte führen deshalb zu erhitzten Gemütern, weil die Idee des ScrumGuides sich geändert hat. Während in der Vergangenheit versucht wurde, "ganz Scrum" zu beschreiben ist die neue Idee, ein <a href="http://www.scrum.org/storage/Scrum%20Update%202011.pdf" title="http://www.scrum.org/storage/Scrum%20Update%202011.pdf">"Regelbuch"</a> herauszubringen, das auch nur dieses enthält: Die Regeln. Strategien, Best Practices und Hintergründe sind nicht Bestandteil dieser "Spielanleitung", sondern separate Dokumente - wenngleich auch sehr wichtig.<br />
<br />
Sehen wir uns vor diesem Hintergrund die einzelnen Punkte etwas genauer an:<ol><li>Die hinter Scrum stehenden Werte fehlen. Sie sind das, worauf Scrum aufbaut und weshalb Scrum entwickelt wurde. Unbestreitbar sind sie das Wichtigste an Scrum überhaupt (zumindest für mich). Trotzdem stehen sie genau da: Hinter Scrum. Sie sind nicht Bestandteil des Regelwerkes, sondern der Grund dafür, dass bestimmte Regeln entwickelt wurden. Es ist zwar wünschenswert, aber nicht notwendig, dass jeder Anwender von Scrum versteht, warum bestimmte Regeln (z.B. Retrospektive oder Timeboxing) existieren - solange er sie befolgt. Meine Vision ist trotzdem, die Werte von Scrum in die Welt hinaus zu tragen (dazu brauche ich aber den ScrumGuide nicht).</li><br />
<li>Forecast ist schwächer als Commitment. Auch hier kann es helfen, <a href="http://kenschwaber.wordpress.com/2011/05/03/empiricism-the-act-of-making-decisions-based-on-what-is/" title="Ken Schwaber's Blog">den Urheber zu fragen</a>. "Commit" war in Scrum schon immer als "forecast" gemeint. Um es noch etwas mehr zu präzisieren: Schon immer hat das Team <strong>versprochen</strong>, fokussiert und mit Hochdruck auf das Sprintziel (bzw. die PBIs) hinzuarbeiten, bei gleichzeitiger Einhaltung der DoD. Schon immer galt bei der Auswahl der PBIs, dass das Team zwar glaubt diese zu schaffen, sich aber <strong>nicht sicher</strong> ist. Das wurde in der Vergangenheit aber von den "Druckaufbauern" und "Kontrollfreaks" missverstanden: Diese Fraktionen werteten auch den zweiten Teil als "Das Team hat versprochen, das Ziel zu erreichen". Das ist natürlich falsch und wird durch "forecast" richtig gestellt. Noch etwas: Wer es nötig hat, hier Druck aufzubauen, sollte sich fragen, ob er seinem Team vertraut ("trust" ist übrigens ein Grundwert von Scrum). Menschen denken unter Druck nicht schneller.</li><br />
<li>Manch einer hat Angst, dass die Umfirmierung von "Team" zu "Development Team" dazu führt, dass einige der Teammitglieder sich angegriffen fühlen. Schließlich "entwickeln" Tester und UI-Experten ja nicht. Oder etwa doch? In meinen Augen ist "Entwicklung" nicht gleichbedeutend mit "Programmierung", sondern bezeichnet den Akt der Produkterstellung von der Idee bis zur Auslieferung. Wenn sich jetzt Teammitglieder darüber beschweren, wird eher ein schon länger existierendes Problem deutlich. Nachforschen kann hier nicht schaden.</li><br />
<li>Kann man Scrum auch ohne Burndowns machen? Na klar! Die Dinger sind zwar einfach und oft hilfreich, aber eben nicht maßgeblich für Scrum. Ich kann meinen Fortschritt auch anders visualisieren. Zum Beispiel mit einem Taskboard. Oder mit Burnup-Charts. Oder wie es eben sonst nützlich und angebracht in meinem Team ist.</li><br />
<li>Die fehlende Releaseplanung hat auch mich zunächst irritiert. Dann ist mir aber der folgende Leitsatz eingefallen: "Was braucht man, um mit Scrum beginnen zu können? - ein Ziel und ein Team!". Nicht in jedem Setting ist eine Releaseplanung sinnvoll. Außerdem ist eigentlich jeder Sprint ein Release ("potentially shippable product increment"), daher sollte man wohl eher von einer "Langfristplanung" sprechen. Diese sollte wiederum jeder PO haben - in dem Maße, in dem es für sein Team und sein Projekt/Produkt sinnvoll ist.</li></ol><br />
<br />
Es kann immer helfen, sich auch mit den <a href="http://www.incrementor.com/agilenyc/media/podcasts/agilenyc_episode28.m4a" title="Agile NYC Podcast">Hintergründen</a> einer Angelegenheit zu befassen, anstatt nur die eigenen Schlüsse zu ziehen. "Kommunikation über Dokumentation" sollte normalerweise auch bedeuten, dass ich zunächst den Verursacher meines schlechten Bauchgefühls befrage, bevor ich ein Dokument gegen ihn verfasse. Ken redet übrigens gerne über den ScrumGuide: Fragt ihn doch einfach, wenn ihr einen bestimmten Punkt diskutieren wollt.<br />
<br />
<br /><br /><img src="http://vg03.met.vgwort.de/na/b30063fd072448bfb3a1cd3792ca7784" width="1" height="1" alt=""><br />
<br />
Scrumorakel - Blognospam@example.com (Dominik Maximini)2011-08-14T08:03:28Zhttp://www.scrumorakel.de/blog/wfwcomment.php?cid=130http://www.scrumorakel.de/blog/rss.php?version=1.0&type=comments&cid=13Scrumguide 2011 erschienen
http://www.scrumorakel.de/blog/index.php?/archives/12-Scrumguide-2011-erschienen.html
Letzte Woche (eigentlich vorletzte Woche, aber der Guide wurde nochmals korrigiert) ist der neue <a href="http://www.scrum.org/scrumguides/" title="Scrumguide">Scrumguide</a> erschienen. Bemerkenswert: Jeff und Ken haben ihn gemeinsam geschrieben und unterzeichnet. Damit ist eine Brücke zwischen Scrumalliance und Scrum.org geschlagen. Allerdings ist dies bislang die einzige Verbindung zwischen den beiden Organisationen.<br />
<br />
Inhaltlich möchte ich nur auf eine Änderung im aktuellen Scrumguide eingehen: Commitment gibt es jetzt nicht mehr. Es wurde umbenannt in Forecast. Warum ist das so?<br />
Commitment war ursprünglich gemeint als "Das Team verspricht, alles in seiner Macht stehende zu tun, um das Ziel zu erreichen". Ausgelegt wurde "Commitment" aber meist als "das Team hat versprochen, das Ziel zu erreichen". Das klappt natürlich nicht - woher soll das Team vorher wissen, was es erreichen wird? Wissen können wir das nicht - nur vermuten. Alles was wir tun, ist eine Vorhersage abgeben, eine Schätzung also. Tut man das nicht und sieht Commitment als Versprechen an, so werden wieder Command and Control Strukturen eingeführt: Der PO kontrolliert dann (oft mit Hilfe des Scrum Masters), dass das Team sein Versprechen auch einhält. Das erzeugt unnötigen Druck, denn wie ihr ja wisst, denken Menschen unter Druck nicht schneller (De Marco). <br />
Ich glaube fest daran, dass ein motiviertes Team sowieso alles in seiner Macht stehende tut, um das sich selbst gesetzte Ziel zu erreichen.<br />
<br /><br /><br />
Scrumorakel - Blognospam@example.com (Dominik Maximini)2011-08-01T05:08:38Zhttp://www.scrumorakel.de/blog/wfwcomment.php?cid=120http://www.scrumorakel.de/blog/rss.php?version=1.0&type=comments&cid=12Wozu braucht Scrum das Management?
http://www.scrumorakel.de/blog/index.php?/archives/11-Wozu-braucht-Scrum-das-Management.html
Scrum definiert drei Rollen: Das Entwicklungs-Team, den Product Owner und den Scrum Master. Alle drei sind in gewissem Sinne Management-Rollen: Das Team managt sich selbst, der PO managt das Produkt und der Scrum Master den Prozess. Wofür aber brauchen wir das "reguläre" Management?<br />
<br />
Die Antwort ist einfach: Wir brauchen sie dafür, dass sie das tun, was ihre hoheitlichen Aufgaben sind. Die Entwicklung von Visionen, Zielen und Strategien. Die Gestaltung der Organisation. Und natürlich die Definition und das aktive Leben der Grundwerte im Unternehmen, insbesondere Mut, Vertrauen und Transparenz.<br />
<br />
Bei einer Scrum-Einführung gibt es drei Hauptformen: <ul><li>U-Boot-Scrum (Submarine Scrum)</li><li>Scrum von unten (Bottom-up Scrum) und</li><li>Scrum von oben (Top-Down Scrum)</li></ul>Alle drei Formen haben ihre Vor- und Nachteile, auf die ich an dieser Stelle nicht eingehen möchte. Eines ist aber sicher: Tiefgreifende Veränderungen in der Organisation wird man nur dann erreichen können, wenn das Management sich engagiert um die oben beschriebenen Aufgaben kümmert. Durchschlagenden Erfolg wird eine Scrum Implementierung nur dann haben, wenn das Management dahinter steht. Die oft versprochene Verzehnfachung der Produktivität ist nur dann überhaupt vorstellbar (geschweige denn erreichbar), wenn die Organisation von Grund auf umgekrempelt wird. Das verursacht Schmerzen. Große Schmerzen. Das Management muss diese ertragen und stillen.<br />
<br />
Achja: Nehmen Sie die Verzehnfachung nicht zu wörtlich. Es sind die absoluten Ausnahmeimplementierungen, die das erreichen.<br /><br /><br />
Scrumorakel - Blognospam@example.com (Dominik Maximini)2011-07-24T20:34:44Zhttp://www.scrumorakel.de/blog/wfwcomment.php?cid=110http://www.scrumorakel.de/blog/rss.php?version=1.0&type=comments&cid=11Warum Scrum Murks ist
http://www.scrumorakel.de/blog/index.php?/archives/10-Warum-Scrum-Murks-ist.html
Relativ häufig trifft man als Coach in deutschen Unternehmen früher oder später auf ein Team, das mit einer gewissen Häme darauf hinweist, dass "Scrum" rückwärts gelesen "Murcs" ergibt. Das passiert jedoch nicht in allen Teams. Woran liegt das?<br />
<br />
Meine Theorie ist, dass die Teams dadurch zu erkennen geben, dass in "ihrer" Scrum-Implementierung etwas nicht stimmt. In allen Fällen, die ich bislang gesehen habe, haben folgende Punkte zugetroffen:<br />
<ul><br />
<li>Das Unternehmen verwendete schon seit einer Weile einen Prozess, den es Scrum nannte. Der Zauber des Neuen, Aufregenden war verflogen.</li><br />
<li>Das Unternehmen machte kein Scrum, sondern "ScrumBut", hatte also wesentliche Bestandteile von Scrum verändert.</li><br />
<li>Schwerwiegende Impediments schwelten schon seit langem und wurden nicht gelöst. Meist aufgrund mangelnder Unterstützung durch die Mächtigen.</li><br />
<li>Die Teammitglieder waren entsprechend frustriert</li><br />
</ul><br />
Der "Murcs"-Hinweis war demnach ein Hilferuf des Teams an mich, den Scrum Master / Coach. Da wundert es nicht, dass ich den Spruch nicht mehr höre, wenn die Probleme angegangen werden und die Lethargie das Team verlässt.<br />
<br />
Motivierte Teams Murcsen nicht! - oder wie Alex Armstrong es ausgedrückt hat: "Well, if they are doing Scrum backwards, what do they expect?" <img src="http://www.scrumorakel.de/blog/templates/default/img/emoticons/smile.png" alt=":-)" style="display: inline; vertical-align: bottom;" class="emoticon" /><br />
<br />
Scrumorakel - Blognospam@example.com (Dominik Maximini)2011-07-21T17:23:34Zhttp://www.scrumorakel.de/blog/wfwcomment.php?cid=100http://www.scrumorakel.de/blog/rss.php?version=1.0&type=comments&cid=10Warum E-Mail-Kommunikation das Werk des Teufels ist
http://www.scrumorakel.de/blog/index.php?/archives/9-Warum-E-Mail-Kommunikation-das-Werk-des-Teufels-ist.html
Gelesen hat das wohl mittlerweile jeder Agilist: Face-to-Face soll man kommunizieren und nicht schriftlich oder per Mail. Aber warum eigentlich? In den letzten Tagen habe ich ein sehr interessantes Beispiel dazu erlebt:<br />
<ul><br />
<li>Ein Teammitglied von mir war in einer Besprechung mit dem Abstimmungsverfahren unzufrieden. Da die Besprechung schön timegeboxt war, konnte er sein Anliegen auch nicht mehr vorbringen.</li><br />
<li>Mit seinem Anliegen kam er zu mir, seinem ScrumMaster. Meine Antwort war: "Geh hoch und kläre das selbst mit der Person."</li><br />
<li>Mein Teammember schrieb daraufhin eine E-Mail an den Kollegen, in der sinngemäß stand: "Ich bin unzufrieden mit der Art und Weise, wie das gelaufen ist und komme gleich hoch, um das mit dir zu klären." Diese Mail war nur an den Kollegen adressiert.</li><br />
<li>Die Antwort des Kollegen kam prompt per Mail: Es gebe nichts zu klären, man könne im nächsten Meeting darüber reden. Diese E-Mail war allerdings nicht nur an den Kollegen, sondern an sämtliche Scrum-Teams adressiert. So um die 70 Leute durften also mitlesen.</li><br />
<li>Der Kollege war sauer und wollte zurückmailen. Davon konnte ich ihn abhalten. Stattdessen habe ich - entgegen meiner sonstigen Vorgehensweise - an ihn geschrieben (ein Fehler, ich hätte direkt hochgehen sollen!): "Es ist unnötig, eine Email an alle zu schreiben, wenn die Angelegenheit nur zwei Leute betrifft. Komm doch kurz runter, dann können wir das diskutieren."</li><br />
<li>Auch hier kam prompt die Antwort. Adressiert an sein Scrum-Team (immerhin...): "Es gibt nichts zu klären, regel das mit meinem ScrumMaster." - was zum Henker hat der damit zu tun?</li><br />
<li>Hier habe ich endgültig begriffen, dass E-Mails ein Fehler sind und uns nicht helfen. Im Dialog mit meinem Teammitglied haben wir entschieden, dass er hoch geht und ein Gespräch versucht. Das hat er dann auch sofort gemacht.</li><br />
<li>Ein paar Minuten später kam er wieder zurück - sauer und frustriert. Er wurde wohl als "Quertreiber" beschimpft und mit "hau ab" aus dem Büro geworfen. Auch mehrere Versuche der Gesprächsaufnahme haben hier nicht funktioniert.</li><br />
<li>Wir einigten uns darauf, die Angelegenheit zu überschlafen.</li><br />
</ul><br />
Was ist bis hierher passiert? Die Sachebene war nicht das Thema, der Konflikt kam von der Beziehungsebene. Der angemailte Kollege hatte schon die erste Mail als Angriff aufgefasst. Statt den Konflikt auszutragen, wollte er ihn umgehen - daher die abwehrende Haltung. Meine E-Mail wurde dann als "runter zitieren" empfunden, was das Gefühl des Angriffs noch weiter verstärkt hat. Wieder wurde versucht, die Angelegenheit nicht selbst zu lösen, sondern zu delegieren ("Regel das mit meinem ScrumMaster"). Der Ansatz meines Teammitglieds eine persönliche Klärung herbeizuführen wurde ebenfalls als (massiver) Angriff erlebt: Ein groß gewachsener Mann, der den Türrahmen füllt und auch nach einer klaren Aufforderung ("Hau ab!") nicht weicht, sondern sagt: "Nein, ich will das jetzt klären!". Keine Fluchtmöglichkeit. In die Ecke gedrängt.<br />
Umgekehrt hat mein Teammitglied das Verhalten des Kollegen als höchst unprofessionell und irrational erlebt. Er fühlte sich beleidigt und missverstanden - schließlich wollte er ihm nur die Hand reichen und die Angelegenheit aus der Welt schaffen. Ein Musterbeispiel von einem Konflikt.<br />
<br />
Wie ging es weiter?<br />
<ul><br />
<li>Zunächst habe ich mit dem ScrumMaster des Kollegen gesprochen. Dieser hatte bereits mit dem Kollegen geredet und wusste daher über die Gefühlswelt dort Bescheid.</li><br />
<li>Wir beschlossen, den Druck vom Kollegen zu nehmen und von uns aus keine weiteren Versuche der Klärung zu unternehmen. Gleichzeitig sollte der ScrumMaster mit dem Kollegen sprechen, ihn auf das gegenseitige Erleben der Situation hinweisen und betonen, dass alle involvierten Personen ihn sehr hoch schätzen. Auch unser Wunsch zur emotionalen Klärung des Vorfalls sollte betont werden.</li><br />
<li>Dieses Gespräch fand statt und hatte zum Ergebnis, dass der Kollege sich selbst entschloss, von sich aus das Gespräch zu suchen.</li><br />
<li>Leider erfolgte das Gespräch nicht. Die Überwindung war wohl zu groß für den Kollegen. Erst ein "Anschubsen" über den ScrumMaster führte dazu, dass das Klärungsgespräch (unter 4 Augen) wirklich statt fand.</li><br />
<li>Die Kollegen entschuldigten sich und bereinigten die Situation. Aus Sicht der Konfliktparteien ist das Problem damit gelöst.</li><br />
</ul><br />
Was habe ich daraus gelernt?<br />
<ul><br />
<li>Jede noch so gut gemeinte E-Mail ist ein Fehler, wenn es um die Beziehungsebene geht</li><br />
<li>Ich selbst sollte immer auf meine eigenen Ratschläge hören - auch wenn zur selben Zeit noch drei andere Leute etwas von mir wollen</li><br />
<li>ScrumMaster sind wichtig - gerade weil sie das Vertrauen ihrer Teammitglieder genießen und dadurch auch die Beziehungsebene gut ansprechen können</li><br />
</ul><br />
<br />
<br /><br /><img src="http://vg03.met.vgwort.de/na/f8914108b5fd4edcb3e1575ddcfea501" width="1" height="1" alt=""><br />
Scrumorakel - Blognospam@example.com (Dominik Maximini)2011-07-14T19:45:19Zhttp://www.scrumorakel.de/blog/wfwcomment.php?cid=90http://www.scrumorakel.de/blog/rss.php?version=1.0&type=comments&cid=9Das Scrumorakel-Logo
http://www.scrumorakel.de/blog/index.php?/archives/8-Das-Scrumorakel-Logo.html
Heute wurde ich gefragt, wofür das Scrumorakel-Logo steht. Das wird wohl öfters passieren - hier ist die Antwort:<br />
<br />
Angefangen hat alles mit dem Portal <a href="http://www.designenlassen.de/" title="designenlassen.de">designenlassen.de</a>. Dort kann man ein Preisgeld ausloben, sein Projekt beschreiben und sich Vorschläge für Logos, Designs, usw. machen lassen. Auf dieser Plattform habe ich mein Logo in Auftrag gegeben und innerhalb von einer Woche ca. 90 Vorschläge erhalten. Gewonnen hat dabei der Vorschlag von Michel Lapka von <a href="http://www.mldesign.jimdo.com/" title="ML Design">ML Design</a>: Er hat es geschafft, die beiden Scrum-Kreise (Symbolisch für die Iteration und das Daily Scrum) stilistisch zu integrieren. Gleichzeitig ist es ihm gelungen, diese Scrum-Kreise so anzuordnen, dass mit etwas Phantasie ein "S" erkennbar ist. Begrenzt wird dieses "S" durch ein "O" - einen runden Kreis um das Ganze. Das Orakel "umfasst" also die Gesamtheit von Scrum. Gleichzeitig sind die Formen einfach, ansprechend und einprägsam. Der Metallic-Look und die klaren Linien machen das Ganze in gewisser Weise "edel". Auch wenn ein Orakel als solches nicht seriös ist, so ist es das Logo für sich genommen durchaus.<br />
<br />
Ich gebe zu, dass diese Interpretationen dem normalen Betrachter nicht sofort eingängig sein werden. Er wird vermutlich nichtmal auf die Idee kommen, dass das Logo eng mit Scrum und dem Orakel verwoben ist. Ist aber so. <img src="http://www.scrumorakel.de/blog/templates/default/img/emoticons/smile.png" alt=":-)" style="display: inline; vertical-align: bottom;" class="emoticon" /><br />
<br />
Die Idee mit den verschiedenen Metallen für die verschiedenen Fragen kam mir, da einem Orakel in der Antike Opfergaben dargebracht wurden. Je größer die Opfergabe, desto schwierigere Fragen konnten gestellt werden. Für ein paar "Silbermünzen" gab es also weniger, als für pures "Gold". Daran habe ich mich angelehnt. Allerdings bemühe ich mich, nicht so verschwommen und in Trance zu antworten, wie es die Pythia (das Orakel im alten Griechenland) tat. Trotzdem bleibt natürlich die Pflicht für den Fragesteller, meine Antwort in den Kontext des jeweiligen Problemfalls einzuordnen und zu bewerten.<br />
<br />
Scrumorakel - Blognospam@example.com (Dominik Maximini)2011-07-11T17:02:20Zhttp://www.scrumorakel.de/blog/wfwcomment.php?cid=80http://www.scrumorakel.de/blog/rss.php?version=1.0&type=comments&cid=8Scrum in der Politik?
http://www.scrumorakel.de/blog/index.php?/archives/7-Scrum-in-der-Politik.html
Wir wissen, dass Scrum in der Softwareentwicklung funktioniert. Kein Wunder - dafür wurde es entwickelt. Wir wissen außerdem, dass es als Instrument zur Organisationsentwicklung eingesetzt werden kann. Elemente daraus können auch für die Hardwareentwicklung und andere Situationen des betrieblichen Alltags genutzt werden. Scrum hinterlässt auch im privaten Umfeld seine Spuren: Wer die Prinzipien verinnerlicht hat, betreibt ständig "Inspect & Adapt", sorgt für Transparenz und fokussiert sich immer auf das Wichtigste. Bei dem ein- oder anderen hängt vielleicht sogar ein Backlog an der Wand...<br />
<br />
Was ist mit der Politik? Auch dort müssen Themenfelder ausgewählt, "User Stories" (Gesetze, Eingaben, Petitionen, ...) mit dem höchsten Wert entwickelt und jedes "Release" (zur Wahl) fertige "Produkte" geliefert werden. Transparenz, Offenheit und Mut sind leider kaum erkennbar. Unsere aktuelle Regierung hat nichtmal "Fokus" zu bieten. Ein zielloses rumgeschubst-werden durch die "Stakeholder" ist an der Tagesordnung. "Inspect & Adapt" findet praktisch nicht statt - die gleichen Fehler werden immer wieder gemacht. Klingt eigentlich, wie die meisten Projekte, in denen ich unterstütze.<br />
<br />
Wie könnte Scrum in der Politik aussehen?<br />
Zunächst einmal stellen die Abgeordneten oder Parteimitglieder die Teams dar. Sie müssen schuften. Sehr gut: Endlich ein paar Pigs in der Politik <img src="http://www.scrumorakel.de/blog/templates/default/img/emoticons/smile.png" alt=":-)" style="display: inline; vertical-align: bottom;" class="emoticon" /><br />
Die Minister und Parteivorstände könnte man als Product Owner betrachten. Sie geben die Richtung vor und entscheiden letztendlich, was auf die Tagesordnung kommt. Die Parteiprogramme (und Koalitionsverträge) könnte man als "Product Backlog" betrachten. Hier steht alles drin, was die POs erreichen wollen. Gestaltet werden sollten diese durch die Stakeholder - also uns, die Wähler. Da wir nur "fertige Produkte" ausliefern dürfen, sollte es für jedes Team eine "Definition of Done" geben. Neben den rechtlichen Aspekten könnte man dort z.B. auch einen Punkt "Wählermeinung abfragen" einbringen. Mit den heutigen modernen Kommunikationsinstrumenten sollte das zu vertretbaren Kosten umsetzbar sein. Natürlich muss dazu die Visibilität quer durch die Republik sehr hoch sein. Der Acceptance-Test ist dann die Abstimmung im Parlament (oder auf dem Parteitag). Lediglich den ScrumMaster vermisse ich noch. Wer sorgt für die Prozesseinhaltung? Wer moderiert und fokussiert die Beteiligten? Ich fürchte, dafür gibt es noch keine Entsprechung in der aktuellen Politik - bitter nötig wäre sie aber. Endlich einer, der weder Macht- noch inhaltliche Interessen verfolgt, sondern nur die Gesamtproduktivität und das persönliche Wohlergehen der Beteiligten im Sinn hat. Hach, wäre das schön!<br />
<br />
In den alten, verkrusteten Parteien scheint mir ein so radikaler Ansatz nicht umsetzbar. Selbst die Grünen sind schon korrumpiert. Was bleibt, sind die Piraten (trotz des marketingtechnisch verheerenden Namens). Ich denke, ich sollte mal mit denen reden: Steuerbordbatterien klar, hart anbrassen, drei Strich nach Lee abfallen - diese Breitseite könnte etwas verändern.<br />
<br /><br /><img src="http://vg03.met.vgwort.de/na/6ebf692414144436b7c2e237943d2268" width="1" height="1" alt=""><br />
Scrumorakel - Blognospam@example.com (Dominik Maximini)2011-07-08T19:19:29Zhttp://www.scrumorakel.de/blog/wfwcomment.php?cid=70http://www.scrumorakel.de/blog/rss.php?version=1.0&type=comments&cid=7Der Weg der Scrum.org
http://www.scrumorakel.de/blog/index.php?/archives/6-Der-Weg-der-Scrum.org.html
Gerade komme ich vom 2. ScrumTisch Stuttgart zurück. Ken Schwaber war auch da und hat uns ein paar interessante Einblicke in die aktuellen Entwicklungen der Scrum.org gewährt. Der ScrumGuide wird beispielsweise überarbeitet: Einige Missverständnisse werden ausgeräumt, einigen Fehlentwicklungen wird vorgebeugt. Zum Beispiel wird endlich die Sektion "Artefakte" korrigiert - bislang steht dort das Burndown Chart als Artefakt, jedoch nicht das Product Increment. Aus meiner Sicht der größte Fehler im ScrumGuide. <img src="http://www.scrumorakel.de/blog/templates/default/img/emoticons/smile.png" alt=":-)" style="display: inline; vertical-align: bottom;" class="emoticon" /><br />
<br />
Auch arbeitet Ken an einem neuen Buch. Bislang habe ich nur die Einleitung lesen können, diese klingt aber vielversprechend. Ich berichte mehr, wenn ich das ganze Werk kenne (was voraus setzt, dass es fertig ist).<br />
<br />
Scrumorakel - Blognospam@example.com (Dominik Maximini)2011-07-04T20:06:56Zhttp://www.scrumorakel.de/blog/wfwcomment.php?cid=60http://www.scrumorakel.de/blog/rss.php?version=1.0&type=comments&cid=6Das Warten auf den Manager
http://www.scrumorakel.de/blog/index.php?/archives/5-Das-Warten-auf-den-Manager.html
Manchmal gibt es Teammitglieder, die über die Jahre gelernt haben, sich der "Obrigkeit" unterzuordnen. Diese Kollegen warten dann darauf, dass der "Manager" ihnen sagt, was sie tun sollen. Dieses Phänomen kenne ich zum Beispiel aus Daily Scrums: Ist jemand anwesend, den das Team als "Manager" ansieht, so wird geschwiegen - der Manager könnte ja was sagen wollen. Wie durch ein Wunder fällt diese Hemmung unmittelbar, wenn die Manager-Persönlichkeit nicht mehr im Raum ist. Plötzlich sprudelt es nur so. Das geht natürlich nur, wenn das Team schon weiß, wie Scrum funktioniert.<br />
<br />
Problematisch ist, dass auch Personen als "Manager" angesehen werden können, die sich selbst nicht so sehen. Das kann der ScrumMaster sein, der Product Owner oder auch ein Senior Entwickler.<br /><br />
Scrumorakel - Blognospam@example.com (Dominik Maximini)2011-06-28T05:06:58Zhttp://www.scrumorakel.de/blog/wfwcomment.php?cid=50http://www.scrumorakel.de/blog/rss.php?version=1.0&type=comments&cid=5Blog online
http://www.scrumorakel.de/blog/index.php?/archives/4-Blog-online.html
Der Blog ist jetzt in Version 1.0 "done". Was genau bedeutet dieses "done" für diesen Blog? Ein kleiner Ausflug in die Welt der "Definition of Dones"<br />
<ul><br />
<li>Alle sichtbaren Funktionen funktionieren</li><br />
<li>Das Aussehen des Blogs ist akzeptabel</li><br />
<li>Die Seite wurde auf verschiedenen Rechnern von verschiedenen Personen getestet.</li><br />
<li>Alle Hygienefaktoren sind erfüllt (oder anders ausgedrückt: Wer einmal hier war hat keinen Grund, nicht wieder zu kommen)</li><br />
<li>Die Seite ist unter der vorgesehenen URL erreichbar</li><br />
</ul><br />
Diese DoD hat zwei Schwachstellen: Zum einen ist strittig, ob Links auf andere Subseiten "sichtbare Funktionen" sind, zum anderen sind die Testsysteme nicht eindeutig definiert. Wie immer gilt: Kommunikation ist wichtiger als Dokumentation. Mein Team muss also mit mir als PO sprechen um festzustellen, ob alle Kriterien erfüllt sind. Ist dies einmal geschehen, sollte im Allgemeinen Klarheit über die Bedeutung der einzelnen Kriterien bestehen. Trotzdem wird jeder Sprint seine eigenen Tücken mit sich bringen.<br /><br />
Scrumorakel - Blognospam@example.com (Dominik Maximini)2011-06-23T16:48:44Zhttp://www.scrumorakel.de/blog/wfwcomment.php?cid=40http://www.scrumorakel.de/blog/rss.php?version=1.0&type=comments&cid=4Veränderungen in der Wirtschaft
http://www.scrumorakel.de/blog/index.php?/archives/3-Veraenderungen-in-der-Wirtschaft.html
Die letzten beiden Abende habe ich mit Jeff Sutherland verbracht. Einige seiner Ansichten möchte ich mit euch teilen: <br />
<ol> <br />
<li>Seiner Beobachtung nach kommen so gut wie alle neuen Jobs in den USA von Unternehmen, die in den letzten 5 Jahren gegründet wurden. Ältere Unternehmen stagnieren oder werfen Leute raus. Das bedeutet, dass auch die Innovationen von diesen Neugründungen kommen, während die "Alten" nur ihre Cash-Cows melken.</li> <br />
<li>Durch die Fokussierung auf's Testen kann ein Unternehmen seine Produktivität mindestens verdoppeln.</li> <br />
<li>Ein Unternehmen, das keine Fokussierung aufs Testen (z.B. durch Scrum) hat, wird innerhalb kürzester Zeit zu denen gehören, die kleiner werden. Jedenfalls nicht zu den Gewinnern.</li> <br />
</ol> <br />
Sehr interessant war auch seine Angabe, dass das gesamte amerikanische Militär aktuell sämtliche Softwareprojekte auf Scrum umstellt bzw. umstellen wird. In Deutschland aktuell noch nicht vorstellbar.<br /><br />
Neben Scrum habe ich mich mit ihm auch über Politik, Wirtschaft und anderes unterhalten. Besonders spannend: In dem Innovationskomplex, in dem er arbeitet, beschäftigen sich ca. 1/3 der Startups mit erneuerbaren Energien. Angenommen diese Zahl wäre auf die gesamten USA anwendbar, dann wären dort immense Innovationen im Busch. Vorausgesetzt, die Regierung fördert diese Innovationen, könnten die USA neben Deutschland und China zum dritten Big Player im Solarbereich und bei anderen erneuerbaren Energien werden. Ich freue mich schon auf die Zukunft - Neuerungen in diesem Bereich begrüße ich sehr.<br /><br />
Scrumorakel - Blognospam@example.com (Dominik Maximini)2011-06-10T19:43:44Zhttp://www.scrumorakel.de/blog/wfwcomment.php?cid=30http://www.scrumorakel.de/blog/rss.php?version=1.0&type=comments&cid=3Wie wird man ein guter ScrumMaster?
http://www.scrumorakel.de/blog/index.php?/archives/2-Wie-wird-man-ein-guter-ScrumMaster.html
Meine Meinung über Zertifizierungen habe ich euch in meinem letzten Blogeintrag mitgeteilt. Wenn aber eine Zertifizierung als Solche nicht wirklich hilft, ein guter ScrumMaster zu werden - was kann der Einzelne dann tun? Meine Meinung dazu ist:<br />
<br />
<br />
<ul> <br />
<li>Anfangen. Nur wer mit beiden Beinen in der Praxis steht, kann begreifen, warum und wie Scrum funktioniert.</li> <br />
<li>Aus den (eigenen) Fehlern lernen (inspect and adapt). Wer anfängt macht Fehler. Kein Problem - aber lernt daraus. Reflektiert regelmäßig über euch selbst und hinterfragt insbesondere bei jedem Item, das in der Retrospektive aufkommt, ob ihr das hättet verhindern können oder ob ihr dazu beigetragen habt, dass es zu einem Impediment wurde. Wie gesagt: Das ist kein Problem, aber lernt daraus.</li> <br />
<li>Macht ein Training. Zum einen lernt ihr dort von einem Profi, wie Scrum funktioniert. Zum anderen könnt ihr dort wichtige Kontakte knüpfen.</li> <br />
<li>Tauscht euch regelmäßig mit anderen Scrum-Anwendern aus. Egal ob in UserGroups, ScrumTischen, bei einem Bier mit Freunden oder in einer Community of Practice in eurem Unternehmen - sucht den Austausch. Wenn es sowas in eurer Nähe nicht gibt, baut selbst etwas auf.</li> <br />
<li>Lest viel. Zwar macht euch das Lesen allein nicht zu Profis, aber ihr erweitert dadurch euren Horizont, was wiederum in konkreten Situationen Ideen gibt, die man sonst nicht gehabt hätte. Bücher, Blogs und Foren sollten dabei in dieser Priorität konsumiert werden.</li> <br />
<li>Bildet euch auch fernab von Scrum fort. Managementpraktiken, Psychologie, Moderation, Mediation, Kreativitätstechniken, Soziologie usw. sind mindestens genauso wichtig wie das harte Scrum-Wissen.</li> <br />
<li>Nutzt jede Gelegenheit, um das Gelernte anzuwenden. Ihr plant ein privates Projekt? Gut - warum nicht mit einem Backlog und Iterationen? Eure Freundin kann sich nicht entscheiden, wohin sie in den Urlaub fahren will? Übernehmt doch die Rolle des POs und kitzelt die relevanten Kriterien sowie deren Ausprägung hervor. Euer privates Projekt ist beendet? Wie ist es denn gelaufen und was könnt ihr für die Zukunft daraus lernen?</li> <br />
<li>Holt euch Hilfe. Genau wie euer Team sich Experten ins Boot holen muss, wenn es nicht weiter kommt, so müsst auch ihr das tun. Niemand kann in allen Bereichen perfekt sein - auch ihr nicht. Sucht euch jemanden, der in genau dem Gebiet, in dem ihr das Problem habt, Profi ist (Psychologie? Prozess? Organisationsentwicklung? ...?) und lernt soviel von dieser Person wie möglich. Vielleicht könnt ihr es dann beim nächsten Mal auch ohne Hilfe lösen.</li> <br />
</ul><br />
<br />
Habe ich etwas vergessen oder liege ich falsch? Über eure Meinungen freue ich mich sehr.<br /><br /><img src="http://vg03.met.vgwort.de/na/9e4d0a7bec1d469e9ac7065eed07df24" width="1" height="1" alt="">
Scrumorakel - Blognospam@example.com (Dominik Maximini)2011-06-05T11:53:37Zhttp://www.scrumorakel.de/blog/wfwcomment.php?cid=20http://www.scrumorakel.de/blog/rss.php?version=1.0&type=comments&cid=2Was sagen Zertifizierungen aus?
http://www.scrumorakel.de/blog/index.php?/archives/1-Was-sagen-Zertifizierungen-aus.html
Immer wieder werde ich von Scrum-Anwendern gefragt, welche Scrum-Zertifizierung denn "die richtige" sei. Um diese Frage ausführlich zu erörtern, habe ich den Blogbeitrag geschrieben, den Sie gerade lesen.<br />
<br />
1) Man braucht keine Zertifizierung, um ein Thema zu beherrschen. Fähigkeiten belegt ein Zertifikat selten, sondern immer nur den durch das Zertifikat abgeprüften Kenntnisstand zum Zeitpunkt des Erwerbs. Nur weil also jemand ein Zertifikat mitbringt heißt das noch lange nicht, dass er für die vor ihm liegende Aufgabe geeignet ist. Man denke nur an sein eigenes Diplom, das Abiturzeugnis oder die Führerscheinprüfung: Würden Sie heute noch alle Fragen beantworten können, die Sie damals erfolgreich beantwortet haben? Wieviel hat Ihnen Ihr Studium für den Berufsstart geholfen? Bei mir konnte ich schätzungsweise 10% des Erlernten anwenden - den Rest hat mir erst der Job selbst vermittelt...<br />
<br />
2) Es gibt drei mir bekannte weltweite Organisationen, deren Scrum-Zertifikate erwähnenswert sind: PMI, Scrumalliance und Scrum.org<br />
2.1) Das <a href="http://www.pmi.org/Certification/New-PMI-Agile-Certification/PMI-Agile-Certification-Pilot-Program.aspx" title="http://www.pmi.org/Certification/New-PMI-Agile-Certification/PMI-Agile-Certification-Pilot-Program.aspx">PMI-Agile</a> Zertifikat läuft derzeit in der Pilotphase. Diese wird - laut Webseite - im November abgeschlossen sein. Daher ist eine Aussage über die Qualität der Zertifizierung derzeit noch nicht möglich (zumal ich selbst die Prüfung nicht abgelegt habe). Bemerkenswert ist jedoch, dass ein Kandidat 2.000 Stunden "General Project Management Experience" nachweisen muss. Meiner Erfahrung nach ist ein guter "klassischer" Projektmanager aber noch lang kein guter ScrumMaster oder Product Owner.<br />
2.2) Die <a href="http://scrumalliance.org/pages/scrum_certification" title="http://scrumalliance.org/pages/scrum_certification">Scrumalliance</a> zertifiziert die Teilnahme an ihren Kursen. Die Zertifikate bedeuten genau das: Jemand hat den dazugehörigen Kurs besucht. Zwar gibt es (zumindest beim Certified Scrum Master-Kurs) auch einen Multiple-Choice-Test. Dieser ist jedoch sehr einfach und es spielt keine Rolle, wie viele Fragen man richtig oder falsch beantwortet. Das Zertifikat gibt es trotzdem. Ich habe mir den Spaß gemacht und die Prüfung durchgespielt. Besonders hat mich dabei beeindruckt, dass man nach Beantwortung der Fragen sofort angezeigt bekommt, ob man richtig oder falsch lag und für weiterführende Studien auf Quellen verwiesen wird, die allesamt nicht bei der scrumalliance liegen: Scrum.org, Mountain Goat Software, usw. Die Prüfung kann man normalerweise nur dann machen, wenn man einen CSM-Kurs besucht hat.<br />
2.3) Bei der <a href="http://www.scrum.org/assessments/" title="http://www.scrum.org/assessments/">Scrum.org</a> muss man richtig schwitzen. Die Prüfungen dort sind schwer bis sehr schwer und werden ebenfalls online abgelegt. Um ein "Professional Scrum Master I" zu werden, muss man keinen Kurs besucht haben (gilt nur für die ScrumMaster-Laufbahn, für PO und Teammitglieder sind die Kurse verpflichtend), sondern kann für 100 $ pro Versuch loslegen. 80 Multiple-Choice-Fragen und eine Stunde stehen dann zwischen dem Prüfling und dem Zertifikat. Um zu bestehen, muss man 85% der Punkte erreichen. Will man später Trainer werden, müssen es mindestens 95% sein. Etwa 80% der Prüflinge sind erfolgreich, der Rest fällt durch.<br />
Hat man die PSM I-Zertifizierung erhalten, darf man sich am PSM II versuchen. Die kostet 500 $ (300 $ für alle, die einen PSM-Kurs besucht haben) pro Versuch, dauert 2 Stunden und besteht aus Multiple-Choice und Essay-Fragen. Auch hier hat man mit 85% bestanden (95% für die Trainer-Laufbahn). Bisher (Stand heute) haben 59 Personen weltweit diese Zertifizierung erhalten. Einige davon nicht im ersten Anlauf. Die Hauptschwierigkeit ist hier, genau zu verstehen, was die Scrum.org von einem wissen will. Manchmal muss man zwischen den Zeilen lesen. Auch unschön ist, dass man (zumindest beim PSM I) hinterher nicht erfährt, welche Fragen man falsch beantwortet hat. So ist es schwierig, sich exakt auf die Prüfung vorzubereiten. Auswendiglernen oder präzises "Fragen lernen" geht also nicht. Im Gegensatz zu PMI und Scrumalliance muss man seine Zertifizierung nicht alle 2 Jahre erneuern. Es entstehen also nur Einmalkosten.<br />
<br />
3) Welches Zertifikat für wen? Zunächst ein paar allgemeine Hinweise: Wer ein Zertifikat haben möchte, sollte sich gut überlegen, was er damit "beweisen" will. Geht es ihm darum, die Anwesenheit in einem Kurs zu belegen, bieten alle Anbieter gute Möglichkeiten. Hat der Kandidat bereits eine PMI-Zertifizierung, könnte sich das "PMI Agile" lohnen. Soll Fachkenntnis nachgewiesen werden (zumindest zum Zeitpunkt X des Zertifikats), dann ist aktuell nur die Scrum.org eine Alternative. Hier hilft es auch, dass jeder die Prüfungen machen kann und 100$ noch tragbar sind.<br />
3.1) Teammitglieder (Coder, Tester, usw.): In der Regel sind hier fachliche Qualifikationen viel wichtiger, als Prozesswissen. Es ist also fraglich, ob überhaupt eine Scrumzertifizierung nötig ist. Falls ja bieten die Scrumalliance und die Scrum.org entsprechende Kurse mit Zertifikat an. Bei der Scrum.org ist dabei das Programm (auch für die anderen Kurse) "streamlined", also weltweit überall gleich, dauert dafür aber auch 5 Tage. Sowohl die Scrum.org als auch die Scrumalliance vermitteln fachliche Fähigkeiten und Scrumwissen.<br />
3.2) Product Owner: Ein ScrumMaster-Kurs ist eigentlich ungeeignet, da die Aufgabe des POs der Return on Invest (ROI) und nicht der Scrum-Flow ist. Daher ist eher ein PO-Kurs zu empfehlen - mit den dazu gehörigen Zertifikaten. PMI scheidet hier aus.<br />
3.3) ScrumMaster: Wer schon Erfahrungen hat und glaubt, eine Prüfung bestehen zu können, der ist bei der Scrum.org gut aufgehoben. Wer keine Prüfung ablegen möchte, sollte sich eher Richtung Scrumalliance orientieren. IMHO ist das PSM II derzeit das einzige Zertifikat am Markt, mit dem man als ScrumMaster ein Alleinstellungsmerkmal erzielt.<br />
<br />
Nach wie vor glaube ich nicht, dass man ein Zertifikat braucht, um ein guter ScrumMaster zu sein. Auch glaube ich nicht, dass ein Zertifikat viel "beweist". Trotzdem ist es ein tolles Gefühl, eines zu haben <img src="http://www.scrumorakel.de/blog/templates/default/img/emoticons/wink.png" alt=";-)" style="display: inline; vertical-align: bottom;" class="emoticon" /><br /><br /><img src="http://vg03.met.vgwort.de/na/6b5a64d44cc241c9a1f5e0ee1eb0882d" width="1" height="1" alt="">
Scrumorakel - Blognospam@example.com (Dominik Maximini)2011-06-02T15:52:03Zhttp://www.scrumorakel.de/blog/wfwcomment.php?cid=11http://www.scrumorakel.de/blog/rss.php?version=1.0&type=comments&cid=1