All posts by David Sabine

I help organizations improve their work environment, technical practice, time-to-market, market-fit, performance, and quality. My professional career highlights the intersections of business, technology, education and innovation. I am a guest lecturer at the Ivey School of Business, a TEDx speaker, and a seasoned Agile practitioner. I have significant “in-the-trenches” experience using Agile methods with product development &application support teams – including Scrum, Kanban, LeanUX, and OpenAgile.

Equifax Data Breach: Lessons We Must Learn

Learn more about transforming people, process and culture with the Real Agility Program

I woke up this morning to the news that my personal data has been leaked by Equifax to…who knows!?  I was reminded of the following tweet:

So, what “awful circumstances” led to Equifax’s recent breach?

Let’s reflect:  News has surfaced (TechCrunch, Reuters) that hackers have scraped untold amounts of sensitive data from Equifax systems.  143+ million people are affected as hackers have amassed a huge database of names, addresses, credit records, license numbers, banking histories.  (That probably includes you too!)

I want to be clear though, the news broke yesterday but the problem started long ago.  The security vulnerability has existed for (probably) years and I have no doubt some Equifax staff have known about it.

Equifax!  We’re not talking about some high-school project with junior coders and tech newbs.  We’re talking about one of the world’s most trusted organizations.  We’re talking about a company whose very existence (their whole business!) is to protect our collateral.  This is supposed to be one of the best-funded, most secure, most technologically-advanced companies on the planet.

But I’m not surprised.   Here’s why…

I teach Scrum and my classrooms are filled regularly with people who work in companies exactly like Equifax.  I hear their stories every day:

“Our managers don’t provide the tools we need to do the job.”

“Our managers don’t understand the time required to deliver high-quality software.  We’re always pressured to cut corners to meet arbitrary and impossible deadlines.”

“Our systems are broken, everyone knows it, but managers continue to outsource and off-shore our QA.”

“We don’t have authority to decide the implementation, we’re often told what to implement by architects and supervisors, even if we know it to be rotten.”

“Our managers never ask us about quality…they ask us only ‘when will this be done’?”

And that’s the crux of the problem: people are hired by companies like Equifax to provide technical expertise, then their advice is ignored and their implementation decisions aren’t trusted.

Some important questions to consider…

1. Does Equifax lack the money to hire excellent technical staff?

No, their offices are filled with some of the best programmers in the world.  I meet them (or people like them) regularly in my classes and I have no doubt that the technical staff at Equifax have warned the managers for years of security holes and technical defects.  I have no doubt those managers have ignored the alarms and have pushed the staff to deliver deficient code.

2. Does Equifax lack the time to build high-quality systems?

No, last I checked they’ve been at it a long time and their existing contracts will carry their operation years into the future.  And as mentioned earlier, securing our data is the reason the company exists.  It’s  the one thing they’re supposed to get right – I’d think their time should be entirely devoted to building high-quality systems.

3. Does Equifax lack the financial resources to invest in proper tools and training for security/quality testing?

No, such techniques and tools are widely available and inexpensive (even hackers can afford them!)  Managers at Equifax have denied budgets for training, tools, and upgrades because “it’s too costly” – hmm…I wonder the cost of this data breach?

4. And my favourite question of the day: Are the hackers “smarter”?

Absolutely not.  But they’re more dedicated and have equipped themselves with good techniques and tools for penetration testing.  In my personal experience as a hacker (er, I use that term loosely) security holes are all around us if we look for them.  Equifax simply wasn’t looking!

What to do about it…

First, it’s clear to me the problem isn’t technical or financial.  It’s cultural.  I see it all the time.  Teams of good product developers are surrounded by bureaucracy instead of support.   Teams of good coders aren’t trusted to see the source code of the systems used by the company – yes, that’s as crazy as it sounds!  Teams of good coders are kept silent about the security vulnerabilities they see.  Solutions are ignored by management and the arguments are: “improving the security isn’t a priority right  now” or “we know there are some possible security concerns and we are in discussion with vendors or outside agencies to address it” or “we have a budget for security improvements scheduled for next quarter; let’s focus for now on new features instead”.  Managers are more concerned with deadlines than with quality.  Managers scrutinize the number of hours a developer works on a task, and outsource or off-shore the quality assurance and testing!  Managers conduct endless planning activities then compress the implementation into tight budgets and timelines – evidently, a lot of energy is spent getting the plan “right” but getting the software right is not a priority.  I could go on.

If you’re interested to know how things work at Equifax, just think of the Dilbert cartoons.  I mean it.  I am very serious.  Dilbert isn’t funny because it’s fiction; it’s funny because it’s NON-fiction.  Sadly. Typically, for enterprises like Equifax, their technical staff and customers take a back seat to management “theatre”.  This needs to be fixed and it starts by asking the technical staff a single, simple question:  “Who among you have raised concerns about technical debt with your managers/supervisors and were ignored?”  That question will unearth bugs which have been deprioritized by managers, budgets that have been denied for technical training and automated testing, projects which have been reported as “done” before they were actually ready for deployment – in other words, that question will reveal the many (fixable) ways managers get in the way of quality.

Second, executive staff at Equifax need a crash course in automated testing.  Yes, THE EXECUTIVE STAFF!  It’s is essential they understand and see with their own eyes that:

  1. Automated testing is cheaper and exponentially more effective than manual testing;
  2. ALL defects are discoverable and fixable before hitting production environments;
  3. Quality is not something one outsources
  4. and the techniques to achieve ZERO DEFECTS are well-known, teachable, repeatable, and proven.   I’m of course referring to techniques like Test-Driven Development, Continuous Integration, Refactoring, and Swarming.  For example, these technical topics form the bulk of our Certified Scrum Developer classes. (Shameless plug.)

And third, technical staff need to stop behaving like sheep.  So far in this article, I’ve been very critical of managers, sure, and anyone who knows me personally knows I have no time for inept management.  But too often I meet smart, well-meaning developers who deliver shoddy code – perhaps at under pressure and against their better judgement, but in the end whose code is it?  Developers! I understand you might feel trapped in a pattern of quantity-over-quality and you are frequently coerced by your management to cut corners.  I get it… I understand it… it’s easy to feel that deadlines are some sort of immutable truth and that managers wield all the power.  But the fact is, developers, YOU hold all the responsibility and therefore you need to be the professional.  You need to say “no” and demand the latitude you require to deliver high quality.  You’re the one closest to the code and therefore directly responsible for the safety and well-being of your users.

So, Equifax and enterprises everywhere, I’m speaking now as your user or stakeholder or customer…

Equifax has failed. Miserably. The company deserves all the class-action suits coming there way. From leaders to developers. Everyone.

Most members of society are unwilling participants in all this.  Most of us aren’t your direct customers.  Example: I’m not a direct customer of Equifax – nobody has chosen Equifax as their personal agent.  Instead, our banks and our governments have selected Equifax on our behalf.  This presents a problem: if I were a direct customer of Equifax I’d call them today and close my accounts; but I can’t do that.  Instead, the best I can do as an individual is contact my banks, lenders, and insurance agents to demand change.  (Yes, I likely will do that.  I’m that sort.)

However, the larger issue is that we are at the mercy of YOU who produce software.  I’m talking about the software in our vehicles, in our heart-monitors, in our subway systems, in our air-traffic-control centres, in our banks – this is serious stuff!  We must be able to trust those systems…with our lives, with our security.  We must be able to trust you even though we don’t and won’t ever know you.

A hacker friend of mine once said, “if self-driving cars are being produced without complete automated test coverage, then that’s a future I don’t want.”

In this day and age, low quality is intolerable.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

A Group of Geographically Distributed Staff is NOT a Scrum Team

Learn more about transforming people, process and culture with the Real Agility Program

It’s my opinion, and I think the opinion of the authors of Scrum, that a Scrum team must be collocated. A collection of geographically distributed staff is NOT a Scrum team.

If you work in a “distributed team”, please consider the following question.

Do the members of this group have authority to decide (if they wanted to) to relocate and work in the same physical space?

  • If you answer “Yes” with regard to your coworkers: then I’d encourage you to advise your colleagues toward collocating, even if only as an experiment for a few Sprints, so they can decide for themselves whether to remain remote.
  • If you answer “No”, the members do not have authority to decide to relocate:
    • then clearly it is not a self-organizing team;
    • clearly there are others in the organization telling those members how to perform their work;
    • and clearly they have dependencies upon others who hold authority (probably budgets as well) which have imposed constraints upon communication between team members.
    • CLEARLY, THEREFORE, IT IS NOT A SCRUM TEAM.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

A Book Review: “The Great ScrumMaster”, by Zuzana Šochová

Learn more about transforming people, process and culture with the Real Agility Program

In Brief

Buy it! You won’t be disappointed!

In Depth

I read the book in 3 sittings.

The First Sitting

Zuzi gave her book to me in October. She was visiting Toronto at the time and we spent a few days together teaching Scrum – I was honoured that she would share a classroom with me and that I’d get a sneak peak at her new publication. Almost immediately after she gave me the book I found a few minutes to thumb through it and read the foreword and first chapters. I immediately liked what I saw.

The foreword is written by Linda Rising who frames the book nicely by reminding us of these simple principles: “successful change is built around small steps and learning”, and “the book offers a chance for reflection and evaluation”. Zuzi’s preface describes briefly her journey to become a great Scrum Master. Hers is a story about humility and studious peristence; the journey is unique and difficult for us all. I could relate! The best aspect of the early pages in the book are the photographs of Zuzi. The book exudes her character traits: a friendly and insightful expert, a colleague and advisor. Her photos, as well as her illustrations throughout the book, help the reader to understand her colourful character; her stance as a coach and mentor; and her voice as an author.

My time was limited so I didn’t get far in that first sitting though my first impressions of the book are memorable. It’s a big book – not thick, that’s not what I mean. I mean large, wide pages. Approximately 20 centimetres square. It’s the kind of book that lays open on a coffee table. This is important! I understand many people buy digital books but if you can find the book in physical format, buy it! The medium is the message, as Mcluhan said. The medium, in this case, is a lightweight book that rests easy, open-faced, on a desk or coffee table. As you pass by the table or sit for a while to enjoy a conversation, you’ll find the book open and waiting for you. You’re likely to thumb through it lazily, your mind wandering while on the phone or talking with a friend, then something will catch your eye. It’ll be a page you’ve looked at a dozen times but suddenly a sentence or illustration will stand out for you, draw your attention. Like, “…if you join a discussion with the core metaskill of curiosity it will be different than if you choose listening or teaching”. That sentence is on page 88 – that’s the one that jumped off the page for me today. I’ve read that page a few times already but this day, in this moment, that sentence resonates. Such a simple sentence on a page and sparse text and white space…but exactly the solace you will need.

The Second Sitting

I was riding a train with the book open on my lap. Through the window passed the Canadian landscape, and I’d glance at the book between sips of coffee to take in another paragraph, picture, page. (See how cool the format is??) What I’ve learned from the next chapters of the book is that I share Zuzi’s interpretation of Scrum and of the Scrum Master’s role.

Her perspective is a philosophical one, yet she effectively relates the material to practical examples. Zuzi describes a concept she calls the #ScrumMasterWay. This is an innovative model for understanding how a Scrum Master can adapt their mode of service depending on the conditions of the organization they serve. Perhaps at first, the organization they serve is ‘A Scrum Team’ – and in that mode of service a Scrum Master will facilitate Scrum and help the team to self-organize. Next, after all the easy fruit has been picked and the Scrum Team is capable of continuous and deep self-improvement, the Scrum Master’s mode of service is likely to change – the team no longer needs help with the rudiments so the Scrum Master may focus more intently upon relationships to and within the team. And finally, the 3rd level of #ScrumMasterWay is achieved when the Scrum Master is able to focus their effort toward the entire system, “bringing the Agile Mindset and Scrum values to the company level”.

The Last Sitting

Reading about Zuzi’s #ScrumMasterWay concept in the previous sitting led me to think nostalgically about my own journey. I know this book, had she written it a decade ago, may have saved me from some mistakes of my own. I’ve come to more deeply appreciate her telling of the Scrum Master role.

In the 2nd half of the book, she provides a glimpse into numerous related practices and concepts. A collection of references and teaching tools that most Scrum Masters will discover along their journey. For example, all Scrum Masters will find themselves in discussion with stakeholders about the nature of complex problems and, ta da!, like a stone tablet from a high mountain will appear Dave Snowden’s CYNEFIN framework! A simple diagram…it’s so obvious! All Scrum Masters will find themselves in a personal struggle between telling and listening: “should I coach as a teacher?” or “coach as a facilitator?” and, without fail, a fellow Scrum Master will recommend a training course with the Agile Coaching Institute to better understand the coaching stance(s).

Here’s the truth of it: if a young jazz musician wants to become a great jazz musician, there are some iconic recordings to which they must listen: Kind of Blue; anything by Duke Ellington and Louis Armstrong; Blue Train; Saxophone Colossus. No drummer is worth their salt without having spent a zillion hours listening to Max Roach and Jimmy Cobb. Likewise, every great Scrum Master has had to grapple with the iconic challenges of servant leadership – they’ve spent a zillion hours pondering the difference between the words “should” and “could” and they’ve praised the power of the question, “what if?”

So, to help Scrum Masters along their journey, Zuzi has compiled many of the community’s greatest hits in her book. Einstein is often quoted as saying, “If you can’t explain it simply, you don’t understand it well enough.” Perhaps then, one can examine how well a person understands a concept by how simply they can explain it… right? By that measure, it’s evident that Zuzi understands her material as she’s able to distill complex topics to just a colourful drawing and a few bullet points. “Root cause analysis” is described concisely with 3 paragraphs, 4 bullet points, and a beautiful drawing of a tree. Her purpose, keep in mind, isn’t to make the reader an expert in root cause analysis – her point is as if to say, “remember…problems often run deeeeeeep in the system. They’re organic. Find the seed.” I’m hearing in my mind a wise old music teacher, telling the aspring young jazz musician, “remember Herbie Hancock…go listen to Maiden Voyage…behold the deeeeeeep groove and floating melodies. It’s organic”.

The collection of materials which complete her book include highlights of Tuckman’s “Stages of Group Development”; Lencioni’s “Five Dysfunctions of a Team”; the martial artist’s progression through “Shu Ha Ri”; a shortlist of “Powerful Questions”; and a few others. In this last sitting, as I finished reading the book, I was struck by the similarity between Zuzi’s journey and interests and my own. I too have enjoyed Lencioni’s books, Tuckman’s model, the practice of co-active coaching. While I’ve lived and practiced all these years in Canada and Zuzi has lived and practiced in Prague, how is it we have been exposed to a similar body of knowledge and wisdom? I take some comfort in that, actually.

Conclusion

I face a difficult decision now. Zuzi signed this book for me and it’s in pristine condition. However, if I’m not careful, I am certain in the coming years this book will become littered with notes and comments, dog-eared pages and sticky-notes everywhere. Shall I allow myself to ruin this pristine book? Yes. Yes, I shall 🙂

See also:


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Are You Getting What You Need From Conferences?

Learn more about transforming people, process and culture with the Real Agility Program

(Originally posted in June 2015 – Updated October 2016)

Photo Credit: BERTEIG’s Valerie Senyk facilitated a group session on “What Do We Mean by Transformation?” in Orlando 2016.

Professional Development opportunities are everywhere and they are easy to find at any price-point on any topic at any location. The hard part is deciding how to spend your time.

It is important to think about why you attend conferences. Most importantly, why do you choose some conferences over others? Do you want to learn from peers in your field? Do you want exposure to the latest industry trends? Are you looking for a new job? Or do you just want to be blown away by great people?

I attended the Agile Coach Camp Canada last weekend in Cornwall, Ontario, and that incredible experience has caused me to reflect on the variety of conferences I have enjoyed in recent years…and why I choose some over others.

Like any great product, successful conferences have clear and focused goals which create specific opportunities for their participants. Conference organizers choose location, venue, date, duration, registration cost, format, theme, etc. The best conference organizers are courageous and willing to make difficult decisions in order to compose their events with utmost respect to the collective vision and goals of the attendees, sponsors, and founders. The organizers of Agile Coach Camp Canada, for example, are dedicated to creating an event in which the agile coaching community can “share in an energizing and supportive environment”. That’s it! A clear and compelling vision. This clarity of vision guides decisions like whether to host the event in a metropolis (which may result in larger numbers and more sponsorship opportunities) or away from large cities (think overnight “camp”) — this is one formative decision of many that make Agile Coach Camp Canada so intense and unique year after year.

Some background: This was the 6th annual Agile Coach Camp Canada and the 2nd time that I have attended; the event generally starts on Friday evening and includes supper followed by lightning talks, Saturday uses Open Space Technology to produce an agenda followed by supper and socializing (late into the night!), then Sunday morning wraps-up with retrospection then everybody leaves in early afternoon; the cost per person is between $300-$500 for the entire weekend including meals, travel, hotel room; the event is often held in small-ish towns like Guelph or Cornwall which are a few hours from a major airport. Having been there twice — both times just blown away by the community, their expertise, their emotional intelligence, their openness — I understand very clearly the responsibility of conference organizers and I have gained new respect for the difficult decisions they must make.

Upon reflection, I know that I attend the Agile Coach Camp Canada because (a) I learn a lot and (b) I have bonded deeply with my colleagues. Those are the two reasons that I will return next year and the next. I do not attend that event with an expectation to develop new business, or attract new leads, or stay on top of industry trends — instead, I will look to other conferences for those opportunities.

What/where/when is your next professional excursion? Do you know what you want to get out of it? Here’s a tip: choose one objective from the list below and find a conference that delivers exactly that!

  • Business development: Find new or reconnect with existing business contacts.
  • Professional development: Find or explore opportunities for career enhancement.
  • Learning: Listen/watch/share with others who practice in your areas of interest.
  • Community building: Connect and communicate with people with interests or qualities that you appreciate.
  • Market exposure: Evangelize a product or service for a captive audience.
  • Other?

Life is short…make it amazing!


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Sabine’s Principle of Cumulative Quality Advantage

Learn more about transforming people, process and culture with the Real Agility Program

Many organizations won’t survive the next decade. Of those that survive, even they are likely to be extinct before century’s end — especially the largest of contemporary organizations.

I was thinking today of a few essential adaptations that enterprises must make immediately in order to stave off their own almost-inevitable death.

With Regard to Business Strategy

  • Measure value delivered and make decisions empirically based on those data.
  • Strive toward a single profit-and-loss statement. Understand which value streams contribute to profit, yes, but minimize fine-grained inspection of cost.
  • Direct-to-consumer, small-batch delivery is winning. It will continue to win.

With Regard to People

  • Heed Conway’s Law. Understand that patterns of communication between workers directly effect the design and structure of their results. Organize staff flexibly and in a way which resembles future states or ‘desired next-states’ so those people produce the future or desired next-architectures. This implies that functional business units and structures based on shared services must be disassembled; instead, organize people around products and then finance the work as long-term initiatives instead of finite projects.
  • Distribute all decision-making to people closest to the market and assess their effectiveness by their results; ensure they interact directly with end users and measure (primarily) trailing indicators of value delivered. Influence decision-making with guiding principles, not policies.
  • The words ‘manager’ and ‘management’ are derogatory terms and not to be used anymore.
  • Teams are the performance unit, not individuals. Get over it.

With Regard to Technology

  • Technical excellence must be known by all to be the enabler of agility.
  • Technical excellence cannot be purchased — it is an aspect of organizational culture.

For example, in the realm of software delivery, extremely high levels of quality are found in organizations with the shortest median times-to-market and the most code deployments per minute. The topic of Continuous Delivery is so important currently because reports show a direct correlation between (a) the frequency of deployment and (b) quality.

That is, as teams learn to deploy more frequently, their time-to-market (lead time), recovery rates, and success rates all change for the better — dramatically!

I have a theory which is exemplified in the following graph.

Sabine’s Principle of Cumulative Quality Advantage Explained

As the intervals between deployments decrease (blue/descending line)

…quality increases (gold/ascending line)

…and the amount & cost of technical debt decreases (red area)

…and competitive advantage accumulates (green area).

Note: The cusp between red and green area represents the turning point an organization makes from responding to defects to preventing them.


This is a repost from David’s original article at tumblr.davesabine.com.

This post is inspired in part by these awesome texts:


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

“Teams” Larger Than Eleven Are Not Scrum Teams

Learn more about transforming people, process and culture with the Real Agility Program

Mobbing Team

Scrum suggests the size of the Development Team (the Scrum Team members who perform the work of the Sprint Backlog) be between three (3) and nine (9) people. (The Scrum Master and Product Owner are not included in that count unless they are also executing the work of the Sprint Backlog.) To maximize cohesion and minimize complexity, it is important larger groups be split into smaller units or downsized.

Considerations for re-organizing into multiple Scrum Teams:

  • People executing the work may be best suited to decide optimal team size and composition. Adjustments to team composition will be most effective if the team members are trusted (and supported) to re-organize around their own work.
  • Groups larger than eleven people often naturally subdivide into smaller, cross-functional sub-groups; therefore it may be possible to carefully observe which team members interact regularly while getting work done and simply acknowledge those informal arrangements.
  • In order to minimize dependencies between teams, Scrum Teams whose mandates are to own discreet Products or systems are preferable to groups whose mandates are to support “components” of larger systems.
  • Organizations which currently employ Project Management methods ought to consider changing budgeting & staffing practices to align around Product delivery rather than Project Management. Doing so will make value streams transparent and bring clarity to Product-centric team mandates.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Breaks Between Sprints Indicate a Problem

Learn more about transforming people, process and culture with the Real Agility Program

This post is a follow-up to an earlier article: There Are No Breaks Between Sprints.

Breaks between Sprints indicate a problem. Usually such breaks are filled with planning activities including research, requirements gathering, design & preparation, negotiations & approvals and the problem is threefold:

  1. Such plans are based on conjecture (risky and not compatible with Scrum) rather than empiricism (less risky and compatible with Scrum). Those activities are most beneficial when diligently performed by skilled inspectors at the point of the work. The four formal events within each Sprint provide the team and stakeholders adequate opportunity for inspection and ensure that decisions are being made in light of the up-to-date product increment and with respect to current user needs and market conditions.
  2. Breaks between Sprints often include activities which do not add value to the product or are entirely unrelated.
  3. Breaks between Sprints defer the delivery of value because the work performed does not result in potentially-releasable increment of “Done” product.

To correct this problem it is important to identify whether any of the effort spent between Sprints is adding value to the product — that is, which activities effect the form, fit, or function of the actual product. If determined to not be value adding, stop the activity entirely — it is waste. If determined to be value adding then the work ought to be part of their Sprints and the Scrum Team may decide that either the activity should be represented and ordered in the Product Backlog, or should be represented in the team’s Definition of Done.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Splitting User Stories

Learn more about transforming people, process and culture with the Real Agility Program

A common challenge faced by inexperienced Scrum teams is related to splitting user Stories (in Scrum, Product Backlog Items or PBIs) so that they are granular enough for development. The INVEST model is a good way to test whether user stories are well-written.

  • I – Independent
  • N – Negotiable
  • V – Valuable
  • E – Estimable
  • S – Small
  • T – Testable

Independent – Each user story must be independent of each other. This prevents any overlap between the items; moreover, it allows the team to implement them in any order.

Negotiable – The details of the work must be negotiable, both among the stakeholders and the team. Specific requirements and design decisions will be fleshed out during development. Many agile practitioners recommended writing user stories on a note card — this is intentional so that a limited amount of detail can be prescribed.

Valuable – Each user story must add business value to the product, the customer and/or the users’ experience.

Estimable ¬– A good user story can be understood well-enough by the team that they can estimate it — not accurately — but at a high-level they perceive that it has size. It is helpful to understand the relative effort as compared to other user stories.

Small – A user story is not small if the team cannot get it done within a single Sprint. As large user stories are split into smaller items, greater clarity about the size and implementation is achieved, which improves the likelihood that the team will get it done within a Sprint.

Testable – Each user story should be testable; this is a common characteristic of well written requirements. If the team cannot determine how the user story may be tested, it is an indication that either desired functionality or the desired business value is not clear enough.

Vertical vs Horizontal Splitting

There are two common ways to split user stories: vertically or horizontally. Horizontal breakdown of user stories splits the item at an architectural component level. Example: front end UI, databases or backend services. Whereas, a vertical slice results in working, demonstrable, software which adds business value. Therefore, it is recommended to slice user stories vertically so as to reduce dependencies and improve the team’s ability to deliver a potentially shippable product increment each sprint.

Splitting User Stories Example

As a customer I can pay for my order so that I receive the products

If the above user story was to be split in a vertical manner, it might be broken down into the various ways a customer can complete a payment. As follows…

As a customer I can make a credit card payment for my order so that I collect reward points on my credit card.

And/or

As a customer I can make a PayPal payment for my order so that I can securely complete my purchase without sharing credit card details with another retailer.

The key point to note in the vertically sliced user stories above is that each story passes the INVEST tests mentioned earlier and therefore a Product Owner can prioritize these user stories based on customer needs. However, if a horizontal approach was used to split the user story (i.e. split by architectural layers and components) then the implementation of such requirements would result in working functionality only when all horizontal components are eventually integrated.

Breaking down by Workflow

Another approach that is commonly used to breakdown user stories is focused on the individual steps a user may take in order to achieve their end goal — that is, a user story which describes a long narrative or “user flow” through a system may be sliced into steps which represent portions of the user’s flow. Continuing from the example above of a customer making a purchase online, the user story can be broken down into the following:

As a customer I can review the items being purchased for my order so that I can be confident I’m paying for the correct items.

As a customer I can provide my banking information for my order so that I can receive the products I ordered.

As a customer I can receive a confirmation ID for my purchase so that I can keep track and keep a record of my purchase.

Other Methods

There are many other methods that can be utilized to breakdown larger user stories such as:

  • Breaking down by business rules
  • Breaking down by happy / unhappy flow
  • Breaking down by input options / platform
  • Breaking down by data types or parameters
  • Breaking down by operations (CRUD)
  • Breaking down by test scenarios / test case
  • Breaking down by roles
  • Breaking down by ‘optimize now’ vs ‘optimize later’
  • Breaking down by browser compatibility

Kudos to this article for inspiring the list above: blog.agilistic.nl.

Other Helpful Resources

The Hamburger Method
User Stories and Story Splitting at AgileAdvice.com


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

ProjectWorld Workshop: From Project to Product

Learn more about transforming people, process and culture with the Real Agility Program

This week we sponsored ProjectWorld in Toronto. Tons of people stopped by our booth and shared their experience with us.

As well as meeting many old friends and new potential clients/collaborators, Mishkin presented a symposium to dispel the myths of Agile work and Gerry, Travis, and I facilitated a workshop called “From Project to Product: Agile Delivery Models”.

Many people in our workshop asked that I share the slide deck so please download it here. Feel free to share with others!


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

David Sabine to Host Panel Discussion with Strategic Leadership Forum in Toronto

Learn more about transforming people, process and culture with the Real Agility Program

Hi, David here.

I have been invited to moderate a panel discussion about business agility on March 30 with the Strategic Leadership Forum in Toronto.  Thank you to Jerry Adel for inviting me!

The panelists includes Dave Clark, David Colburn, and Frank Leong.  I’m honoured to share the stage with them.  Please join us.

Register at EventBrite.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

If Your Up-Front Planning is Measured in Weeks, Then a Lean Startup is Going to Eat Your Lunch

Learn more about transforming people, process and culture with the Real Agility Program

Title inspired by Michael James…see below.

One of the most powerful assumptions built in to Agile methods is that we learn by doing — that our learning, our planning, our problem-solving, and ability to mitigate risk is enhanced when planning is performed inline with active development and in the context of deliberate experimentation.  Scrum, for example, is based on empirical process control theory which means that we make decisions based on what is known.

One of the most common pitfalls we see among organizations trying to “adopt” Agile is excessive pre-planning — their assumption being that we can decide by planning, learn by planning, or mitigate risk by planning.  This sometimes manifests as an anti-pattern that people call “Sprint Zero” — a signal that an organization misunderstands Agile methods fundamentally.  More importantly, a signal that the organization may incorrectly perceive Software Engineering — or any team-based work — as predictable and repetitive rather than the complex, creative endeavor that it is.

If your organization injects a “Sprint Zero” or a planning phase (that is measured in weeks rather than days or hours) ahead of the creation/development of real product, then these two posts are of interest to you:


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Change On-the-Fly Learnings Into Lasting Improvements

Learn more about transforming people, process and culture with the Real Agility Program

Teams encounter and solve many EP!C challenges as they deliver their Product Backlog items. During Retrospectives, teams may struggle to recall their challenges/learnings and may miss an opportunity to adapt their behaviour for future work cycles.

I thought of two fun ideas to help teams keep this EP!C stuff top of mind:

  1. Get a milk carton with a cut out (call it a “Treasure Chest”), supply some sticky notes and sharpies, and have the team deposit new notes as they happen during their work.
    • When the team gathers for a Retrospective they can retrieve these treasures and discuss them.
  2. Create a “Parking Lot” on the wall in the team area where they can post sticky notes during their work periods. These 3 questions can help them focus items that they post:
    • What did you learn during this Sprint/Cycle that you want to share with the team?
    • What did you learn during this Sprint/Cycle that you want to share with other teams?
    • How might your stakeholders help or support your team and how might dialogue with them be initiated?

I pitched these ideas to my team and they loved both and they decided to experiment with the 2nd above. On Day 2 of a recent Sprint, I was amazed to see how many ideas had been posted in just 2 days. Not only does it include learnings/challenges, but it also includes items that can integrated into our Definition of Done in the future.

Submitted by Lisa Serrentino.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Practice Courage: Move Beyond Planning Into Action

Learn more about transforming people, process and culture with the Real Agility Program

Courage is required to move beyond planning into action. The amount of courage correlates to the attachment we feel to our plans and the attitude we have about failure. Risk-averse/plan-heavy environments are discouraging — risk-tolerant/experimental environments are encouraging.

Are you stuck in planning mode?

I was coaching Product Managers working for a demanding Chief Product Officer. Not only demanding but also visionary yet particular, energetic yet moody, instinctual yet empirical, intensely focused yet integrally involved in all aspects of business — he led the creation of a multi-billion dollar product so these traits are evidently effective. The Product Managers faced intense pressure.

When I met the group, projects underway by the engineering teams were all in the name of optimization or reliability of existing features. New product ideas had been shelved and Product Managers felt paralyzed in a pattern of planning and analysis. The more they planned, the more they became attached to their plans, the more they were disheartened when the CPO rejected their plans, so the more they would plan.

To break from that pattern, I petitioned hard for a four-day hack-a-thon so the whole product development organization could self-organize and feel encouraged to try new things. With mere *minutes* of up-front planning, teams started testing new product ideas in a safe-to-fail setting.

The results were powerful. The barriers to action had dissolved and within months the company could announce new features and previously-shelved product ideas were underway.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

If Showcasing Technical Work, Then Remember to Keep Stakeholders Engaged

Learn more about transforming people, process and culture with the Real Agility Program

During Sprint Reviews, I’ve observed teams showcasing the results of purely technical work. Sometimes the resolution of a defect caused by some form of technical debt (“we noticed that we were making too many service calls”); or something related to development infrastructure (“we had to switch to a new testing framework”.) In such cases, the presentation frequently jumps quickly into a description of what was done showing, for example, the before and after behaviour connected to the defect or the results produced with a testing framework.

Potential problems with this are that business stakeholders attending the meeting:

  • might be left wondering what this means to them
  • feel unable to provide any feedback
  • and in the worst case scenario, might feel they’ve wasted their time attending the Review.

A team might ask themselves, “what is the reason for us to have purely technical items in our Product Backlog?” But leaving that aside, the perils of losing stakeholder engagement during the Sprint Review could be mitigated by framing the presentation around the following questions:

  • How is the world better now that we’ve fixed this defect?
  • What’s the impact on the users and the business?
  • What specific new capability does this technical work allow the team to do now for the business they serve (that they couldn’t do before)?

Submitted by Fernando Cuenca


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Practice Focus: Send Less Email & Close Slack

Learn more about transforming people, process and culture with the Real Agility Program

Very few people are paid to chat or write email: executive assistants and lawyers mostly.  Everybody else is paid to do other work like write code, build things, solve problems, or transact with customers.  Think about what you’re actually paid to do, then do that and only that.

If the Slack channel side-bar represents your definition of “collaboration”, stop! If you need to communicate with others while doing your work, do it face-to-face whenever possible or by phone & video. To be clear: Slack channels may be good for announcements but quickly digress as water-cooler drivel and those chatbots are sorry excuses for actual event logging. Perhaps it’s reassuring to be reminded that there’s nothing in Slack (or Yammer/HipChat/Asana/Jira/Trello) more important than the work you’re actually paid to perform.

If your “Sent Items” folder is a CYA repository, stop! If it’s necessary in your organization to CYA then document your activity in a personal journal and stop involving other people in your CYA habit.

If your Inbox is your to-do list, stop!  Use sticky-notes, a hipster PDA, or a calendar.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail