Skip to content

Feed aggregator

The Impact of Agile and Lean Startup on Project Portfolio Management

With the large number of organizations now adopting agile methods, the existing body of literature has paid significant attention to the function of project management, business analysis, and more recently program management.  This is understandable as individuals filling these roles are ubiquitous and critical to the operation of their respective organizations.

Many organizations have an additional formalized function, project portfolio management (PPM), that is also critical to the organization but gets little attention — especially in light of the considerable desire being shown to scaling agile to the enterprise level.  The focus, objectives, and responsibilities of agile PPM must fundamentally shift when transitioning to an agile model, structure, and culture.  The reason for this is simple—the same agile principles that are being applied to individual projects can also be leveraged to manage the portfolio.

Below are two ways that agile PPM differs from traditional PPM:

Traditional PPM:  Optimize portfolio resources (individuals) by skill set
Agile PPM:  Maximize value delivery to customers by team capability

Traditional projects, while still delivered by teams, are much more focused on optimizing skill set across a portfolio.  One reason for this is because most traditional organizations are structured and organized by functional specialty.  That is, the organization’s structure is very hierarchical and often has individuals within a particular functional specialty (business analysis, quality assurance, project management, etc.) reporting to the same manager.

Another reason is that projects move through the process by passing through one of several phase gates such as requirements, design, test, etc.  When this is the case, project execution may be throttled by a particular skill set at each gate.  For example, if you have five business analysts, you will be limited to the number of projects that can be active.  However, most organizations ignore this fact and still have far too many projects active at any time; this only adds needless risk.  The sad truth is that most organizations really have no idea of their true project capacity.

In agile organizations, the team (not the individual) is the unit of capacity measure.  Therefore, if you have three teams that are capable of delivering an initiative or feature, you are limited by the number of teams.  So, how many projects of each type can you have active at any one time?  I don’t know; each situation will vary by organization, team, and context.  However, to get started, try setting the limit to be equal to the number of teams with the capability of delivering that type of solution.  If it doesn’t help, experiment.

For example, if you have five products that need mobile solutions, but only have three teams capable of doing the work, only start the three that will deliver the highest customer value.  Of course, that assumes that the teams are not already working on other items.

Traditional PPM:  Maximize Revenue and Evaluate Project Health
Agile PPM:  Govern Empirically through Validated Learning

One of the primary goals of traditional PPM is maximizing revenue… that is, how much money a particular project or product can add to the “bottom line” of a company’s balance sheet.  In today’s economy that is characterized by pervasive, disruptive technology and consumers that demand choice and flexibility focusing on revenue alone misses the point.

Revenue is the metric of wildly satisfied customers.

Stated another way, many would say that the sole objective of PPM is to maximize shareholder value.  This is done through increasing revenue, but it misses the point.  Because customers have flexibility and plentiful choices, the focus must be on maximizing customer value.  By focusing on customer value, if shareholder value doesn’t increase, it may be because you’re building the wrong thing.  Wouldn’t it be appealing to find that out sooner rather than later?

Further, traditional PPM typically measures the health of the agile portfolio by evaluating the health of its component projects.  This is great—in theory.  But one of the big problems with this approach is the way in which health is typically measured.  It’s most commonly done through subjective mechanisms like project status reports, achieved milestones, and progress stoplight indicators.  None of these approaches offer an objective mechanism of determining if the project is actually building the right thing.  Personally, I’ve managed projects that have delivered the wrong solution on time and within budget.  The kind of objectivity that’s required is customer validation.

A more agile PPM approach would be to introduce some mechanism of validated learning to help us make more sound and responsible decisions for our customers about what projects or products to continue funding.  Validated learning is a key aspect of the Lean Startup approach made popular by Eric Ries’ book of the same name.  Agile projects aim to build small increments of a product.  This means we are dealing with smaller return-on-investment (ROI) horizons.

Through agile PPM it’s possible to incrementally fund two projects to experiment with two different solutions to a (perceived) customer problem.  This is known as A/B testing, a.k.a., “split testing.”  Because agile methods allow us to get solutions into the hands of customers more quickly, we can evaluate the results of our experiments and shift funding to investments that are more promising and pertinent.  Because the funding is done incrementally, we need not fund an entire project for an extended period before finding out whether our assumptions were incorrect.


While these are only two of many considerations when adopting agile PPM, each has the potential to make an immediate and lasting impact on your organization and its customers, thereby, positively impacting your shareholders as well.  In my opinion, the sooner organizations can sow the seeds of customer satisfaction through validated learning, engagement, and collaboration, the sooner they will reap the rewards of increased shareholder value.

What are your thoughts?  How can you begin to apply these concepts within your own unique context?

Categories: Companies

Lean, Agile & Scrum Conference, Zurich, Switzerland, September 9 2014

Scrum Expert - Tue, 08/19/2014 - 19:52
The Zurich Lean, Agile & Scrum Conference (LAS) is a one day conference that focuses on Lean and Agile approaches for software development. The conference provides both German and English content. The keynotes of the 2014 edition of the Zurich Lean, Agile & Scrum Conference will be Alistair Cockburn and Bob Marshall. In the agenda you can find topics like “Our journey from Waterfall to Agile; Delivering an Agile Framework to a Global IT Organization”, “Transforming Addicted Organisations (Serenity to Accept What I Cannot Change, Courage to Change What I Can)” ...
Categories: Communities

Scaled Agile Framework (SAFe) 3.0 Released

Scrum Expert - Tue, 08/19/2014 - 17:43
The version 3.0 of the Scaled agile Framework (SAFe) has been released. The Scaled agile Framework is a methodology created by Dean Leffingwell to implement Agile practices at enterprise scale. Major changes in the SAFe 3.0 version include: * Guidance on the critical role, knowledge and responsibilities of Lean-Agile Leadership * Enhanced Portfolio Level — new flow, new Metrics, Strategic Themes that connect business strategy to Portfolio Vision, and Portfolio-level Non-functional Requirements (NFRs) * Lean-Agile Budgeting optimized for flow “Beyond Project Cost Accounting” * New guidance on Coordinating multiple Agile Release Trains within larger Value ...
Categories: Communities

Software Waste is Invisible

Agile Tools - Tom Perry - Tue, 08/19/2014 - 15:34


You know what one of the biggest problems with knowledge work is? It’s mostly invisible. We can talk about it, but we can’t see it. You can’t see the stuff you want to create (except perhaps in your own head, which really doesn’t count) and perhaps most importantly you can’t see the stuff that is missing.

It gets worse the more people you add to the equation. That’s right, go to a planning meeting and you will find a long list of things that the team thinks they want to do (struggling to make the work visible), but I can almost guarantee you there is no list of what is missing. Why not? Because we can’t see it. It’s hard enough to see the work – that’s tough enough to begin with, but you can just forget about seeing the delay that is associated with that work.

I was reading Reinertson’s book on Product Development Flow the other day and within a couple of pages, it hit me: we can’t see what the hell we are trying to do – and that makes knowledge work really hard. We are like blind men trying to describe the proverbial elephant. If I were assembling a bicycle, I would be able to see all the parts before I put them together. I might even have some sort of inventory list to check against. I can physically see and verify the parts and the work that needs to be done. Compared to knowledge work, this physical assembly is worlds easier to estimate and accomplish – simply because we can see it.

OK, to you this may be a big, “Duh!” moment. Fair enough. But here is where I realize that we may often have a problem. What is the output of a planning meeting? Some user stories, some tasks, maybe a few follow up questions? Perhaps a calendar or timeline of some sort? How often do you see a list of all the risks or potential delays that need to be addressed as an output of a planning meeting? Yeah, never.

You see any process can be broken down into work and delay. This is the foundation for value streams. The thing is, you can’t have one and not the other. There is always delay in any system, no matter how efficient it is. But delay is one of the most neglected things we plan for. Honestly, most of the time we don’t plan for it. We plan the work and choose to ignore the delay. This is like talking about the work, but not acknowledging the impediments to the work. You can’t have one without the other. 

So why in the world would you NOT plan for delay? Planning for it is simply acknowledging that it’s real. Well, I would submit that part of the reason that delay doesn’t get more consideration is because it’s invisible. It’s very hard for us to see and visualize. Let’s face it, human beings perception of time is a total mess. We suck at assessing duration, so why would we be any good at assessing delay?

On agile teams we have evolved mechanisms to make the work visible: Story boards, Kanban boards, & Story maps, are just some of the techniques that have evolved to make work visible to us. We need similar mechanisms to make delay, impediments and other forms of waste visible too. Once we do that, we will have a more realistic vision of the work we are trying to do.

Filed under: Uncategorized
Categories: Blogs

Design Thinking für Product Owner – Teil 1: Was ist eigentlich Design Thinking?

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

Mit der Reihe “Design Thinking für Product Owner” wollen wir Product Owner Anhaltspunkte dafür geben, wie sie ihr Produkt gestalten können und wie sie die Items für das Product Backlog generieren können.

Warum ist Design Thinking für Product Owner wichtig?

Der Product Owner ist für den Return on Investment verantwortlich, er bestimmt die Eigenschaften des Produkts, priorisiert nach Business-Value und kommuniziert eine klare Produktvision. Aber was der Nutzer wirklich braucht und wie aus vagen Produktideen eine klare Produktvision wird, beantwortet Scrum nicht!
Genau hier kann Design Thinking den Product Owner unterstützen. 
In Iterationen nähert man sich der bestmöglichen Lösung für den Nutzer, generiert Wissen für sich und andere und kann schlussendlich dem Kunden und dem eigenen Scrum-Team eine getestete und erfolgversprechende Produktvision im Spannungsfeld aus Wünschbarkeit, Machbarkeit und Wirtschaftlichkeit präsentieren.


Design Thinking behält dabei stets die Menschen, die das Produkt benutzen sollen, im Fokus und strebt danach, die Erfahrung des Nutzers mit der kreierten Lösung zu verbessern.

Was ist eigentlich Design Thinking?

Viele Menschen sehen auf den ersten Blick nur den Design-Thinking-Prozess, im Grunde ist Design Thinking aber eine agile Grundhaltung und eine Sammlung verschiedener Techniken aus unterschiedlichen Disziplinen. In der Kombination soll dies die Erfolgswahrscheinlichkeit bei der Entwicklung von Lösungen in komplexen Umfeldern erhöhen. Die Entwicklung von Ideen im moderierten Design-Thinking-Prozess ist dabei absolut nutzerfokussiert, ergebnisoffen und doch ergebnisorientiert. Das interdisziplinäre Team sucht nach aktuell unbefriedigten menschlichen Bedürfnissen, die dann im Mittelpunkt der Lösungsfindung stehen.

Mitte der 1990er-Jahre wurde an der Fakultät für Ingenieurwesen der Universität Stanford der Name “Design Thinking” für dieses methodische Gerüst der Innovationsarbeit geprägt und in der 1991 gegründeten Innovations-Agentur IDEO bereits angewendet.
In Europa wird diese Methode heute an der School of Design Thinking des Hasso-Plattner-Instituts in Potsdam … nun, nicht gerade gelehrt … eher erfahrbar gemacht.

Was heißt “agiles Mindset”?

Die wichtigsten Komponenten sind das Team, der Raum und der Prozess, aber ohne die passende persönliche Einstellung funktioniert Design Thinking nicht. Design Thinking braucht “T-shaped People”! Eine Bezeichnung für Menschen, die eine Tiefe/Spezialisierung in ihren Skills (vertikaler Balken) aufweisen, aber dennoch in der Lage sind, über Ihre Disziplin hinaus (horizontaler Balken) mit anderen Experten und Perspektiven zusammen zu arbeiten, zu teilen und zu wachsen.
 Der Design-Thinker sollte mit Unvorhersehbarkeit und Unsicherheit umgehen können. Positiv formuliert: Es bedarf einer mutigen, neugierigen und ergebnisoffenen Grundhaltung, denn der Design-Thinker kennt zu Beginn die Lösung nicht und wird erst im Laufe des Prozesses zum Experten. Er provoziert das Scheitern und setzt sich dem gnadenlosen Feedback der Nutzer aus … und das tut weh! 
Aber es ist auch der Auftakt zu neuen Erkenntnissen und – da man stets im Team arbeitet – zum gemeinsamen Lernen.
All dies sollte der Design-Thinker wirklich wollen, verordnen kann man es nicht.

Design Thinking & Change Management Flipcharts

In den folgenden Beiträgen zu “Design Thinking für Product Owner” werde ich Design Thinking näher erklären und aufzeigen, wie es mit Scrum kombinierbar ist.
 Ich freue mich über Fragen, Anregungen und Diskussionen!

Related posts:

  1. Produktfindung mit Design Thinking
  2. 5 min on Scrum | Scrum and Design
  3. Training

Categories: Blogs

One thought before sleep… why is management changing so slowly ?

AgileEspresso - Davide Noaro - Tue, 08/19/2014 - 00:39
Midnight is passed… I’m reading some pages of the book “How to Change the World” of Jurgen Appelo… and I’ve found just in some lines the sum up of my feelings…  I share it with you, to be your thought for today, your thought for tonight: “W.  Edwards  Deming  wrote  decades  ago  that  bonuses  are  […]
Categories: Blogs

Next Cape Town talk: Product Owners: Dealing with Capacity and Prioritisation

Scrum User Group of South Africa - Mon, 08/18/2014 - 10:51
During this session we will look at the various things POs need to focus on, manage and eventually master. The majority of the session will be spent on 2 areas that in our experience, many PO’s struggle with, capacity and prioritisation. To explain capacity we will use an analogy and help you self discover what […]
Categories: Communities

5 minutes on scaling: Hangout & Co

Scrum 4 You - Mon, 08/18/2014 - 07:40

Natürlich nutzen wir mittlerweile neben den physischen Taskboards auch JIRA und Co. Doch jedes Mal, wenn ich diese Tools nutze, gehen mir ihre Unzulänglichkeiten auf den Geist. Sie lösen im skalierten Umfeld das eigentliche Problem nicht: Sie helfen nicht, die Kommunikation zwischen den Scrum-Teammitgliedern einer weltweit aufgestellten Organisation zu vereinfachen. Vielmehr sind sie zu Datenbanken, Reporting Tools, perfektionierten Bug Tracking Tools und Forecast Push Systemen degeneriert. Selbst bieten diese Wesen keinen Mehrwert – sie müssen sich der Lebenszeit von Entwicklern und Managern bedienen, um am Leben zu bleiben.

Dabei wäre es so einfach, ein wirklich funktionierendes, agiles Scrum-Tool zu entwickeln. Eines nämlich, das Arbeit beschleunigt und Kommunikation erleichtert, statt zu einer Belastung zu werden. Dazu bräuchte es nur ein paar Entwickler, die nach folgendem Rezept das perfekte Scrum-Tool bauen:

  1. Man nehme ein wirklich funktionierendes, d.h. stabiles Video Conferencing System wie zum Beispiel Google Hangout und verpasse ihm eine bessere Usability – sorry liebe Googles, das geht besser!
  2. Man füge eine Prise Telefoneinwahl international und kostenfrei hinzu – für die Teammitglieder, die während des Daily Scrums unterwegs sind (sorry, noch ist WLAN oder LTE auf deutschen Autobahnen und im ICE zu instabil – vor allem bei Hochgeschwindigkeitsfahrten).
  3. Dann mische man ein Whiteboard, eine Desksharing-Funktionalität, einen Persistent Chat und ein Taskboard hinzu.
  4. Nun braucht man noch die Möglichkeit, Texte auffindbar zu erstellen, die u.a. aber nicht nur an den Stories hängen. Deshalb integrieren wir ein Wiki, das sich aber bitte so wie ein Google Docs verhält.
  5. Für große Mengen an Bildern und Dokumenten brauchen wir noch Dropbox oder Evernote.
  6. Als Dessert nehmen wir noch einen integrierten Kalender, ein Shared Adressbook und eine E-Mail-Funktionalität.

Fertig. Alle zu Tisch, so kann man international arbeiten.

Ach so: Die Reporting-Funktionalitäten fürs Management lassen wir weg.
Fortschritte zeigen wir, indem wir fertige Produkte liefern – wir zeigen es nicht durch abgearbeitete Stories oder Tasks. Das ginge ja, wenn wir das Video-Chat-Programm so ausweiten könnten, dass wir ohne Probleme Demos auch für nicht Firmenmitglieder abhalten könnten.

Naja, ich träume. Aber ganz ehrlich, wir brauchen solche Tools. Die Entwicklung in der postindustriellen Netzwerkgesellschaft geht hin zu mehr Remote-Arbeit (work were you are), denn Teams kaufen sich die Kollegen dort ein, wo sie eben wohnen. Einer meiner Bekannten wohnt in St. Pölten (Niederösterreich) und arbeitet täglich für ein kalifornisches Unternehmen als Entwickler – warum auch nicht. Softwareentwicklungs-Teams können das heute. Andere Firmen werden folgen.

Wir müssen das möglich machen. Die Teams eines unserer Kunden arbeiten an zwei Orten in den USA, in China, in Indien und in München. Wir brauchen die Infrastruktur, um sie miteinander arbeiten zu lassen – und zwar produktiv. Und nein: Menschen zu einem Umzug oder hunderttausenden Flugmeilen mehr zu zwingen, ist keine wirkliche Alternative – weder steuertechnisch noch aus Sicht der Produktivität. Wissensarbeit braucht den Austausch, das miteinander Denken. Das geht in der Business Class des A380 nicht, da hilft auch die überfüllte Senatoren Lounge nichts mehr. Das ist nichts anderes als verlorene Lebenszeit.

Verteiltes, skaliertes und mulitkulturelles, grenzüberschreitendes Arbeiten wird zum Alltag werden. Kleine, schlanke Firmen werden das mit einer Symbiose aus den günstigen Lösungen wie Google HO, Confluence, Evernote und Dropbox stemmen. Große, unbewegliche Konzerne werden folgen – und dafür teure Enterprise Tools einkaufen. Vor allem müssen wir es schaffen, auch den multikulturellen Aspekt zu berücksichtigen. Schweizer, Österreicher und Deutsche – wir sprechen eine Sprache und meinen etwas völlig anderes. Ein elektronisches Board, dessen Sichtbarkeit auf die Größe eines Monitors beschränkt ist, muss also etwas anderes können, als beim Verschieben der Tasks die Farbe zu wechseln.

Related posts:

  1. 5 min on Scrum Tools
  2. Scrum Tools | VersionOne
  3. 5 min on Scrum | Tools

Categories: Blogs

Z is for Zukunftstag (#AgileFutureDay)

Scrum Breakfast - Fri, 08/15/2014 - 15:52
Agile is changing the world, but our schools are still preparing kids for the way world used to be. Would you like your kids to learn the ways of the future?

Thursday, November 13, 2014 is "Future Day" in Switzerland. Originally conceived as "Daughter's Day" to encourage fathers to take their daughters to work to experience non-traditional jobs for women,  it is now an annual opportunity for kids, usually in the 6th grade to get a day off from school so they can experience their parents at work and get a first taste of the real world.

My oldest attended one of my courses a few years ago (her insights were stunning, says the proud father) and this year, I will invite my youngest to attend.

Wouldn't it be cool if kids everywhere got a chance to experience the world of work, the way it should be? I'd like to call on trainers everywhere to invite the middle school aged children of their participants to join in their Agile, Lean or Scrum trainings on November 13th! Would that be cool? They can learn what collaboration can be! Let's make November 13th #AgileFutureDay!

P.S. I've got four spaces for kids on Future Day in my CSM course. No charge ;-)

Categories: Blogs

It is not the Process, Stupid

Leading Answers - Mike Griffiths - Fri, 08/15/2014 - 06:03
Even though Mickey Mouse is the symbol of Disney theme parks he is not really what these locations are about. Agile methods are similarly known by their novel processes and team ceremonies but these are largely irrelevant distractions from the... Mike Griffiths
Categories: Blogs

Posting Update

Leading Answers - Mike Griffiths - Fri, 08/15/2014 - 05:58
Thank you for visiting my site or subscribing to this feed. Regardless of how you access this content thanks for your patience. I have not been writing recently, instead using my spare time to enjoy the great summer weather we... Mike Griffiths
Categories: Blogs

The Agile Reader – Weekend Edition: 08/15/2014 - Kane Mar - Fri, 08/15/2014 - 04:20

You can get the Weekend Edition delivered directly to you via email by signing up here. The Weekend Edition is a list of some interesting links found on the web to catch up with over the weekend. It is generated automatically, so I can’t vouch for any particular link but I’ve found the results are […]

The post The Agile Reader – Weekend Edition: 08/15/2014 appeared first on Scrumology.

Categories: Blogs

Learn a new domain every year

TargetProcess - Edge of Chaos Blog - Thu, 08/14/2014 - 23:25

How diversity helps us in problem solving, creativity and overall intelligence? It helps a lot. Diverse groups of people can produce better results and radiate more creativity. But what about your own, personal diversity? Is it a good idea to accumulate knowledge from wide range of disciplines? Does knowledge of music theory help to write better code? Does knowledge from biology make you a better user experience designer? I believe yes, and here is why.


source: Escher Butterfly Wallpaper by MPCine

Douglas Hofstadter and Emmanuel Sander wrote a very controversial book Surfaces and Essences. It is not an easy read, but it is time spent well. Authors unfold thinking process from language to high level constructs. They show how analogy-making helps us think, generate new ideas and fuel our creativity, including scientific insights.

This book deeply resonated with me. In general I agree that analogy-making is a core of our creativity. I even tried to apply knowledge from Running domain to Software Development domain and generated some quite interesting ideas like Interval development. Sure these ideas can’t be proved easily, since analogy doesn’t mean the idea is great. But still it is relatively easy to take knowledge from one domain and apply it to another domain.

How can it help me?

All that brought me to the idea to increase my personal diversity and expand my knowledge beyond typical areas like system thinking, software architecture, groups dynamic, innovation models, user experience and other stuff every CEO learns. I read books and took courses about quite diverse topics already, but I did that in a chaotic way.

Suddenly it became obvious to me how all these new domains can help me to be more creative and solve problems better.

What domains should I explore?

I think you should try anything you always wanted to learn, but didn’t have time to. It is quite hard to predict what analogies can be generated from unknown domains. For example, you always wanted to know how people paint, how art evolved and how Michelangelo painted a fresco of The Last Judgement on the altar wall of the Sistine Chapel. Dig into the art domain and learn as much as you can in a single year. Will it help you to be a better software developer? Why not? If you try to paint something you can train patience and learn how to sketch (everybody should sketch, you know). Michelangelo’s approaches may give you some ideas how to structure your work. As I said, it is hard to predict exact ideas that you’ll generate in the end, but I promise you will generate some.

I personally want to study biology, music theory, architecture, education, medicine, go and swimming. If a simple running domain gave me new insights, I believe larger and more complex domains will bring even more value.

Why one year?

A year is a good timeframe to focus on something. It will be your new hobby for a full year. You can read 20+ books, take 1-3 online courses, maybe take offline courses, try to apply your new knowledge constantly. Small domains demand less time, but larger domains are hard to grasp in 2-3 months.

I don’t believe in quick solutions. You can read a book or two about a subject and have some fresh air in your head, but it is not enough to just scratch the surface. In 10 years you will have a decent knowledge in 10 domains. That sounds cool to me.

Did you try that?

Nope. I started to dig into music theory recently. So far I’m just sharing the idea with a hope that there is always a chance you’ll like it and give it a try.

And maybe, just maybe, you’ll even find your new passion. Who knows?

Categories: Companies

A is for Agile... and changing the world

Scrum Breakfast - Thu, 08/14/2014 - 17:53
We are uncovering better ways of developing software, by doing it and helping others to do it...

-- The Manifesto for Agile Software Development 
In 2001, seventeen people signed a 73 word statement that changed software development forever. Before: a bunch of guys doing "lightweight project management." After: a set of values which coalesced into a name, "Agile" and later into a movement. People identified with the values and transformed their working worlds with things like Scrum, Extreme Programming, Kanban, Lean Startup, and still other ideas and frameworks we haven't invented yet.

As we got better at developing software, we discovered the need for better ways at lot of things. The Agile movement inspired DevOps, which is looking for better ways to operate computer systems, and Stoos, which is looking for better ways of management. Soon, maybe scientists will look for better ways of conducting research, and maybe you will look for better ways of doing whatever you do.

How can you use the Agile Manifesto to help you? Start with the Agile Manifesto, find some colleagues who do what you do, and play with the Manifesto a bit. Not developing software? What is your essential goal or reason for being? Adjust the manifest as necessary to fit your situation. It probably won't need many changes.

So if you are in the HR department, what do you do? Maybe it is something like 'developing our human potential.' So what would a manifesto for agile human resources look like? Maybe something like this:
Sample Manifesto for Agile Human DevelopmentWe are uncovering better ways of developing human potential, by doing it and helping others to do it. Through this work we have come to value:
  • Individuals and interactions over processes and tools
  • Autonomy, mastery and purpose over documentation, directives and control
  • Collaboration over contract negotiation
  • Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.This is probably not quite right, but you get the idea. And it should be your manifesto, not mine, so feel free to keep working on it!
Want to change your world? Start looking for a better way! Maybe write your own manifesto... Want to find like-minded individuals, check out the Open Space event 24 Think Park in Zurich...

Categories: Blogs

SAP classic – agil

Scrum 4 You - Thu, 08/14/2014 - 07:35

“Softwareentwicklung” wird häufig mit Menschen assoziiert, die für eine Lösung Zeile für Zeile Code in ihrem Computer schreiben. Tatsache ist, dass viele Geschäftsprozesse von Unternehmen heute durch Standardsoftware abgebildet werden. Für eine neue Anforderung muss in dieser Software nicht zwangsweise wirklich neuer Code generiert werden. In vielen Fällen reicht ein „Anpassen“, das so genannte „Customizing“, der Standardsoftware aus. Aus diesem Customizing von Standardsoftware sind bei den bekanntesten Produkten ganze Geschäftszweige entstanden. Auf den Punkt gebracht spreche ich zum Beispiel von SAP-Beratern, die mit ihrer Expertise die einzelnen SAP-Module, auch als “SAP classic” bezeichnet, so anpassen, dass sie die Prozesse des Unternehmens abbilden und somit unterstützen.

Nun gibt es in der realen Business-Welt oft Projekte, die bereits vorhandene SAP-Module nutzen, aberpixabay_pdpics über reines Customizing der Software hinausreichen und das Modul mit maßgeschneiderten Zusätzen ergänzen. Und genau hier wird es spannend: SAP-Berater treffen auf Softwareentwickler. Warum, ist nicht ganz einfach zu erklären. Vielleicht sind es die unterschiedlichen Typen, die in den einzelnen Berufsgruppen anzutreffen sind, vielleicht sind es auch die unterschiedlichen Rollen – vielleicht aber auch etwas ganz anderes. Der Grund tut vielleicht gar nicht soviel zur Sache. Die Tatsache ist, dass ein solches cross-funktionales Team sehr gut, effizient und erfolgreich mit agilen Methoden wie Scrum zusammenarbeiten kann.

Ich habe in meinen Projekten die Erfahrung gemacht, dass sich gerade die Berater an diese neuen Teamkonstellationen gewöhnen müssen. Ihre Vorgehensweise ist oft geprägt von traditionellem Denken –  vor der Implementierung wird ein Konzept ausgearbeitet wird. Von Vorteil ist, dass dieses Konzept zumeist in intensiver Interaktion mit dem Kunden in gemeinsamen Workshops erarbeitet wird. Problematisch ist dabei häufig die fehlende Vorstellungskraft der Kunden, der Fachbereiche des Unternehmens. Für sie ist die Welt der Datenstrukturen, Objekte und Transaktionen äußerst irreal und zumeist zu komplex, um sie vollständig zu verstehen. So entstehen oft aus monatelang diskutierten und mit dem Kunden abgestimmten Konzepten erst recht wieder Prozessabbildungen im System, die den Anwender nicht optimal unterstützen.

Die gute Nachricht ist: Es ist möglich. Erfahrungen zeigen, dass Berater nebst Entwicklern in cross-funktionalen Teams in kurzen Iterationen miteinander arbeiten und so kontinuierlich Business Value liefern können. Customizing-Einstellungen und Codierung können so Hand in Hand in Form von User Stories erfolgen. Müssen verschiedene Möglichkeiten der Prozessabbildung doch einmal intensiver mit den Anwendern erarbeitet, besprochen und abgestimmt werden, so sollten diese Arbeitsschritte ebenfalls in Form von User Stories abgebildet werden. Ausgearbeitete und aufbereitete Entscheidungsgrundlagen entsprechen ebenfalls Lieferungen von Kundennutzen. Mit Hilfe der kontinuierlichen Lieferungen ist es dem Anwender nun auch möglich, nicht nur die Datenmodelle, sondern lauffähige Software zu begutachten. Im optimalen Fall kann er seinen Geschäftsprozess oder Teilprozesse davon bereits nach wenigen Sprints nutzen, um Feedback für das agile Team zu generieren. Alle Beteiligten können so durch die Anwendung agiler Methoden profitieren, auch oder gerade weil es sich in diesem Fall nicht nur um reine Softwareentwicklung handelt.

Related posts:

  1. In der Welt des SAP Customizings
  2. Scrum und Festpreis
  3. Teams – co-located, distributed, dispersed

Categories: Blogs

Business Capabilities and Microservices

Leading Agile - Wed, 08/13/2014 - 17:25

I don’t often use this forum to link out to other websites and authors, but I read a post last night by Martin Fowler and James Lewis that really gets to the heart of this issue around encapsulation, decoupling, and value streams I’ve been talking about lately.

The article does a great job of describing the problem and the end-state solution… it doesn’t say much about how to get there. Even so, I was impressed by the article and I wanted to share it with you guys in case you haven’t seen it.

I think this kind of architecture might be a prerequisite for true agile at scale, take a look:

UPDATE: Here is another interesting post I just discovered on Twitter by Richard Clayton highlighting some of the mistakes they made implementing this approach. Doesn’t invalidate the concept, just some good things to be aware of.

The post Business Capabilities and Microservices appeared first on LeadingAgile.

Categories: Blogs

People Are Not Resources

Johanna Rothman - Wed, 08/13/2014 - 15:06

My manager reviewed the org chart along with the budget. “I need to cut the budget. Which resources can we cut?”

“Well, I don’t think we can cut software licenses,” I was reviewing my copy of the budget. “I don’t understand this overhead item here,” I pointed to a particular line item.

“No,” he said. “I’m talking about people. Which people can we lay off? We need to cut expenses.”

“People aren’t resources! People finish work. If you don’t want us to finish projects, let’s decide which projects not to do. Then we can re-allocate people, if we want. But we don’t start with people. That’s crazy.” I was vehement.

My manager looked at me as if I’d grown three heads. “I’ll start wherever I want,” he said. He looked unhappy.

“What is the target you need to accomplish? Maybe we can ship something earlier, and bring in revenue, instead of laying people off? You know, bring up the top line, not decrease the bottom line?”

Now he looked at me as if I had four heads.

“Just tell me who to cut. We have too many resources.”

When managers think of people as resources, they stop thinking. I’m convinced of this. My manager was under pressure from his management to reduce his budget. In the same way that technical people under pressure to meet a date stop thinking, managers under pressure stop thinking. Anyone under pressure stops thinking. We react. We can’t consider options. That’s because we are so very human.

People are resourceful. But we, the people, are not resources. We are not the same as desks, licenses, infrastructure, and other goods that people need to finish their work.

We need to change the language in our organizations. We need talk about people as people, not resources. And, that is the topic of this month’s management myth: Management Myth 32: I Can Treat People as Interchangeable Resources.

Let’s change the language in our organizations. Let’s stop talking about people as “resources” and start talking about people as people. We might still need layoffs. But, maybe we can handle them with humanity. Maybe we can think of the work strategically.

And, maybe, just maybe, we can think of the real resources in the organization. You know, the ones we buy with the capital equipment budget or expense budget, not operating budget. The desks, the cables, the computers. Those resources. The ones we have to depreciate. Those are resources. Not people.

People become more valuable over time. Show me a desk that does that. Ha!

Go read Management Myth 32: I Can Treat People as Interchangeable Resources.

Categories: Blogs

Who should be in (agile) HR?

Scrum 4 You - Wed, 08/13/2014 - 07:41

In his short article “It’s time to split HR” Ram Charan proposes to split HR into an administrative department and a department for leadership and organization. His main point is that HR members need experience in other management functions such as i.e. finance. His criticizes that most of the current HR people cannot relate to business issues from the „real world“. I understand what his point is all about. People who study HR usually want to work with people and help them to release their potential. But this seems rather difficult as HR is mostly sitting in parts of the building with restricted access for “real world” people due to confidentiality reasons. The majority of them become experts in one specific field of HR (i.e. training, recruiting). Again, relating to business issues from the “real world” is rather difficult.

In an agile organization I would propose the ScrumMasters / agile coaches to take some of the HR duties. Mainly those that concern leadership and organization, but also, from time to time, administrative duties. Such a setup creates links to product development teams and their daily business issues. The ScrumMasters, being lateral leaders, know what it means to solve these “real world” problems – also known as impediments.

ScrumMasters are responsible for increasing the productivity of development teams. In order to reach their goal, they are supposed to change the organization as needed. Being involved in HR activities would be the perfect opportunity to create a link between the HR expertise and the “real world”. The adjustment of “People Systems”, as described by Jay Lorsch in the Strategy Pyramid, would be much easier. Also the other way round: the integration of the HR perspective into change initiatives would be given at any time.
What I also like about the idea of Charan is that HR is not a job position for life. Rather it should be a “pass through”, where one can gain experience in another field of management. In an agile organization this could mean that ScrumMasters and HR experts organize themselves in communities of practice. This way, they can work together and contribute to the success of the enterprise in different ways, for example like this:

  • ScrumMasters could fill a full-time HR position for a certain period of time .
  • ScrumMasters and their teams could participate as pilots for new concepts developed by HR.
  • ScrumMasters could be friendly users for i.e. new concepts of leadership training etc.
  • Engagement in different phases of the development process of new “people systems” is also possible (proposing ideas, defining the concept, collecting feedback etc.)

For a limited amount of time, ScrumMasters can be solely engaged in HR activities. Still it is mandatory that they return into leading a team after a certain HR deliverable has been released. An HR deliverable could be a new training, a cultural change that is clearly visible, new processes etc. But not only ScrumMasters can engage in HR topics, also other team members can take part in the communities of practice. How? The ScrumMasters and HR experts will find a way!

Related posts:

  1. Organisations need to understand …
  2. 5 minutes on management
  3. Massive Multiplayer Online Games the Digital Business School of the Next Generation

Categories: Blogs

Who killed Agile?

Agile Thinking - Dhaval Panchal - Wed, 08/13/2014 - 00:28

Arthur Carrera from Electric Cloud posted an excellent blog about the session that I led at the Agile Conference 2014 in Orlando. Here is a link:

Nailed it!

Categories: Blogs

Axosoft at the Agile2014 Conference

About SCRUM - Hamid Shojaee Axosoft - Tue, 08/12/2014 - 17:52

Agile 2014

We traveled to Orlando, Florida last week for the Agile 2014 conference. It was a blast!

As Arizonans we are no strangers to the heat, but dry heat is an entirely different experience than being immersed in 80% humidity. Upon arrival in Orlando, we braced ourselves for the balmy weather and were much relieved to arrive at the Gaylord Palms Resort and Convention Center. For those of you who have never been, Gaylord Palms is like a biosphere: a temperature controlled, naturally lit, plant thriving oasis!

gaylord palms resort

We were happy to set up in the expo hall right in front of the entrance doors. If you were there, there’s no way you could have missed us! We readied our booth with plenty of Axosoft swag – Scrum mini guides, Agile Notetakers, Tego Audio Nova speakers, and stress-ball ladybugs – then welcomed the first wave of conference attendees.

Axosoft booth

We had lots of great conversations with project managers, developers, Scrum masters, agile coaches, and the like. Many were drawn into our booth by our cute ladybug stress-balls representative of our recent decision to price Axosoft Bug Tracker at only $1!

Axosoft Bug Tracker

With ladybugs in hand, people wanted to know what makes us different from our competitors. Many of you who are already familiar with Axosoft know that we are much more Scrum focused than JIRA, Rally, VersionOne and other Agile softwares. For instance, we have a new Daily Scrum feature that no other agile or Scrum software has to facilitate daily standup meetings. Lots of attendees started envisioning their teams using this feature.

Daily Scrum

People also loved our clean UI and many people stopped at our demos when they recognized our custom dashboards from the hit HBO show Silicon Valley.

Scrum Dashboard

All in all we had a great time talking to current and prospective Axosoft users at our booth. We were also happy to mingle with many  more great people and even a mermaid!  We came away from this conference with lots of great insights and ideas we will be bringing to Agile2015; hope to see you there!


Categories: Companies

Scrum Knowledge Sharing

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