Skip to content

Feed aggregator

How Timelines Help Project Managers Track Progress

TargetProcess - Edge of Chaos Blog - Thu, 04/10/2014 - 21:32

… no matter if it’s agile, Scrum, Kanban, SAFe, lean, XP or some mix of these methodologies.

Project managers want to track progress in any software development project, small or large. Sometimes they want to track progress not only in one, but in many projects at a time, and they want to be able to do this fast and conveniently. A timeline is a a visual management tool that helps accomplish this. Let’s take a closer look in which way.

Regardless of the software development methodology used, projects are meant to be completed. Always. However, at times project managers feel tied to by-the-book canons of Kanban (which is viewed by many as the best visual management system there is, but allows no time-boxing), or of Scrum (which has time-boxed iterations and releases but falls short with the visual part).  What if a project manager wants to get the best both of Kanban, as a visual board, and of Scrum? Obviously, if  projects have deadlines, one can not live by the classical pull and flow formula of Kanban only.

For progress tracking, Scrum allows only one visual report, called the burn down chart. When we want to keep an eye only on one project, such a report would probably be enough:

burn down chart

However, if many projects need a watchful eye of this one person, squeezing many burn down charts on one screen will not make the job any easier. Imagine how hard it would be to make sense of those charts arranged in a grid-like fashion. A project manager will likely want to see how projects correlate with each other, as it might be that the timing in one project affects the other projects. In this case, it would be sensible to drift away from the prescribed tool set of Scrum, and venture into the unknown land, fearlessly mixing sense of time (Scrum) with a neat visual representation (Kanban).  That’s how this stylized mix looks as a timeline view for 2 projects (click to enlarge):

Timelines tracking for many projects

Work items in several projects on a timeline in Targetprocess 3

Such a visualization will fit a dozen projects into one screen, showing a project manager how all of them correlate with each other. This timeline has something more in store, than merely registering projects’ health in terms of time. Unlike in the burn down chart, one will be able to zoom in on any work item in any project and see what’s going on. This timeline bears a certain resemblance to Kanban board, because bugs, user stories and features are presented as cards stretched over time. At the same time, as in Scrum, the forecast will update depending on velocity (if one needs it done that way), and the timeline will show the latest status. If a project manager is in charge of several teams, that do several projects, this timeline will show when one can expect these projects to be completed:

Timeline-by-Team

A teams/projects timeline in Targetprocess3

A yet another snapshot of tracking progress with timeline. Here we have Features and User Stories (as in Scrum):Features visualized on a timeline in Targetprocess 3

User Stories inside Features on a timeline in Targetprocess 3

When someone pledges allegiance to Scrum, timelines offer a way to track progress with many iterations. Same for many releases, as opposed to clicking through single release and iteration plans one by one.
Track User Stories by Iteration on timeline in Targetprocess 3

Tracking progress/status for several iterations on a timeline in Targetprocess 3

As we can see, it pays off when we forget about practices that seem to be rigidly prescribed by a methodology. A methodology is nothing, unless it works for our purposes, and helps us do the work better and faster. These timelines can not be, scholastically, classified as belonging solely to Scrum as a method, or to Kanban. While classical Scrum only offers burn down charts for progress tracking, this is not enough when people work with many projects and want to keep their hand on the pulse of all of them. Classical Kanban, in its turn, allows no time tracking as a methodology (and as a visual board). I’m not even sure if what they call “Scrumban” would accommodate this representation with timelines. Frankly, I don’t care how it’s called. I only care if it works for project managers or product owners, or any other folks in charge of projects, and helps them do their work well. And I wish that people were more of a freethinkers, unpinning themselves from the methodology labels.

Care to take a look where one can afford being a freethinker and still work as a project manager? With no strings attached to Kanban, or Scrum, sticking only to common sense and convenience of work? It’s here.

Related articles:

How Visualize: Board, List or Timeline?

Why Visualize?

Categories: Companies

Without Simplicity, There Is no Agility

Scrum Expert - Thu, 04/10/2014 - 16:15
Rich Hickey has stated “The simpler solution is going to kick your butt”, Russ Miles would go further, “The simpler solution is already kicking your butt; no one is more agile than the teams developing with simplicity in mind”. But what makes a complex solution and why is its complexity such a confining force on your ability to be agile and respond to market needs? In this talk Russ Miles, principal consultant at Simplicity Itself, will share the hard lessons learned while designing a real world application that, through applying practical ...
Categories: Communities

Agilia, Budapest, Hungary, June 11-13 2014

Scrum Expert - Thu, 04/10/2014 - 15:59
Agilia is a three-day conference focused on Agile software development. The theme of this edition is the role of product owner and product management in Agile: creating vision, designing product, managing teams, role of Product Owner, engagement of customers and users, creativity and management of innovations. Use cases. In the agenda up you can find topics like “Gamified Retrospective – how to use it to become product/customer-centric team and improve communication with Product Owner?”, “Setting a Good Example: Improving your SBE, BDD and ATDD artefacts”, “The Product Owner’s Work With Specifications”, ...
Categories: Communities

12 Tips for Product Owners who want better performance from their Scrum Teams

Scrum Breakfast - Thu, 04/10/2014 - 12:16
As Product Owner, I want better performance from my Scrum team.

Jeff Sutherland observed that teams in the 95th percentile were 10 times more productive than average teams (50th percentile). He created Scrum to enable all teams to recreate those conditions that enable top performance.

How do you really get better performance from your Scrum team? It’s not about cracking the whip. That is usually counterproductive. It’s about creating the right conditions. In my Product Owner course, we look at the many tools available to Product Owner to enable better and quicker results from the development teams. On the saat-network company site, I have posted 12 tips (well, 13 actually) for how Product Owners can improve Scrum Team performance. Read the whole article...
Categories: Blogs

Köstlichkeiten und Kostenloses im Alltag eines Unternehmensberaters

Scrum 4 You - Thu, 04/10/2014 - 07:34

Es ist Donnerstag. Böse Zungen sagen auch gerne mal Beraterfreitag. Aber das perlt ab.
Ich habe eingecheckt und befinde mich im Abflugterminal des Flughafens. In dieser speziellen Ausgabe von Flughafen hat sich ein besonders schlauer Fuchs gedacht, es sei geschickt, die kleinen gelben Automaten, an denen man Gefrierbeutel für den sicheren Transport 10x100ml hochexplosiver Flüssigkeiten erwerben kann, 20 Meter hinter der Taschen- und Personenkontrolle aufzustellen. Dann können die Passagiere die Flüssigkeiten, die sie vor dem Sicherheitscheck schon längst entsorgen mussten, endlich in die Plastiktüten packen. Toll!

Mein Tag verlief so lala – der Kunde wusste es mal wieder besser als ich und stellte mich dann gleich noch zusammen mit „dieser ganzen Beraterbande“ grundsätzlich in Frage. Widerstand zwecklos. Definitiv Grund genug, sich mit dem Gedanken an ein kühles Bier anzufreunden. Ich überschlage kurz das verbleibende Reisebudget und stelle fest, dass ich bei Verzehr eines Flughafenbieres wohl noch 4,50 Euro drauflegen müsste, da ich ja bereits heute morgen unbedingt das S-Bahnhof-Ciabatta und den korrespondierenden Kaffee beanspruchen musste. Mittags musste es dann selbstverständlich auch das Mittagsmenü der örtlichen Crossover-Kitchen sein, weil der Kollege, mit dem dieses eine superwichtige Thema besprochen werden wollte, eben dort schon einen Tisch reserviert hatte. Und das im schwäbischen Teil Baden Württembergs – also keine Chance, eingeladen zu werden.

Zurück ins Jetzt. Ich könnte natürlich auf ein kleineres Bier ausweichen…Naääh komm, das würde den Literpreis schlagartig dreistellig werden lassen. Außerdem ist heute Beraterfreitag. Ich entscheide mich für den halben Liter Weißbier vom Fass. Hmmm, wie es so schön in der Abendsonne schimmert, die hinter der Landebahn untergeht. Ich mache noch schnell ein Foto mit meinem inneren Auge und reiße sogleich der Bedienung den Kelch aus der Hand. Dabei verschütte ich etwas von dem kostbaren Gut auf den bereits klebrigen Tresen. Bin wohl nicht der erste halbverdurstete Hobbybierologe heute.

Da vorne am Fenster ist noch ein Plätzchen frei. Ich setze mich und hole meinen Laptop raus. Es ist noch etwas Zeit und ich überlege, einen kleinen Beitrag für unseren Blog zu schreiben. Thema: such dir was aus. Na gut, schreib ich halt was über Leute am Flughafen. Ha! Direkt neben mir hat jemand sein Bier nicht ausgetrunken. Das ist ja noch dreieurofünfzig voll! Also entweder, es war ihm wirklich egal, oder demjenigen ist wieder eingefallen, dass es ein Flughafen mit angeschlossener Kneipe ist und nicht umgekehrt. Oder ihr? Gibt es Frauen, die am Flughafen einen halben Liter Weißbier bestellen und dann die Hälfte zurücklassen? Unwahrscheinlich. Derart leichtsinnig sind doch bestimmt nur Menschen die es gewohnt sind, von einer Sekunde zur maximal übernächsten zu denken (das Bier im 30 Minuten später startenden Flugzeug ist kostenlos!).

Ein paar Meter weiter, eine Tafel: „Jede Pizza nur 10 Euro!!“ Wow, ich bin kurz davor zu Hause Bescheid zu sagen, dass ich im Begriff bin, das Schnäppchen der Woche zu schlagen und zu fragen, ob ich vielleicht noch eine zweite mitbringen soll. Ich schaue mich um, um zu sehen, ob sich dieser Anbieter eventuell in einem erbitterten Preiskampf mit unzähligen weiteren Pizzabäckern befindet. Natürlich nicht. „Do people at the airport know what the prices are at any other place in the world?“, fragte einst der amerikanische Comedian Jerry Seinfeld. Nun ja, ich habe vor ein paar Minuten ein Bier für 6,90 Euro gekauft – bin also Teil des Problems. Der randvollen Auslage nach zu urteilen hat die Pizza heute auch schon einmal 15 Euro gekostet und nun wird voller Enthusiasmus diese Wahnsinnsreduktion beworben. Ausgang ungewiss.

Gegenüber steht das Regal mit dem Zeitschriftenangebot der Airline. Eine Ausgabe des PLAYBOY mit jugendfreiem Einband – zu sehen ist das Bild einer verlassenen Karibikinsel in Häschenkopfform aus der Vogelperspektive – liegt dort aus. Und, was ist das? Ein Mittvierziger mit seinem maximal 10-jährigen Spross geht schnurstracks darauf zu, lenkt den Jüngsten noch kurz mit einer SportBild, auf deren Cover Manuel Neuer gerade irgendwen anbrüllt ab, um dann beherzt ins obere Regal zu greifen. Bold move, daddy! Was wohl Mama dazu sagen würde? Kriegt sie ja nicht mit. Und wenn doch, wird auch er behaupten, es ginge ihm lediglich um die super Reportagen.

Oh, der Flug wird aufgerufen. Für’s Priority Boarding habe ich noch nicht genügend Meilen – Anfänger! Aber ich habe noch etwas Zeit, um den Passagieren bei ihrer besten Engländer-Imitation zuzusehen und die restlichen 2,90 Euro auszutrinken. Nicht dass sich am Ende jemand über mein halb volles (!!) Glas lustig macht. Wie sie sich alle brav anstellen, obwohl sie doch noch laaaange nicht dran sind. Vielleicht sollte ich mal hingehen und darauf aufmerksam machen, dass sich die Sitzplatznummern auch in den verbleibenden 30 Minuten nicht mehr ändern werden. Und „ja, Sie werden mit sehr sehr großer Wahrscheinlichkeit der erste auf dem ausschließlich für Sie reservierten Platz sein“. Mich beschleicht der Verdacht, es könnte sich um traumatisierte Bahnkunden handeln, die auch Angst davor haben, nachts aus ihren Betten geschmissen zu werden, weil sie das „ggf. freigeben“-Schild einfach ignoriert haben. Ich beobachte das Schauspiel noch eine Weile und verpasse um ein Haar noch meine Boarding-Gruppe.

Im Flugzeug komme ich mit meinem Sitznachbarn ins Gespräch. Er erzählt mir davon, wie er aufgrund seiner Leibesfülle schonmal aus den komfortablen Sitzen vor den Notausgängen komplimentiert wurde. „Jaja, Alte, Kinder und Dicke haben keine Chance“, sagt er. Und ich weiß in dieser Situation nicht, wer mir mehr Leid tut: dieser arme Kerl, dem seine stattliche Physis so deutlich vor Augen geführt wurde, oder ich, der auf einmal mit der Hälfte des bezahlten Sitzplatzes auskommen muss. Ich versuche trotzdem, es mir ein bisschen bequem zu machen. Über die Lautsprecher hauchen Simply Red: „I wanna fall from the stars“ in die Kabine. Bei dem Gedanken an den Marketingmitarbeiter mit dem Einfühlvermögen einer Tiefkühltruhe, der tagelang gegrübelt und letztlich beschlossen hat, dass nur genau dieser der richtige Song vor jedem Take-off sein kann, lasse ich mich langsam in den Schlaf rütteln. Das kostenlose Bier werde ich natürlich verpassen.

Related posts:

  1. Die Stiftung Bärenherz bekommt den Bambi
  2. Scrum Lollipops
  3. ScrumMaster Checkliste

Categories: Blogs

A Primer for Smart Change Agents

TargetProcess - Edge of Chaos Blog - Wed, 04/09/2014 - 19:31

Have you ever tried to act as a change agent in your company, and bumped into obstacles that seemed to be blocking the change? There’s no such software development organization in the world that allows no space for some sort of adjustment. Whether you hit a dead end as a change catalyst, or succeed will mostly depend on the following:

If the change you have in mind is trending — agile adoption can be a good example — then you’re lucky. One will have to apply little effort, because agile has gone mainstream, and there’s lots of information out there as to why and how agile is supposed to be good for a company. In this case, your intrinsic motivation as a change agent syncs with the extrinsic sweeping wave. Not only your organization, but many others will find it easy to jump on the same bandwagon. The change will then happen smoothly as in a domino effect, started by one easy move of a finger. With each new organization adopting agile, the chain extends to embrace more and more companies.

The second scenario for driving change is quite the opposite one. It might be related to a not that obvious trend, but you somehow feel that the way stakeholders treat this thing is in need of a major overhaul. This scenario involves repeating it over and over again that the product that your company develops needs to have a more intuitive user interface. You’d run into inertia as the stakeholders would probably say that all is fine with the user interface, because customers seem to be content with what they have, and revamping “the face” of the software involves some heavy changes in the code, etc. Unless you have some compelling proof that current customers and prospective clients find the user interface confusing, or even walk away, the effort required to boost the change in the attitude by pushing it down the pipe would be akin to that of a weightlifter doing 3 consecutive clean&jerk attempts.

The third scenario for driving change is not as easy, as scenario 1, and not as super-taxing, as scenario 2. It’s more related to an innovative change. Say, you’re still defending a difficult case, such as  improving user experience in enterprise software. There’s no domino effect, and no “join the others” feel in the air. What can one do to trigger this change? How to convince the executives that the time will come when the current clients will not be happy with the bulky UI? The incentive for change in this case should be supported by good old research and analysis methods. Instead of tearing your muscles as with weightlifting (or, rather, breaking your tongue), one has to turn on the head and do a research, taking advantage of  the big data that is, hopefully, available in any company, to make the need for a change appear compelling. If a hollow call to action is rendered into the language of pragmatism, the actual “raw muscle” effort of arguing wouldn’t take more than that of this little girl who uses the power of her opponent to win.

the aikido girl

 

Related articles:

Back to the Future of Agile Software Development

The Origins of Big Data Trend

Categories: Companies

Calculating Velocity FAQ

Agile Coaching - Rachel Davies - Wed, 04/09/2014 - 13:41

Sometimes people get confused about velocity and edge cases of what gets counted or not. It doesn't matter greatly except it helps to do this consistently over time. I wrote a FAQ for our teams because these edge cases come up infrequently and developers often don't remember what rule to apply. I'm sharing a slightly abbreviated version of our Velocity FAQ as an illustration of working agreements around this. Your team might choose to do this differently and that's okay.

The purpose of this FAQ is to clear up any confusion about counting team velocity before story prioritisation.  We average our velocity over past 3 iterations to level things out. Also we make adjustments if we know that team members will be on holiday during the next iteration.

1) Should I partially count a story if we did some work on it but it hasn’t been finished? No

2) Should I count a story if the code is all live but we haven’t had the story approved by stakeholders or sent out the release email? No because sometimes more work is discovered through doing this.

3) If we extended or shortened the iteration should I adjust the velocity to match the usual iteration length? Yes

4) If the story was signed off and complete and then later we discover it has problems, Should we add another story for the extra work to fix it? No. If the implementation has a bug or we broke or clearly failed to deliver on the story we will fix it without an additional story, even if it was accidentally signed off.

5) My stakeholder says that she really wanted something extra than the story we’ve developed. Do we expand the story to do the extra things? No, this can be a new story if wasn’t agreed with other stakeholders. It helps to note the acceptance criteria clearly in the story and check them with stakeholders before starting work on development.

6) We had to do some story work in an iteration that wasn't planned in because the story was not finished from a previous iteration (due to any reason including dependency on other team). What do we do?

Step 1: Send stakeholder email or let them know in planning that this is happening and may impact stories currently lined up for current iteration.

Step 2: Fix the problem and then count the full estimate of the original story when its finished in the current iteration

Do not create an extra story for the remainder of the work and estimate it as extra work as this will result in artificially inflating the velocity.

7) We did an extra piece of work it took about 2 points worth, it was never planned in or estimated can I count it now because we did do it?

No. New pieces of work even if they come up mid-iteration, even if they are ultra urgent and should be done immediately should always be discussed, broken down and estimated BEFORE we start work on it. We need to warn stakeholders we are putting it in. So this situation should never ever arise that you only estimate a story after you completed it! If it does happen you should not count it. and discuss what went wrong in the process.

 

Categories: Blogs

Manage Your Job Search is Out; You Get the Presents

Johanna Rothman - Wed, 04/09/2014 - 13:28

I am happy to announce that Manage Your Job Search is available on all platforms: electronic and print. And, you get the presents!

For one week, I am running a series of special conference calls to promote the book. Take a look at my celebration page.

I also have special pricing on Hiring Geeks That Fit as a bundle at the Pragmatic Bookshelf, leanpub, and on Amazon. Why? Because you might want to know how great managers hire.

Please do join me on the conference calls. They’ll be short, sweet, and a ton of fun.

Categories: Blogs

Agile Planning Fundamentals with TeamStart

Rally Agile Blog - Wed, 04/09/2014 - 13:00

Agile Planning: it’s not an oxymoron.

On Tuesday, April 15, our TeamStart webinar series will answer your questions about Agile Planning. Whether you’re just getting started with Agile or consider yourself an expert, join us to get and give good Q+A. We'll talk about making and keeping commitments, using tracking and metrics to predict delivery, and planning levels with time horizons.

Here are a few questions from past Agile Planning webinars:

  1. How does the product owner role fit into Agile Planning?
  2. Are there guidelines for setting up good planning estimates?
  3. If the team is not able to complete a story before the iteration ends,  or if a critical change is requested, how do we respond?

From an Agile Planning perspective these are related questions. Let’s take a look at the answers to see why.

1. How does the product owner role fit into Agile planning?

Answer:  A product owner initiates and translates the product roadmap into a manageable product backlog. He or she participates in daily standups and manages the product dashboard. The product owner communicates with internal teams and the product manager, to understand the features and requirements and support the release planning and sprint planning exercises. It’s also the product owner’s job to allow the team to manage itself and understand Agile estimation approaches.


Screen Shot 2014-04-08 at 4.48.11 PM.png
5 Levels of Agile Planning: From Enterprise Product Vision to Team Stand-up, Hubert Smits

2. Are there guidelines for setting up good planning estimates?

Answer: The principal guideline when estimating user story size is to employ a comparative approach. For example, rather than estimating in absolute terms, such as hours or days, you use abstract "story points" to compare the sizes of work items with past work the team has completed. Using an example the team is already familiar with helps you establish a baseline. By contrast, task size should be estimated in hours, since a task should be small enough that it doesn’t span more than a working day (about six hours.)

The estimation of stories done in abstract values happens continuously, and well before iteration planning; whereas task estimation is done once during the iteration planning meeting, immediately before the team votes to commit to the proposed work.

3. If the team is not able to complete a story before the iteration ends, or if a critical change is requested, how do we respond?

Answer: When the scope of a user story becomes larger -- either because you underestimated its scope or because a change request comes in -- you should finish the current iteration as planned, and re-plan the remaining iterations in the release. In a situation where the team still has a fixed delivery date, you must work with the business to determine what other committed-to features or functions may be sacrificed to continue to work within the timebox limits. Teams should review burndown charts daily, so that you can spot problems early and mitigate them. When it’s necessary to re-estimate and re-prioritize features, you should signal to the business and stakeholders as soon as possible.

I bet you have at least three questions about Agile! Learn more about Agile Planning. Join Tuesday’s TeamStart webinar.

Rob Ward
Categories: Companies

Schätzt du noch oder baust du schon?

Scrum 4 You - Wed, 04/09/2014 - 07:32

Im einem Projekt verlangte das Management für den kommenden Release, einmal zu schätzen, wie viele Bearbeitertage für die zu liefernde Menge an Funktionalitäten wohl benötigt würden, um einen Forecast abgeben zu können. Die Manager wollten das, weil sie mit der Storypointschätzung per Magic Estimation nicht zufrieden waren. Denn die sagte aus, dass das Scrum-Team bis zur Deadline bei der aktuellen Velocity von 40 Storypoints lange nicht das liefern würde, was eigentlich erwünscht war.

Alte Schule. Statt anzufangen, werden nun viele Arbeitsstunden darauf verwendet, vorherzusagen, wie lange es wohl dauern wird mit der Lieferung. Zeitverschwendung, so meine Hypothese. Zahlen aus 2012 belegen: 74% der IT-Projekte werden in der Zeit überschritten, 59% in den Kosten und 69%, was die Anzahl der gelieferten Features angeht. (Quelle: Standish Group 2013, S.2) Warum also viel Zeit auf die Schätzung verwenden, wenn wir immer wieder sehen, dass sie ohnehin mehr als ungenügend ist?
Ganz einfach: Die Schätzung wird verlangt. Punkt. Eines jedoch sollte die Erkenntnis aus diesen Erfahrungen sein: Lieber mehr Zeit für die Umsetzung verwenden als auf das stunden- oder tagelange Schätzen.

Natürlich gibt es in einem Unternehmen immer Interessengruppen, die Ressourcen und Kosten planen müssen. Aber uns sollte klar sein, dass wir unser „Geschätze“ der Dauer und unsere Methoden stark überdenken müssen. Vor allem auch die Frage, wer denn schätzen sollte. Im konkreten Fall entschied man sich dafür, pro Story und Thema den jeweiligen Experten die Dauer der erwarteten Arbeit schätzen zu lassen. Gefährlich, sage ich, und möchte hiermit auf das Buch „Die Weisheit der vielen“ von James Surowiecki verweisen. Darin behauptet der Autor, dass die Masse stets besser entscheidet als ein Einzelner: „Die Masse ist dumm, dumpf und gefährlich. Dieses verbreitete und von Wissenschaftlern gestützte Urteil ist falsch. Wahlumfragen, Pferdewetten, der Publikumsjoker bei Günther Jauch, Google oder Millionen Steuerzahler belegen: Die Menge entscheidet in der Regel intelligenter und effizienter als der klügste Einzelne in ihren Reihen. Ihre Problemlösungen greifen besser als die von Experten. Vorausgesetzt, jeder Einzelne denkt und handelt unabhängig, die Gruppe ist groß und vielfältig, und sie kann darauf vertrauen, dass ihre Meinung wirklich zählt.“ (aus dem Klappentext)

Prompt versuchte ich nun, Surowieckis Vermutungen in einem kleinen Experiment zu beweisen, um die Schätzweise im Projekt überdenken zu lassen. Ich ließ von jedem im Team schätzen, wie viele orange Bälle in dem Sack waren, den ich mitgebracht hatte. Die Wahrheit lag bei 101 Bällen. Das wusste außer mir jedoch niemand. Die kleinste Schätzung lag bei 50, die höchste (im übrigen von einem Experten für Zahlen) lag bei 150. Im Mittelwert schätzte das Team den Inhalt auf 96 Bälle. Ein beeindruckendes Ergebnis, das erstaunlich nahe an der Realität von 101 lag und die Theorie Surowieckis zumindest unterstützt.

Eine Gruppe von Menschen (je größer desto besser) schätzt immer genauer als der klügste Einzelne.
Genau das ist der Grund dafür, warum der Publikumsjoker bei „Wer wird Millionär“ in den meisten Fällen so zuverlässig funktioniert.
Auch dafür, warum eine Gruppe von Experten mit je nur einem Tipp es 1968 schaffte, den Standort des im im Atlantik havarierten U-Bootes “Skorpion” auf 75 Meter genau zu ermitteln.

Bei all diesen plakativen und hochinteressanten Beispielen erinnern wir uns daran, worum es geht: Mehr Zeit in die Umsetzung als in das aufwändige Schätzen zu stecken.

Bleibt nur noch die Frage: „Schätzt du noch, oder baust du schon?“

Related posts:

  1. …denn wenn Anna größer als Tom ist und Tom größer als Friederike…
  2. Schätztauchen
  3. Die Weisheit der Vielen

Categories: Blogs

Agile, the urgency of change

In this article I have been interviewed by ZeroUno with some colleagues of mine about agility and the necessity of change in the ITC field. This is the link to the article: http://www.zerounoweb.it/approfondimenti/software-application-quality/agile-l-urgenza-del-cambiamento.html
Categories: Blogs

Assembla's reaction to the SSL security vulnerability "Heartbleed"

Assembla Blog - Tue, 04/08/2014 - 20:38

heartbleedThe Internet was surprised recently by a bug in the OpenSSL software, called "Heratbleed," that might allow an attacker to see your HTTPS traffic including your password on a Web login form.  You can read about some of the technical details regarding "Heartbleed" here and the OpenSSL 1.0.1g fix here.

We updated the Assembla servers to remove the vulnerability within a few hours of being notified about a fix. Our acceleration provider, Edgecast, had not yet updated their servers with the fix. This extended the time that Assembla users were exposed to the vulnerability for a few more hours. We had turned off Edgecast, causing some pages to render more slowly, until Edgecast's servers were updated. Everything has since returned to normal.

Protect Yourself!
  • It is recommended that you reset your Assembla password. You can do so using the password reset form
     
  • If you use API keys or tokens, we recommend that you reset your API keys or tokens.
     
  • If you use the FTP tool, we recommend that you reset your server login credentials and update these credentials in Assembla's FTP tool.

If you have any questions or concerns, please do not hesitate to contact us

Categories: Companies

The Agile Coach on Production Support

The Agile Management Blog - VersionOne - Tue, 04/08/2014 - 14:53

One of the biggest struggles I’ve seen in organizations adopting Agile is in the area of Production Support. Every organization that has a product to support has to manage this. It’s a critical part of the business. There’s a lot of responsibility to manage a 24/7 Production environment. The middle of the night calls, working on code you didn’t create. Speediness, precision, reaction time and problem-solving are crucial.

productsupport

The struggle typically comes in the form of pulling people away from active Scrum teams to make whatever hot fixes are necessary. This is clearly disruptive to the Scrum development team. Oftentimes, a team member is being pulled away to work on something that’s very unpredictable. Who knows how long they could be gone from the team; an hour, a day, a week? This disrupts our rhythm and velocity. It makes planning difficult. Team cohesiveness suffers. The person getting yanked to do the Production work usually isn’t too happy either. Context switching makes them less productive. And in the end, we actually get less done!

Alas, we need to get these ongoing high priority bug fixes out the door asap. And we need the ability to re-prioritize any time. We need focus. And we know that 2 week sprints aren’t a good fit.

So how do we combat this? How can we keep our Production environment up to speed, while also allowing our Scrum teams to develop that stuff they’ve committed to getting done for their Product Owner?

My preference, and one that I’ve seen work well in many organizations, is to create a new Production Support team that works these hot fixes as part of a Kanban effort. The only negative feedback I’ve heard on this is that it seems like punishment to some (think of the Gulag in Northern Syberia). To combat this feeling, we’ve tried cycling folks on and off the team so they don’t burn out. As any good Managers knows, it goes a long way to show your appreciation to this group in some way. Maybe a really nice work environment, new laptops, snacks/drinks, etc. A sincere pat on the back also works wonders. Get creative. Additionally, there may be some folks that don’t fit well in your new highly collaborative team culture. They’re very smart folks, but more of the lone wolf variety. This team could be a natural fit for them.

At the end of the day, technical debt is something that will keep us in this death spiral. We want fewer bugs in Production. In order to get out of it, we need to improve our technical practices, our code quality, our testing, our architecture, and our design. It’s hard to make any progress if we keep patching up something that’s not good to begin with. Sometimes it’s just easier in the long run to scrap it and start fresh (I know, that’s a hard pill to swallow).

How do you handle Production Support in your Agile environment?

Categories: Companies

Don’t Estimate Spikes

Leading Agile - Tue, 04/08/2014 - 13:51
 

Don't Estimate Spikes

Don’t Estimate Spikes

I don’t estimate spikes.

Do All Your Spikes in Sprint 0?

If you implement all of your spikes for each release in a “Sprint 0″, you could estimate them. If you do, do so always so that your velocity will be reliable. Spikes are, like defects, generally harder to estimate correctly relative to user stories. It’s best to time-box them.

If you don’t estimate spikes, your Sprint 0s or HIP Sprints may have no points. That’s no problem. When computing your average velocity and when release planning, you can exclude Sprint 0s or HIP Sprints — don’t count them in the devisor when averaging your velocity; don’ t allocate points to them when release planning.

Even if you do all of your spikes in Sprint 0, additional spikes often come along during the release. For those, don’t estimate them for the same reason I don’t estimate defects.

Don’t Do All Your Spikes in Sprint 0?

Spikes in your backlog represent risk. Spikes often correspond to un-estimated user stories and stories with ambiguity — stories where we need to do a research spike before we can estimate. For these reasons, we want to knock out spikes early each release. (I’m assuming periodic releases — Prioritizing spikes in the face of continuous planning and continuous deployment is another story.)

However, spikes do come along later in our releases as unplanned work. And in that case, I still want to execute the spikes ASAP. And I still don’t want to estimate them.

Therefore, for me, spikes don’t stay in the backlog very long. I rarely consider them planned work of the same order as stories. I may have planned stories for the next 4 months, but I don’t want a backlog of spikes that I can’t implement in the next 2 sprints. This is not about discouraging spikes. It’s about resolving them quickly just like I would want to do for defects. It’s about not having a big backlog of unresolved spikes, just like for defects.

One great benefit we get from estimating user stories is that estimating drives clarity about the work. Estimating can help us clarify our acceptance criteria. Being clear about the work, the goal, and the acceptance criteria is just as important for spikes as it is for user stories. But estimating doesn’t always achieve that clarity. Sometimes we get lazy, especially for spikes. So, setting a small time-box limit for spikes is another way to encourage clarity. I like to set explicit policy for spikes. For example, one team’s policy was that all spikes must be completed in 12 hours or less, each must have one explicit question to answer, we must know who the answer goes to, and there must be a “demo”. No vague spikes with vague results.

Conclusion

Therefore, whether you do all of your spikes in Sprint 0 or spread them out over the course of a release, I don’t want them hanging around a long time and as for defects, I don’t estimate them. I choose my poison of NOT including spikes in my velocity. I don’t want to inflate my velocity. Defects and spikes are estimated differently than how we estimate stories (relative to each other). It’s very difficult to correctly relatively compare to a 1 point story a spike that is time-boxed in terms of hours or days. Likewise with defects — it’s a very different type of work than normal story development.

 

webinar ad

The post Don’t Estimate Spikes appeared first on LeadingAgile.

Categories: Blogs

“Wir müssen nur noch unsere ScrumMaster überzeugen”

Scrum 4 You - Tue, 04/08/2014 - 07:30

Habt ihr diesen Satz auch schon einmal zu hören bekommen? Ich war absolut überrascht bzw. fast schon überrollt von der Aussage: „Mein Ziel ist es, bis zum nächsten Treffen meinen ScrumMaster von Scrum zu überzeugen.“ Getätigt von einer Führungskraft. Ich kenne eher Fragen wie: „Wie überzeuge ich mein Team?“ oder „Wie überzeuge ich das höhere Management von Scrum?“ Aber „Wie überzeuge ich meinen ScrumMaster von Scrum“ war mir absolut neu.

Ein ScrumMaster ist wie das Fundament, auf dem man ein Haus baut, und wenn bereits das Fundament bröckelt, wird auch der Rest des Hauses nicht sonderlich stabil sein. Kann man denn mit einem ScrumMaster, der noch von Scrum überzeugt werden muss, überhaupt eine erfolgreiche Prozessveränderung durchführen? Meistens ist den ScrumMastern ihre Bedeutung nicht bewusst, daher ist es essenziell, ihnen ihre Rolle im Scrum-Prozess genau zu erklären. Erst wenn man die eigene Rolle versteht, kann man sie auch leben. Ihr habt es sicher schon tausend Mal gehört, aber scheinbar ist es nötig, die Rolleninhalte des ScrumMasters immer wieder zu wiederholen. Was genau sind denn die Aufgaben eines ScrumMasters im Veränderungsprozess mit Scrum?

Scrum implementieren – bzw. Scrum einführen
Erste und wichtigste Aufgabe eines ScrumMasters ist es, Scrum im Unternehmen zu verwirklichen, die Regeln von Scrum einzuführen und den Veränderungsprozess anzustoßen. Jede noch so geringe Abweichung von Scrum ist – zumindest in der Lernphase – zu vermeiden.

Abarbeiten von Impediments und Entscheidungen treffen bzw. Hindernisse aus dem Weg räumen
Alle Impediments, die das Team und die Organisation daran hindern, effektiv zu sein, werden vom ScrumMaster gelöst.

Arbeit mit dem Team
Der ScrumMaster arbeitet mit dem Team daran, die Entwicklung eines Produktes selbst in die Hand zu nehmen.

Arbeit mit dem Product Owner
Der ScrumMaster unterstützt nicht nur sein Team, damit es Scrum versteht und umsetzen kann, sondern auch den Product Owner, damit auch dieser seine Aufgaben in Scrum versteht und erledigen kann.

Scrum in die Organisation hineintragen und die Organisation ändern
Die mit Scrum erzielten Erfolge werden in der/die Organisation kommuniziert, um auch eine Änderung in der Organisation anstoßen zu können. Der ScrumMaster erzählt von den Ergebnissen, die sein Team und er mit Scrum erzielt haben. Ja, ScrumMaster sollten daran arbeiten, ihre Chefs und andere Teams von Scrum zu überzeugen, um Scrum im gesamten Unternehmen zu etablieren.

Die Produktivität des Teams steigern
Das wird durch das Ausleben von Scrum erreicht!

Ausgehend von den Aufgaben als ScrumMaster, sollte es überhaupt nicht mehr nötig sein, einen ScrumMaster von Scrum zu überzeugen. Ohne Überzeugung kann er oder sie diese Aufgaben nämlich gar nicht übernehmen und noch weniger Erfolge erzielen.

Symptome und Ursachen

Wenn wir aber genau hinsehen, liegt hinter der Aussage „Ich muss nur noch den ScrumMaster von Scrum überzeugen“ noch eine andere Ursache. In diesem Fall war es so: Man nehme mehrere Development Teams und ein Management, das merkt, dass eine Prozessänderung nötig ist, um besser und schneller zu werden. Also entscheidet sich das Management für Scrum. Die Rollen werden schnell verteilt, alle bisherigen „Anforderer“ werden zu Product Ownern und die ScrumMaster sind einfach die Teamleads, die auch bisher die Teams geleitet haben (es spricht ja absolut nichts dagegen). Also nehmen alle an den einschlägigen Trainings teil und werden – juhu – ScrumMaster. Und einige Zeit später kommt man drauf, dass man die Leute vielleicht ein wenig überrumpelt hat. Statt zu verstehen, dass man es hier mit einem massiven persönlichen Veränderungsprozess zu tun hat, wird Etikettenschwindel betrieben: Die einzige Veränderung besteht darin, den Titel auszutauschen. Während das Management von einem Tag auf den anderen ScrumMaster haben will, sind die ScrumMaster im Geiste noch Teamleiter – und das ist nur allzu verständlich. Vom Titelträger zum Change Agent zu werden, ist ein ziemlich großer Schritt und nicht von heute auf morgen zu bewerkstelligen. Ein echter ScrumMaster kennt Scrum, will Scrum und arbeitet nach Scrum – ein ScrumMaster lebt nun mal Scrum.

Wenn man sich nun schon in diese etwas missliche Lage gebracht hat: Wie kommt man da wieder raus? Manager sollten wahrnehmen und wertschätzen, was ScrumMaster im Unternehmen mit ihren Teams leisten. Auch kleinere Erfolge, wie ein erfolgreich abgeschlossener Sprint, gehören gefeiert und gelobt. ScrumMaster leisten den höchsten Beitrag für den Veränderungsprozess und sollten auch seitens der Führungskräfte und Product Owner dementsprechend wahrgenommen werden. Positives Feedback ist für viele ScrumMaster die größte Motivation in ihrer Arbeit.

Vielleicht muss gar nicht der ScrumMaster von Scrum überzeugt werden, sondern dem Management sollte bewusst werden, was ihre ScrumMaster im Veränderungsprozess leisten. Es kann nämlich auch gut sein, dass ScrumMaster sich denken: „Ich muss noch meine Führungskraft von meiner Rolle und meiner Leistung überzeugen.“

Related posts:

  1. Die Skills eines guten ScrumMasters
  2. Taktische Ebene
  3. Grundlagentrainings

Categories: Blogs

Feature Boards

Agile Game Development - Mon, 04/07/2014 - 23:29
A challenge in agile game development is managing cross-discipline teamwork where a wide range of skills is required.  As a result, following some practices and artifacts by-the-book doesn’t work as well as it does for software-only teams.  One of these artifacts is the task board.  These boards are used for teamwork transparency during an iteration and are a tool for the team to manage their day-to-day progress.  However, for a highly diverse game team, task boards are often modified.  This article is about one such modification, called a “Feature Board”.

Task Boards
A strength of the physical task board is that the team owns it.  A physical task board is always visible and requires no licenses and little training to use.  The only limitations are that it requires wall space and team collocation.  The photo above demonstrates some example modifications made by the team using it, such as adding columns for verification or colored cards for tracking different types of work (e.g. emergent work, bugs or impediments).

A problem that boards like this encounter is the lack of visibility of cross-discipline dependencies.  For example, let’s say a team is working on a number of player mechanics in an iteration, such as jumping, crawling and ducking.  There are three programmers and one animator among the team.  Halfway through the iteration, the programmers have the code working, but can’t fully test it because the animator is backed up with too much work.  Perhaps the animator is trying to work on all three mechanics at once or the task of animating one mechanic is harder than they thought, or there is a problem exporting the animations.  Creating awareness of these problems is one of the functions of the daily stand-up meeting and a mature team will address them, but sometimes a problem like this doesn’t surface until it’s too late in the iteration to do anything about it.  This is one instance where a Feature Board can help.

What is a Feature Board?A simple Feature Board looks like this:

Instead of tracking tasks, a Feature Board visualizes feature development state.  The iteration (or Sprint) goal is on the left side and contains cards identifying features the team committed to implementing over the next 2-3 weeks.  The cards move around the board (not just left to right) during the iteration, depending on the work that is being done.  Each column on the board indicates the type of work being done on the feature at the moment.  The rows show which features are in progress and which features are waiting for work to be done.  As features are completed, they exit to the right of the board into the “done” column.  In this particular example, the features are prioritized in value.  Red features are the most important.  Green features are the least important and yellow are in-between.

How is a Feature Board used?A Feature Board serves the team.  It shows them the state of each feature on a daily basis and leads to conversations that are necessary for a cross-discipline game team.

Take a look at the board above.  The board is telling us that the jump feature is having some coding done, while melee is getting some animation.  There are a few bug fixes that need to be done and one of them is being worked on by both a designer and programmer.
The board also raises questions.  For example:

  • Are the testers overwhelmed?  It looks like they have test work piling up.
  • What is the modeler doing?  Have they run out of work?
  • Why are lower priority features ready for test?  Why are they ahead of higher priority features?

The board won’t answer those questions, but quickly highlight them for the team to answer.

What are the benefits of a Feature Board over the by-the-book Scrum task board?Feature Boards focus on feature progress, not task progress.
Too many times, teams get focused on completing tasks in any particular order and don’t worry about features being “done” until the end of the iteration.  Postponing “done” means features don’t get enough polish and tuning time.  As a result, teams release lower quality features.  Feature Boards focus the team on completing prioritized features over merely completing tasks in any particular order.

Feature Boards help balance cross-discipline teams.
Unlike software-only teams, a cross-discipline team of game developers can’t share as much of their work (e.g you really wouldn’t want me creating a texture or a sound for your game).  So it’s important to quickly identify problems with the flow of work.  Task boards don’t do this well;  They don’t visualize stalls and backups.  As a result, individuals end up solving problems by working on more things in parallel, leading to late integration, testing and tuning.  Feature boards show, dramatically and frequently, where the stalls are occurring, or soon to occur, which focuses a team's response.

Feature Boards help limit Work-in-Progress (WiP).  
In order to complete features sooner in an iteration, a team needs to work on fewer features in parallel and address issues or workflow problems that are stalling work or wasting time.  By separating the “In Progress” features from the “Waiting/Blocked” features, a team will see where work is piling up quickly enough to be able to do something about it.  Teams can even institute “WiP Limits” on the columns or rows to stop any new features being added when work is piling up too much.  This leads to different behaviors.  For example, when the team sees that testing work is piling up above, others in the team can help out.  There is no law of nature that says “only testers can test”.  By embodying WiP limits, Feature Boards can be a tool for encouraging such “out of the box” thinking.

“This looks like Kanban!  Why not just use Kanban?”
Some of these ideas come from Kanban (like WiP limits), but it’s not Kanban by-the-book.  While Kanban by-the-book is great for some work—work that is less exploratory, or follows a predictable flow of hand-offs from one discipline to the next—the Feature Board is better for teams that are working on unpredictable new features and “first-time” content.  Feature Boards fit best within a time-boxed iteration which has a lot of “swarming”.  “Swarming” means that there is an unpredictable flow of work between disciplines to create a feature and the feature will bounce around or iterate unpredictably before the fun is discovered.

Own ItThe bottom line is that I don’t care what label you use (Kanban, Scrum, etc).  You need to find what works regardless of where it comes from and keep finding ways of making it work better.  That’s the agile mindset.

Categories: Blogs

A Team of Product Owners

Scrum Expert - Mon, 04/07/2014 - 16:41
The Product Owner is a very important role in Scrum. He has the key responsibility to create, manage and prioritize the product development backlog. Can this responsibility always be to a unique person or is there situations where you could have a team of product owners? Kenneth Rubin discusses this topic in his “Essential Scrum” book. Every Scrum team must have a single person who is identified as the product owner and is the only person empowered and accountable for fulfilling the product owner responsibilities for that Scrum team. Should we allow ...
Categories: Communities

Estimates Considered Useful

Agile Coaching - Rachel Davies - Mon, 04/07/2014 - 12:38

Despite the current #NoEstimates trend, at Unruly we still estimate our user stories. The way we do this is in small informal meetings in our development area. Why do we find this useful? Because estimates of development costs inform decisions on what to develop next.

At Unruly our teams are all working on multiple product streams. We don’t have long-term project or release plans. We deploy features as soon as we can rather than to hit a release date. We agree the next set of priorities with our product stakeholders every few weeks. The team makes a proposal of what seem to be the most valuable stories to work on next and we also offer our stakeholders a list of alternative options as estimated stories. There’s a bit of shuffling in the meeting, which typically takes less that 30 mins. We are not making a commitment to deliver exactly those stories as something more important may come up.

Spam

As we whittle down our proposed list of best value stories in the lead-up to story prioritisation with stakeholders, developers make two kinds of estimate. A rough “ballpark” given by a lone developer is used to figure out whether to bin the idea or do further investigation. A “full estimate” is given by the team when the developer investigating that story has gathered enough information to bring a proposal to the team. We only put full estimates on stories that are strong contenders to present to stakeholders for next iteration.

I wonder if #NoEstimates approach is effective when there’s no significant value tradeoff being made around strands of work (sets of small user stories) and that we find estimates useful because we’re looking for the most valuable stories each time and development cost is a part of that. I think it’s because we’re in a #NoProjects context that we find estimates useful, I’d be interested to hear your thoughts on this.

Categories: Blogs

Von Zahlenfetischismus und anderen Angewohnheiten

Scrum 4 You - Mon, 04/07/2014 - 07:49

Letztens im Sprint Planning 1: Der Product Owner stellt gerade die 7. Story vor. Bereits das Commitment der 6. Story hatte einigen Teammitgliedern Bauchschmerzen bereitet. Doch zu meiner Überraschung ist das Team schnell zu dem Entschluss gekommen, auch diese weitere Story zu committen.

Szenenwechsel: Die Nachbesprechung des Meetings in kleinem Kreis. “Warum wart ihr euch als Teammitglieder bei der letzten Story so sicher?”, lautet meine Frage als ScrumMaster. Kleinlaut wird mir erklärt, dass ein Teil der Storys vorab im Aufwand mit Manntagen geschätzt wurde. Und das alles, nachdem wir die letzten Schätzungen mit Hilfe von Magic Estimation [1] auf der Basis des relativen Funktionsumfangs sehr effizient durchgeführt hatten und das Team überzeugt von den Vorteilen wirkte.

Das Beispiel zeigt, wie schwierig es doch ist, alte Gewohnheiten hinter sich zu lassen. Obwohl mir doch in den Diskussionen mit dem Team bestätigt wurde, dass alle bisherigen Aufwandschätzungen keineswegs genau und richtig waren. Zudem sind viele der traditionellen Software-Schätzverfahren mit hohem Aufwand verbunden, da viele Faktoren erhoben und Bewertungen durchgeführt werden müssen, wie beispielsweise in der Function Point Methode [2]. Und doch scheint es schwierig zu sein, die alten Angewohnheiten einfach einmal beiseite zu legen.

Doch was ist es, das uns an den Schätzungen mit Aufwand festhalten lässt? Ist es das Gefühl der vermeintlichen Sicherheit, die Größe der Story bestimmt zu haben? Ist es die Annahme, das Projekt mit Hilfe dieser Zahlen „im Griff“ zu haben? Oder ist es der reine Zahlenfetischismus, der von Jahr zu Jahr zuzunehmen droht? Oder sind es ganz andere Gründe, die wir gar nicht benennen können?

"Man kann die Ideen, wie sie in unserem Geiste und in der Natur sich kundgeben, sehr treffend durch Zahlen bezeichnen; aber die Zahl bleibt doch immer das Zeichen der Idee, nicht die Idee selbst. Der Meister bleibt dieses Unterschieds noch bewusst, der Schüler aber vergisst dessen und überliefert seinen Nachschülern nur eine Zahlenhieroglyphik, bloße Chiffren, deren lebendige Bedeutung niemand mehr kennt und die man mit Schulstolz nachplappert." Heinrich Heine

Mein Tipp: Lasst euch auf neue Methoden ein, wenn die bisher verwendeten keinen Erfolg versprechen. Lasst euer Bauchgefühl entscheiden und verschwendet keine Stunden und Tage für kompliziert berechnete Schätzungen, die nicht halten. Benutzt Magic Estimation, mit dessen Hilfe ihr die Storys schneller und fokussierter schätzen könnt. Ich bin mir bewusst, dass dies auch Mut erfordert. Den Mut, bisher jahrelang verwendete Verfahren in Frage zu stellen. Glaubt mir, es lohnt sich!

[1] Gloger, B.: Scrum. Hanser Verlag (4. Auflage), 2013.
[2] Poensgen, B.: Function-Point-Analyse: Ein Praxishandbuch. dpunkt Verlage (2. Auflage), 2012.

Übrigens frisch im Buchhandel: “Wie schätzt man in agilen Projekten – oder wieso Scrum-Projekte erfolgreicher sind” von Boris Gloger. Hanser Verlag 2014.

Related posts:

  1. Magic Estimation / Great Article
  2. Agile Estimation
  3. Magic Estimation / Toller Artikel von David Campey

Categories: Blogs

Scrum: The Necessary Conditions

Business Craftsmanship - Tobias Mayer - Sat, 04/05/2014 - 15:51

[Originally published on ThePeoplesForum 8/5/13]

The previous post Scrum: a 5-step guide for managers was (quite rightly) criticized for not describing Scrum. It was never intended to. In the text I describe the five steps as being for “managers and executives for starting a new Scrum process”. The title was intended to challenge, to have people ask, so what is Scrum?

Scrum, clearly, is the thing defined in The Scrum Guide, a lightweight document, laying out the process, roles and artifacts of Scrum, and describing the value it offers. It is—happily—very low on prescription, beyond prescribing the basic Scrum framework. There is little in there to take issue with, and actually little that has changed from original Scrum. The problem is, with this and most of the books on the subject, sparse attention is paid to the environment in which we try to implement Scrum. To me this is key to success.

I recently witnessed a team implement at least the first four of the five steps I recommend. They were not “doing Scrum” and yet were closer to the values we seek with Scrum than many teams I have witnessed struggling to make the process meaningful with members in different locations, no clear product vision, team members working on different projects, being driven (and driven crazy!) by the electronic tracking tool of (someone else’s) choice, with all its rules and limitations. Scrum can sometimes create more pain that it relieves.

Teams that are not supported—environmentally, humanely, systemically—to do Scrum, will do Scrum very poorly. Teams that are so supported may not actually end up doing Scrum at all, but will likely have better results. This is my experience from the past nine years.

So my “5 steps” are intended to have managers and executives understand the necessary conditions for inspiring an effective, engaging process, whether that’s Scrum or something else. With such conditions met, I would usually recommend something that looks very much like Scrum, with perhaps a more continuous flow model á la Kanban. As always, context will determine the detail.

And if anyone doubts my own definition of Scrum, or feels it is out of line with The Scrum Guide. Please read Simple Scrum, an essay written in 2009, which still accurately reflects my understanding of Scrum.

Original comments can be seen here

Categories: Blogs

Scrum Knowledge Sharing

SpiraPlan is a agile project management system designed specifically for methodologies such as scrum, XP and Kanban.