Does the Agile Organization Supersede the Matrix?

During my Business Economics and Information Systems master study at the University of Groningen I was introduced to organization design scholars like Henry Mintzberg. He captured different organizational structures in his famous Structures in Fives (1983). While the matrix organization operated by both function and product with the project as well-known manifestation is nothing new, recent management literature seems to reinvent wheels. The adagio Keep it Simple, Stupid (KISS) should be the golden rule.

Matrix organization in 1983

Mintzberg stated in 1983: “No single basis for grouping can contain all the interdependencies. Functional ones pose work-flow problems, market-based ones impede contacts among specialists, and so on. (…) By using matrix structure, the organization avoids choosing one basis of grouping over another; instead, it chooses both. (…) As a result, matrix structure sacrifices the principle of unity of command. (…) Two kinds of matrix structures can be distinguished: a permanent form, where the interdependencies remain more-or-less stable and so, as a result, do the units and the people in them; and a shifting form, geared to project work, where the interdependencies, the market units, and the people in them shift around frequently. (…) Matrix structure has its share of problems. Although it seems to be a most effective device for developing new activities and for coordinating complex multiple interdependencies, it is no place for those in need of security and stability. Dispensing with the principle of unity of command creates considerable confusion, stress, and conflict, and requires from its participants highly developed interpersonal skills and considerable tolerance for ambiguity.” (p.85-88).

I don’t think I really understood everything in these sections while studying Structures in Fives in 1992. Now, in hindsight, I share the experiences of effectiveness and problems.

Forget tradition, let’s try something new!

Mimicking the ‘cut the middleman’-approach in insurance, many large organizations formerly true examples of the Divisionalized Form in Mintzberg’s Structures in Fives, tried to flatten their organization at the dawn of the new century. Middle managers weren’t safe of their position anymore. Recent moves towards organizational agility showed a further decoupling of managers and their teams. Self-organization is the new mantra, something to believe in. More middle managers were fired. Spotify-ing organizations led to copying grouping mechanisms of expertise and product-centricity. Squads and guilds, tribes and communities of practice, like in the Middle Ages, where craftsmen all lived next door.

Projects? You must be kidding, Scrum doesn’t say anything about projects, so these are nonexistent. Project manager? Pity you, redefine yourself as an agile coach or be fired. Project management methods like PRINCE2? So 2003! Waterfall? Definitely the common enemy among agilists. Many millennials say they don’t value it, while they’re still practicing sequential stage-based lifecycles, culturally not yet embracing the agile mindset one talks about in conferences.

Where’s the manager if you need him?

Studying the Leading SAFe course material in Spring 2017, it stood out. Management cannot simply walk away. Scaled Agile Framework (SAFe), one of the leading frameworks for scaling up agile practices throughout a large organization has a clear role for management. Turning back to W. Edwards Deming quotes like “It is not enough that management commits themselves to quality and productivity, they must know what it is they must do. Such a responsibility cannot be delegated.” are a call to action: manager, manage.

Self-organizing professionals have a limited reach. Either the late Stephen R. Covey or a random developmental psychology professional taught you that people must understand the interdependencies in a group. Every group needs a leader to avoid inertia, someone to trigger processes, guide the way towards a goal, hire and fire, inspire, integrate, motivate, and set the example. To value a coach more than a manager disguises a blind spot, the emperor’s new clothes set in today’s organizations. The Dutch book Ga Toch Leidinggeven! – Een Manifest Tegen Overmatig Coachen (2013), roughly translated as Go and lead! A Manifesto against excessive coaching is meant as reality-check for all coaches out there.

How would you call this role?

A recent job post by a large bank that has kicked out all project managers in favor of squads, guilds, and tribes reads: “You coordinate activities in various backlogs of squads and ensure consistency. Align architecture, infrastructure, and software. You support the squads aligning various features. You manage towards incremental delivery. You facilitate quick decision making by reporting feature delivery status. You ensure that all (IT) stakeholders are aligned. You’re inspiring, passionate and energized. You have a strong market focus on IT (e.g. Lean IT, continuous delivery, cloud processes) You focus on collaboration. Your ego has less priority than reaching the best result. You facilitate others to be successful. You’re capable of absorbing knowledge quickly in order to share it. You ask for help and feedback but give feedback as well. You’re eager to innovate. You collaborate and have a mindset of continuous improvements. You’re not afraid to try new things. You are experienced in management in an agile organization. Managing various internal and external vendors and working in complex programs is your second nature. You’re an experienced coach, and manage outputs. You’ve strong analytical skills and lots of experience as IT integrator.”

Project manager, right. Another large bank, while massively turning into a Spotify meets SAFe organization without project managers model for its IT asked for a project manager to implement DevOps in a team. Why? Project managers, and hopefully managers in general, learned to organize, lead, manage, direct, inspire, solve organizational problems.

I’m called a road manager nowadays at a Dutch Spotify adept in Financial Services. Road managers are internally advertised as the ones to help:

  • coordinate
  • accelerate
  • connect people
  • plan roadmaps
  • authorize work packages, etc.

Autonomy?

I have to operate without a dedicated project team, without any formal position or power. Leading is still influencing people to get things done. The matrix organization is alive and kicking with squad members functionally reporting to chapter leads, and in their working field to tribe leads via their product owners and scrum masters. Externals have their own reporting lines as employees of their respective companies.

I can’t help but lean on my years of Greek education. So I know the etymology of ‘autonomy’. Can you really set your own rules as squad / Scrum team member? I don’t think so. There’s a lot written on autonomy as a driver for the modern worker. Daniel H. Pink regards it as one of the 3 motivators purpose, autonomy and mastery in Drive. John Hermarij laughs about it, and recommends you to become a self-employed professional if you really want to have autonomy. Marketingfacts shares wonderful thoughts: “Alignment and autonomy are no opposites. Experience teaches us that alignment makes autonomy possible.” Something to think about. Trust is key, I suggest, feeling comfortable with Patrick Lencioni (Overcoming The Five Dysfunctions of a Team) supporting me.

A less visible manager in the matrix organization is something that you earn. Delegation is fine, unless performance is insufficient. Karel van Berckel in 1999 published a book on self-organized teams (Zelfsturende teams: doelen, processen, valkuilen, tips). There no blueprints, silver bullets. Many organizations experiment, try to move around the many pitfalls.

No blueprints? Are patterns for agile organizations useful?

Since 1999 we should have gained more insights and experience in organizational development. Nowadays at least four patterns for enterprise agility are available:

  1. Agile portfolio management – fit for future
  2. Scaling agile – fit for enterprise
  3. Enterprise-wide DevOps – fit for lifecycle
  4. Agile SIAM (service integration management) – fit for integration.

The way Fred A Cummins in Building the Agile Enterprise (2017): “In the agile enterprise, we combine the workforce shift to knowledge work with shared capabilities and a network of services, contributing to value streams that deliver enterprise values. Service units provide enterprise capabilities that can be engaged in a variety of enterprise pursuits. This is a sort of “hyper-matrix” structure because collaborations are connected by deliverable flows; value streams; responsible organization units; delegations from service to service; delivery of events; and teams for planning, coordination, innovation, problem-solving, and other purposes that involve inter-organizational participation.
The management hierarchy in an agile enterprise is a hierarchy of organization units responsible for budgets, personnel, and other resources, from the collaboration of top management to service units with people who do the actual work of the enterprise. The grouping of organization units under a parent organization unit brings together organization units that have similar capabilities and operating characteristics that enable them to work together for economies of scale and comparable leadership and incentives. The organization hierarchy is not about products, but about capabilities.

A hierarchy of organization units forms the traditional management hierarchy that is extended to additional collaborations that manage resources such as project teams and business transformation initiatives. A capability method is performed by an organization unit that is responsible for the assignments of people, availability of resources, and management of capability method performance. Interorganization collaborations define interactions between members of different organizational units to do work for enterprise purposes ranging from transformation planning to ad hoc problem resolution meetings. The network of collaborations involves all of the people engaged in the work of the enterprise, many people in multiple collaborations. Most of these collaborations are not represented in typical organization structure diagrams.”

And so, in 2017 we’re still having matrix organizations and a place for project management skills to bring to the table 🙂

Agile Product Management Examined

A tag cloud on product management shows much more than the average product owner of a Scrum team may recognize. Product development is broader than just software development or executing changes to the IT infrastructure. Think of a new car, iPhone, or solar panel.

On Wednesday 21 June I had the opportunity to present views on product management to the Capgemini Agile Community of Practice in a webinar. Why not share the ideas with you?

New product development described

According to the Wikipedia lemma:

  • In business and engineering, new product development covers the complete process of bringing a new product to market.
  • New product development is described in the literature as the transformation of a market opportunity into a product available for sale.
  • The product can be tangible (something physical which one can touch) or intangible (like a service, experience, or belief).
  • A good understanding of customer needs and wants, of the competitive environment and of the nature of the market represents the top required factor for the success of a new product. Cost, time and quality are the main variables that drive customer needs. Aiming at these three variables, companies develop continuous practices and strategies to better satisfy customer requirements and to increase their own market share by a regular development of new products.There are many uncertainties and challenges which companies must face throughout the process. The use of best practices and the elimination of barriers to communication are the main concerns for the management of the process.

Notice the difference between product development and:

  • Deploy bug fixes.
  • Steal features of another application and embed it in yours, like Facebook does with SnapChat and Instagram.
  • Implement feature requests in build 1.18.346.

Six Myths of Product Development

Harvard Business Review five years ago identified six myths on product development, which still is recognizable in 2017:

  1. High utilization of resources will improve performance. Possibly fired-up is confused with burn-out. Passion, purpose fuel performance, a sense of autonomy and mastery support performance, but simply increasing the number of resources or utilization of available resources cause negative stress.
  2. Processing work in large batches improves the economics of the development process. That’s where Lean principles kick in. Limit work in progress and batch sizes.
  3. Our development plan is great; we just need to stick to it. You would think that the principle “planning is useful, plans are worthless once these hit reality” would be adhered to by more people nowadays.
  4. The sooner the project is started, the sooner it will be finished. I never was in that kind of projects. Starting a project too soon may ignore risks, weaken the foundation, etc.
  5. The more features we put into a product, the more customers will like it. Which customer actually asked for iTunes becoming a media player, music library, podcast subscription machine, web shop, a lifeline to your iPhone/iPad? Who submitted the feature list for a $600 smart watch?
  6. We will be more successful if we get it right the first time. If quality expectations are made explicit, the team is mature, etc. this could be possible. In reality, failures belong to life. Thomas Edison ‘invented’ the light bulb after thousands of failed experiments.

When speed is of essence…

The selling point of Agile methods (e.g. Jeff Sutherland‘s book Scrum: The Art of Doing Twice the Work in Half the Time) also applies to product development in general. What five things make Zara and H&M successful?

  1. Constant level of new products
  2. Clear strategy on discounting
  3. Focusing on core customers
  4. Consistency in price architecture
  5. Communicating your brand’s identity

Other examples

  • Amazon Prime: Mastery of order fulfillment for the customers. Guaranteed two-day delivery on all products which are prime eligible.
  • Jimmy John’s: Freaky fast. The company even faced some lawsuits for being too fast in their gourmet sandwiches business including safety measures.
  • General Electronics:
    • Anew product announcement of GE appliances was held every 90 days.
    • The GE90, the world’s most powerful commercial jet engine was built and designed in half the normal time it takes to build a jet.
    • GE team developed breakthrough ultrasound innovation in less than a year.

…is this beneficial?


What’s needed:

  • Shorten the lead time to implement
    • Will multiple feature or component teams work on a single product help?
    • Is a Program Increment after 90 days using SAFe soon enough?
    • Continuous Integration / Continuous Delivery
  • Collect feedback from customers ASAP

The intended coverage of current agile frameworks

Scrum is a framework for developing and sustaining complex products. Scrum is a process framework that has been used to manage complex product since the early 1990s. Scrum is not a process or a technique for building products; rather, it is a framework within which you can employ various processes and techniques. Scrum makes clear the relative efficacy of your product management and development practices so that you can improve.

The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals. The Product Owner is the sole person responsible for managing the Product Backlog. §The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner.

In the Scaled Agile Framework (SAFe) responsibilities of Product Management in an Agile Release Train are:

  • Understand Customer needs and validate solutions.
  • Understand and support portfolio work.
  • Develop and communicate the program vision and roadmap.
  • Manage and prioritize the flow of work.
  • Participate in PI planning.
  • Define releases and Program Increments.
  • Work with System Architect / Engineering to understand Enabler work.
  • Participate in demos and Inspect and Adapt.
  • Build an effective Product Manager / Product Owner team.

Five strategies to agile product development

To shorten the time to market, Insurance Innovation Reporter identified five strategies. I added examples to illustrate the importance.

  1. Explore a greenfield strategy.
    1. Moving from airbed & breakfast during a conference to earn some money to Airbnb.
    2. Moving from a DVD rental site to enabler of binge-watching a.k.a. Netflix.
  2. Lead the way, be a trailblazer.
    1. The alcohol-free beer Buckler was introduced in 1988 by Heineken, and quickly dethroned Clausthaler. Jokes on Buckler by the Dutch comedian Youp van ‘t Hek however in 1989 caused too much reputation damage. Buckler was withdrawn from the market. Quite surprisingly Heineken introduced an alcohol-free beer in March 2017 (!), after all large beer brands had introduced Radler sub-brands.
  3. Never stop experimenting.
    1. Think of Thomas Edison again. It doesn’t matter whether he tried over thousand or ten thousand failed experiments (try to find the correct answer on Google), only at last he got it right. The light bulb’s history.
    2. One small team cannot run parallel experiments to solve complex problems (fast enough). The consciousness of an overarching problem, call it an (unknown) common enemy is needed. Examples are the Manhattan Project to develop the atomic bomb, and the X-15 models to test rocket boosters in the midst of President Kennedy’s assignment to bring a man to the Moon and return safely.
  4. Invest in an open distribution platform.
    1. The Payment Services Directive (PSD2) led to open APIs for financial data.
    2. Moving from products to platforms e.g. AliExpress, Uber, Airbnb, Salesforce, Bol.com.
  5. Ensure trusted partners have agile platforms.
    1. What’s your place in the value chain?
    2. Supply chain logistics – economies of scale versus Lean, and experiments. Examples are Toyota Production System, Ahold Delhaize, Lidl, and Aldi.
    3. Maybe closer to the home of an IT department:
      1. Continuous integration, automated testing versus shippable software after a sprint.
      2. Agile development in a fixed time, fixed scope, fixed costs, and fixed quality contract.

Wrap up

  • Product development is much more than software alone.
  • Our current agile frameworks are still focused on software instead of products.
  • Strategies for Agile product development are good practices

Verslag 20e BPUG seminar – Next Practices

Een ‘best practice’ beschrijft een manier van werken waarbij in de praktijk is bewezen dat de uitgevoerde activiteiten de meest efficiënte en effectieve manier zijn om gewenst eindresultaat of doelstelling te realiseren. Best pretentieus, en zeker niet toekomstvast. De tijden veranderen en zo ook veel van de eisen die aan de praktijk van de project management professaional gesteld worden. De Best Practices User Group Nederland, ooit begonnen als PRINCE2 User Group wil dinsdag 13 juni met het 20e seminar verder kijken. Wat zouden next practices, ofwel ‘the next best practices’ kunnen zijn? Toekomstgericht, zonder het verleden uit het oog te verliezen. Eén van de principes onder bijvoorbeeld de projectmanagement methode PRINCE2 is immers het leren van ervaringen.

Hajati Wieferink – Een paradigmaverschuiving

De ruim 400 deelnemers vandaag verwachten van de seminarcommissie misschien wat huishoudelijke mededelingen en aandacht voor de sponsoren, zonder wie deze dag niet mogelijk zou zijn. We krijgen van Hajati Wieferink daarna echter een blended version voorgeschoteld van Clare GravesSpiral Dynamics, Frederic Laloux‘s Teal paradigm (beschreven in zijn boek Reinventing Organizations), en Bob Marshall’s Rightshifting Model.  Voor de geïnteresseerden alvast de laatste mannen zelf aan het woord.

Hajati Wieferink duidt next practices in rightshifting modelKleurentheorieën om fasen in de ontwikkeling van de mensheid, organisaties en raamwerken om de veranderingen teweeg te brengen te duiden. Soms lijkt het een soort Henry Mintzberg (Structures in Fives) meets Nicoline Mulder (Value-based projectmanagement: een aanpak voor chaordische projecten) in de beweging van ad hoc – analytic – synergetic – chaordic.

Wieferink vraagt aan de zaal waar de deelnemers hun eigen organisatie ‘plotten’, maar vermoedt dat er ook principiële niet-handopstekers zijn. Ja, ik ben er één van tijdens dit minicollege. Ik zie eerder trekjes van verschillende ‘kleuren’ in de organisaties waar ik opdrachten uitvoer. Niemand, dus ook niet een organisatie past in precies één hokje. Het eigen mensbeeld strookt niet per se met de organisatiepositie. En dan verwachten veel mensen agile misschien wat meer in het rechter deel van het Rightshifting Model. Nee, met het empiricism als basis is Scrum en dergelijke natuurlijk behoorlijk analytic.

De modellen zijn ook een kapstok om de sprekers en hun onderwerpen uit de rest van het seminarprogramma een plek te geven. De BPUG heeft daarbij gestreeft vooral invulling van de breuklijnen, de faseovergangen te geven, en zo te inspireren.

Keynote Jan Flippo – Je zult maar CIO van Amsterdam zijn

Jan Flippo duidt digitale transformatie bij gemeente AmsterdamJan Flippo is 5 jaar werkzaam als CIO van de stad Amsterdam waar hij verantwoordelijk is voor het inrichten van een nieuw IV-stelsel, governance en de aanpassingen van de organisatie om invulling te geven aan de grote stedelijke opgaven en terugdringing van de daarmee samenhangende uitgaven. Hij veegt direct de vloer aan met de zojuist gepresenteerde kleuren en modellen. Als je iets van orde in een chaos van tientallen uitvoerende IT/IV-organisaties, duizenden applicaties, tientallen netwerken, datacentra, etc. moet scheppen, waarbij besluitvorming langs 10+ schijven met een doorlooptijd van minstens 2 maanden duurt, past bescheidenheid.

Burgemeester & wethouders beslissen uiteindelijk, als CIO wordt je gedoogd en kun je niet op macht of positie bogen om wat gedaan te krijgen. Zelf doen of op de markt betrekken of in partnerships? Waterval èn agile, mensen koesteren en dus niet vanwege een ‘non-agile fit’ ontslaan. Zijn eerste lustrum ziet Flippo als corvé. Ontwikkelingen als Internet of Things en de praktische uitingen van het containerbegrip Digital Transformation ziet hij als duw om constant te blijven doorgaan. Er is geen goed, en dus moet er geprobeerd, geslaagd èn mislukt worden.

Het gaat wat Flippo betreft om verbinden, samenwerken en dienen zonder macht of positie. Hij nomineert deze combinatie als mogelijke next practice.

Ben jij de katalysator van Next Practice?

katalysator van de veranderingSonja van Steekelenburg – De Energieke Schakel- moet het vandaag alleen doen. Haar partner Carla Roebroeck – Positief werk(T) is ziek. Ze zet deelnemers bij binnenkomst meteen aan het werk. Ga het gesprek aan, verbindt aan de hand van vragen als ‘Wat gaat jou moeiteloos af?’ of ‘Waar mogen ze je ‘s nachts altijd voor wakker maken?’.

Daarna mogen we in kleine groepen ervaringen delen en elkaar helpen om een thema dat mij (ik had de langste reistijd gehad vanochtend, en dus mocht hoe dan ook mijn thema als casus inbrengen) bijzonder raakt of bezighoudt en relevant is voor mijn werk te delen. Welja, dat is dus in de basis veranderen zonder positie. Met nieuwsgierige, open vragen mogen de anderen het onderwerp aanscherpen en uitdiepen.En dan dromen. Over 5 jaar wordt dit congres weer gehouden. En jullie wordt gevraagd een best practice te presenteren over dit thema. We komen als groep op de volgende gedachten:

  • Er is nog amper een traditionele lijnorganisatie.
  • Organisatiestructuren zijn er minder.
  • Er zijn meer practices ontwikkeld voor team- en organisatiegrootte, type medewerkers en vaardigheden die nodig zijn in de adaptieve organisatie.
  • Er is bepaald wat nog “hiërarchisch” geregeld moet worden in organisaties.

De kans is groot dat dit weblog over 5 jaar nog goed terug te vinden is. Dus check in 2022 vooral of onze droom is uitgekomen. En bam, dan zit ook deze 45 minuten er alweer op!

Doen we het beter dan de dino’s?

Tanja van den Akker MBA is mede-eigenaar van Forsa Advies, geaccrediteerd trainer in project- en verandermanagement en auteur van ‘PRINCE2 voor Professionele Projecten’ en ‘Verandermanagement, basisprincipes en praktijk’.

Zij gaat na Pangea: The Neverending World uitgezet te hebben, langs de verschillende kleuren en stadia uit het Spiral Dynamics model en vraagt de zaal zichzelf en de organisatie waar men werkt te plotten. Dus zien we de pendule tussen individu en groep bewegen langs de kleuren:

  • beige – overleven
  • paars – geborgenheid
  • rood – macht
  • blauw – orde
  • oranje – succes
  • groen – gemeenschap
  • geel – systeemdenken
  • turkoois – holistisch

Gelardeerd met scènes uit speelfilms, voorbeelden van het thuisfront en werk vliegt ook hier de tijd voorbij, maar niet zonder een aantal next practices te belichten:

  • Zelfbewustzijn, maar ook het beheersen van het ego.
  • Vergroten van het vertrouwen.
  • Sociaal ondersteunen.
  • Zelforganisatie en -sturing.

Cameron Stewart – PRINCE2 2017 and the future of best practice

Axelos' Cameron Stweart projects the next 5 years in project managementCameron Stewart (AXELOS) heeft een aantal boodschappen te vertellen. PRINCE2 2017 is uit – het elektronische manual heb ik al een paar maanden, en ook gelezen; donderdag ga ik examen doen als geaccrediteerd trainer – en dat mag de wereld weten. Meer nadruk op tailoring en agile delivery in a controlled context. Vanaf Q1 2018 komen het bijgewerkte Nederlandstalig PRINCE2 boek en examens beschikbaar. Vanaf juli 2017 eerst alleen in het Engels. De vierde revisie van de methode is begrijpelijker, maar behoudt vrijiwel alles van het raamwerk. Er is een nieuw lidmaatschapsmodel om bijblijven in je vakgebied aan te tonen.

AXELOS beheert veel meer producten en zal in rap tempo doorgaan met uitbrengen van nieuwe raamwerken. Later dit jaar komt een op organisaties gericht ‘thing’ om te kunnen overleven. Waarom? Omdat de context van organisaties, BAU en projectmatig werken verandert. Stewart blikt 5 jaar vooruit en besluit zijn keynote met een appèl aan de projectmanager om vooral ‘the skin in the game’ te hebben.

De keynote van Richard Pharro (APMG) mis ik vanwege de nodige calls en mails op het project, het ‘echte’ werk, dat ook vandag gewoon doorgaat.

Hoeveel ‘Next Agile Practices’ kunnen we overzien?

Henny Portman licht agile methoden en frameworks toeIk schuif weer aan in de grote zaal, als Henny Portman , na ING/NN-meubilair te zijn geworden, nu partner bij HWP Consulting is. Behalve consultant, is Henny spreker, coach en trainer van zowel traditioneel projectmanagement (MoP, MSP, PRINCE2, P3O) als agile aanpakken waaronder PRINCE2 Agile en SAFe. Henny Portman is met zijn PM blog onlangs door Project Directors uitgeroepen tot “Blog of the Year”. Hij schrijft hij af en toe een boekje. En, wat een toeval, vandaag wordt zijn nieuwe boek Scaling in organisaties aan alle andere sprekers meegegeven als bedankje.

Als teaser neemt hij ons mee in het woud met intussen 30 frameworks voor agile ontwikkelen. Wat is de plek van de projectmanager en de (de)centrale PMO in dit geweld van Scrum, SAFe, DAD, Nexus, Scrum@scale, LeSS of Spotify? Dat kan bij tijdelijk uitdijende veranderoirganisaties of bij blijvend inrichten van portfoliomanagement nog heel goed. Voor de rest is het toch een afscheid van veel traditionele projectmanagement- en PMO-functies in organisaties die overstappen op agile.

Op engineering level ziet Portman overigens ook een leemte. HIer kunnen practices als XP, CI/CD en automated testing nog steeds veel waarde toevoegen. De agile smaken op portfolio level zijn er nog maar deels en vergen dus ook doorontwikkelng. Het blijkbaar onlangs uitgebreide Scrum@scale en de komst van Nexus+ geeft mij huiswerk. Portman ziet gevaar in de zombie teams, zoals er eerder zombie projecten en zombie medewerkers waren. Als mogelijke next practices ziet hij de overgang van project naar flow, plan naar value en controller naar advisor.

Back to the future 4

Clemens Bon en Frank van Dam zijn pensionado’s die hun kennis en kunde als wetenschappelijke raad van Oppidum delen. We krijgen in kleine groepen de opdracht te beschrijven wat er in projectmanagement veranderd en ongewijzigd is gebleven in de afgelopen 20 jaar. Ja, principes en thema’s zijn hetzelfde gebleven. Het blijft mensenwerk, communicatie is cruciaal, er zijn plannen en beheersing. Toch zijin er forse accentverschillen, zoals de verschuiving van vuistdikke methoden als SDM naar een Scrum Guide van 16 pagina’s. Maakt dat allemaal significant verschil voor de slagingskans van projecten? Volgens de Standish Group niet. Nog altijd slaagt maar 30% van de projecten. Grote slagen kan de performance maken als (project)organisaties van volwassenheidsniveau 2 naar 3 gaan.

Ik moet helaas afhaken op het moment, dat de groep de opdracht krijgt te beschrijven welke practices nu het verschil tussen 30 en 60% kans van slagen gaan maken. Opnieuw roept de plicht van een conference call voor mijn project. Daarmee heb ik ook geen idee of mijn visitekaartje dit jaar opnieuw ergens in de tombola getrokken is. Ook de netwerkborrel gaat aan me voorbij. Het is wat als practitioner 😉

 

Kanbanize, agile process management software tested

With a lot of JIRA and Trello usage hours on my resume, I was invited to test Kanbanize. Kanbanize is an Agile process management software built around the lean values and the idea of Kanban boards. Unique selling points are the industry business automation engine, Actionable Agile integration, and highly customizable user interface.

Kanbanize propels you miles beyond the electronic Kanban board with a couple of swimlanes, WIP indicator, and drag-and-drop functionality of stories. A free 30-day trial account in Kanbanize provides access to all features in the system with almost no restrictions.

Main features

  • Kanban boards
    • Visualize your progress as you move cards across the board at the project, team or organization level.
    • WIP limits per column, swimlane or user.
    • Role-based access. The Kanban board allows you to define custom roles and assign unique permissions to users by projects and boards. To grant access selectively, a member with elevated privileges in one area of the project may be simultaneously restricted in another.
    • Flexible card views & filters. As you populate your Kanban board, you will have to navigate different types of cards. To make sure you are seeing only what you need to, adjust which card attributes are hidden from view or use our board filter to show a selection of the cards on your board by priority, color, assignee or by searching a keyword.
    • Card templates, handy when you need to create complex cards with predefined attributes and subtasks quickly. All types and templates function on a per project basis and you can manage them easily through your online board settings.
    • Custom fields. Every team is different and each will have specific needs based on what they want to achieve. You can choose types for the fields (text, number, date, multi-choice, etc.) appearing in the structure of a card and make some fields mandatory for one digital board or optional for another. Custom fields are even supported in the analytics module so you can slice the data of the chart to show each one separately.
    • Reminders and follow-ups. When you have a lot of things on your list, forgetting something seems inevitable. The subscription-based notifications system in Kanbanize lets you rest easy while we keep track of your deadlines for you. If you want to be pinged about an approaching deadline, we will send you an email with a link to the task to be followed-up.
  • Links between cards. Complex projects involve a lot of work items and, with no special care, visibility is quickly lost. Link Kanban cards in different boards and get the ultimate visibility you need to execute successfully.
    • Parent-child hierarchy.
    • Mirror cards.
  • Run time policies, comparable with IFTTT recipes. If triggers occur, then perform a certain action e.g. move parent card, remind your team by email of reached WIP limit or queues than the need to be replenished. Triggers and actions can be used in a bi-directional way.
  • Email integration. Kanbanize not only sends out emails on certain triggers but also can update cards from email messages. Adding comments or triggering movements of cards are good examples.
  • Time tracking. Hours spent can be logged on cards, and user for aggregation and reporting.

The product is updated monthly. While the video below highlights 5.1 features, March 2017 version already is at 5.7, including SSO, archive and new integrations. May 2017 5.9 release showed an acceleration of the Kanban boards performance, legacy applications connectors, etc.

Price plans

Flexible pricing scheme based on usage and not just number of users. Check the online information.

Kanbanize vs Trello

  • Kanbanize is the true implementation of Kanban.
  • Customizable swimlanes.
  • WIP limits for individual users, columns or even specific cells.
  • Automation with Runtime Policies – from smart notification to automated card movements, updates, changes, invoking external services, blocking other cards or manipulating linked cards.
  • Powerful search + custom reporting. Search filters can be saved and shared like external pages or widgets on the main Dashboard. A custom search can be used for metric-specific reporting that is relevant to your specific needs.
  • 2-way external integrations, including email (card creation, updates, and movement over email + ability to respond to an email from within the board), Slack, most cloud storage services, GitHub, and more.
  • Links, relationships and hierarchical dependencies between cards (predecessor cards must be completed before successor cards could be moved to In Progress.
  • Time tracking (both automatic and manual input).
  • Productivity Analytics – clean visualization of bottlenecks, Cycle Time trends, cards distribution, efficiency widget.
  • Premium Analytics for statistical predictions and deeper data analysis.

Kanbanize vs Jira

  • Kanbanize is built for Kanban, its user interface and the system itself is designed to facilitate Kanban application and let teams make the most of it
  • Kanbanize is much easier to set up, but it still allows an incredible degree of customization
  • User-Friendly drag-and-drop interface.
  • While tasks can only be assigned to one person, subtasks could be owned by other users + there can be a custom Contributor field to show someone else pushing the card.

Kanbanize vs other Kanban tools

On Wikipedia, a comparison of Kanbanize with other Kanban tools is available, although not necessarily up-to-date.

Pride – In the Name of Agile Only

Is Agile the holy grail for organizations struggling to get the time to market of their products and services? Is Spotify-ing your business the only way forward? Is Agile a binary option like you’re in or out? And what if you scale up the agile way of working while an inspection on team level would reveal many deviations from the theoretical or original setup? Is your company pride based on false assumptions? Let’s dig into these questions.

Agile ≠ Scrum

Scrum is just one of the agile frameworks out there to support complex product development. Scrum is a lightweight framework with a limited set of roles, events, and artifacts. An agile team or other organization needs more than a process framework. Behaviors, principles or values, and tools are important as well. Scrum itself will not make you agile, neither does a tool like Atlassian‘s JIRA, a mandatory in-house training or certification of all your former project managers as Professional Scrum Masters. A tool, process or technique is there to help you, guide you. Adherence to principles like the ones in the Agile Manifesto, as well as daily visible behaviors that enable your team(s) to produce and improve are key. Remember that the Agile Manifesto is not defining Agile. It’s a manifesto of shared convictions expressed by a community of representatives of iterative and incremental software development methods and frameworks. There’s no owner of agile, or independent supervisor determining who is and who is not agile.

So, no one can blame you or excommunicate from the ‘agile community’ if you:

  • Apply the Scrum framework outside software development by a single team.
  • Use other tools than Atlassian’s for product breakdown and planning.
  • Enhance the Agile Manifesto e.g. taking it beyond the realm of software development.
  • Admit being on a journey becoming agiler.
  • Reserve Scrum for complex product development, and apply different processes or practices for business-as-usual, complicated or chaotic contexts.

16 pages of Scrum theory are incredibly difficult to practice

Whether you like it or not, the 16 pages of the Scrum Guide define Scrum. “This Guide contains the definition of  Scrum. This definition consists of Scrum’s roles, events, artifacts, and the rules that bind them together.” If you want to bend these rules or deviate, be honest about it. Any Scrum master or critical observer knowledgeable of the same 16 pages of rules, is fully entitled to confront you with your choices. There is a reason for Ken Schwaber and Jeff Sutherland to state that they “developed Scrum; the Scrum Guide is written and provided by them. Together, they stand behind the Scrum Guide.”, ” 

Scrum is:

  • Lightweight
  • Simple to understand
  • Difficult to master”, and

“Specific tactics for using the Scrum framework vary and are described elsewhere.” Other books, presenters, practitioners may publish and share their tactics, practices, lessons learned about the way they actually use the Scrum framework. It’s just like a soccer team being coached, instructed, and rewarded to play the game in a specific way. Rules for soccer are a given, selection of team players, playing style, training schedule, salaries, clothing, sponsorship, involvement of fans, etc. are open and will vary among teams and countries.

Be aware of the difference between tactics for using the Scrum framework and deliberate choices to play a different game. My client organization wants to check the knowledge of Scrum, throws in weekly quizzes with questions like: “What are steps involve in Scrum Cycle?” Unfortunately, there is no ‘none of the above’ option to answer this question. Scrum, like other frameworks based on empiricism, has three pillars: inspect, adapt, transparency. In the Scrum Guide steps are non-existent. There is no predefined sequence. Transparency should be there 24/7. Inspect & adapt is at the core of the Scrum events (Sprint planning, Daily Scrum, Sprint review, Sprint retrospective). Planning is both at the beginning of the Sprint during the Sprint planning event, but also answering the second question in the Daily Scrum, as well as throughout the day as progression is made, impediments are encountered, and other products are completed faster than expected.

If you want to have a sequential step-by-step approach in place, like the Plan-Do-Check-Act (PDCA) cycle, you’re using a different framework, and have to face the consequences. You will only inspect finished products by quality review techniques, adapt only after a close inspection of delivered products. Everything can and must be planned before being produced. I’m not against PDCA, but Deming is not Schwaber or Sutherland providing us Scrum.

What about deviations on team level when scaling up?

Consider this real-life case:

  • Multiple product owners interact with a single Scrum team.
  • Many in-depth discussions occur during the Daily Scrum. The three questions Development Team members should explain themselves are forgotten or left to the Scrum master to pull from them.
  • It takes multiple Sprints to deliver shippable software and mandatory documentation. Story points are only counted for when a User story is done. A burn-down chart is not used at all.
  • Every 2-3 Sprints team composition changes.
  • The team is highly dependent on providers and consumers of the products they deliver.
  • No stakeholders are invited to the Sprint review. None or only a selection of the products are demonstrated.
  • Even after 16 Sprints Daily Scrum meetings don’t start and end in time, people joining and leaving throughout the meeting, and audio connections are still bad, despite conference call tools being available.
  • No velocity is measured, no reference User stories for estimating are available.
  • Updating tasks for product backlog items in JIRA is still not common practice among Development team members.

20080920 Balkbrug E3 002Will scaling up resolve or increase these problems? Let’s revisit the soccer team. When our son was around eight, he and his fellow team members basically didn’t know how to play the game. They simply went after the ball, all of them, all the time. Later, they learned to listen more to the referee, play a certain position, and become better soccer players, both individually, and as a team. If you play soccer in name only, you will lose all the matches, except for a few in which you are very lucky. In my opinion, the same applies to the play of Scrum. If you don’t know how to play it according to the rules, you’ll lose the matches. Your Product owner and other stakeholders will not benefit from your free format sandbox level play. Where other teams behave predictably, you don’t. And where other teams improve their process, competencies, and productivity, you still struggle with basics. Be honest, you’re not ready for the big game. It’s Agile in Name Only, nothing to be proud of.