Tag: ScrumAnd

Posted on by — Leave a comment

The “ScrumAnd” Stance (requiring thought and discipline)

Try organizing a party in a “Yes, but…” atmosphere. The result is probably a zillion obstacles identified, but no party.
Try moving through a door with your eyes stubbornly fixated on the door frame. People seemingly can become deeply obsessed with frames-as-obstacles.

Try benefiting from Scrum in a “Yes, but…” environment, where the primary response is to raise concerns and hindrances, where the conversation is all about obstacles, and that what cannot be done.

“Yes, but” comes in many guises.

“Yes, but” is a tempting stance, offering the illusion of safety. Shifting to “Yes, and” requires thought and discipline. It requires thought and discipline to consciously look for possibilities and opportunities first, no matter how small. This does not preclude awareness of problems and obstacles, but the focal point shifts radically. Check if the door is actually open. Look at the doorway. Trust the door frame for holding the wall from collapsing if you pass the door. If the door is closed, the frame is probably not where the solution is. 

Imagine adopting Scrum from a “Yes, and” stance.

Over the past decade Scrum did more than just gain a critical mass to build on. Since Scrum’s inception in 1995 and the definition of ‘Agile’ as a set of values and principles in 2001, Scrum gradually became the most preferred way for people, teams and organizations worldwide to become more Agile. Agile crossed the chasm (2005-2006) and by now the 3rd Scrum Wave has risen.

Zeitgeist. Inclusive language and an inclusive stance are more helpful today. “ScrumAnd” is today’s way forward to help people increase the benefits realized through their manifestation of Scrum. 

“ScrumAnd” starts with Scrum. Scrum is a simple, yet cohesive framework. In a nutshell:

A Scrum Master fosters an environment where:

  1. A Product Owner assures there is a Product Backlog, an ordered list of work deemed necessary to optimize the value a product delivers.
  2. In consultation with the Product Owner, Development Team(s) pull the work from Product Backlog deemed feasible to get done in a time-boxed Sprint against an overarching Sprint Goal.
  3. On a daily basis the Development Team(s) synchronize their progress and upcoming work toward delivering a releasable version of product, available no later than by the end the Sprint.
  4. All players involved figure out what to work on next and how to best organize as from the next Sprint.
  5. Repeat.

Although crucial to optimize the benefits realized, observation shows how difficult it is to keep Scrum cohesive. There are no practices that can be left out or cut out without harmfully breaking the cohesion (covering up dysfunctions or other ways of undermining important benefits). There is no such thing as individual Scrum practices.

Observation shows how difficult it is to keep Scrum lightweight and nimble. There is no need to aggravate Scrum. The “And” in “ScrumAnd” is not the next excuse to stack practices, rules or roles on top of Scrum. Instead, Scrum can wrap many practices, as tactics to apply the overarching rules, principles and values. Such are inclusive practices. Inclusive practices are needed and even make out a specific manifestation of Scrum. When inclusive practices are applied well, cohesion is preserved in the resultant system that is still recognizably… Scrum. “ScrumAnd” is more about the overarching rules, principles and values of Scrum, than it is about inclusive practices.

“ScrumAnd” starts, and ends, with Scrum. Many roles and domains exist that may not be covered by Scrum, for which Scrum has no rules, events and artefacts in place. Practices in such domains can help an organization get more out of Scrum. They are complementary practices. Complementary practices don’t change your manifestation of Scrum. The “And” in “ScrumAnd” is not about complementary practices.

“ScrumAnd” supports thinking about how to get more out of Scrum, how to be more effective in employing Scrum, and gain agility.

The syntax of “ScrumAnd” -if any- might look like:

Illustrations of “ScrumAnd”:

  • “YES, we have a Product Owner,
    AND a dedicated, full-time Product Owner, acting from a business perspective, with a mandate, and clear decision authority increases our agility in terms of customer proximity.”
  • “YES, we have a Product Backlog,
    AND going from using it merely as an inventory of exhaustive specifications to experiencing it as a collaborative instrument that helps us focus on what is really important and valuable increases our agility in terms of our ability to deal with unpredictability.”
  • “YES, we have a definition of Done,
    AND expanding it beyond producing only coded, tested or even integrated work to creating releasable and valuable Increments increases our agility in terms of our ability to deliver actual value (and close the feedback loop with the customer base).”

The illustrations of “ScrumAnd” are just that, illustrations, representations of what might work, like some earlier illustrations. There are no universal definitions, labels or boundaries, not within an individual “ScrumAnd”, nor across several of them.

And then complexity comes into play.

“ScrumAnd” illustrations can be created for all elements of the Scrum framework. The implied “ScrumAnd” stance shifts the mind to the exploration of options and possibilities, patterns of improvements, away from the frame (Scrum) or obstacles only.

And then complexity comes into play. There is a “ScrumAnd” in understanding and employing “ScrumAnd”. “ScrumAnd” is not for judging or assessing, it is more than a simplistic model of linear progression, more than phases, maturity or other levels. Inspection without adaptation is pointless anyhow, to start with. Despite the possible creation of individual “ScrumAnd” representations, the topics they target are necessarily connected, matched, intertwined. They reinforce or diminish each other without clear cause-effect relationships.

Complexity kicks in even more. One “ScrumAnd” may not result in improved agility through Scrum. Improvement requires concurrency and comes in Increments too. Reversely, increased agility through Scrum cannot be attributed to one “ScrumAnd” alone. “ScrumAnd” abides by the sfumato principle, the reality that reality has layers and shades of gradual progression, shadows rather than cold delineations, monochromatic color areas and binary separations.

  • A PDF of this text is available for download
  • The “ScrumAnd” poster (PNG) is available for download
Posted on by — 4 Comments

A Mirror of the Scrum Master’s Work (so far)

Introducing “ScrumAnd”

Jigsaw Scrum

Adopting Scrum best starts by doing Scrum in the first place, getting all the formal elements of Scrum in place. It is like a jigsaw that isn’t complete until you have fitted all the pieces together. Luckily Scrum doesn’t have many pieces: 3 roles, 3 artifacts and 5 events. A simple set of rules can emerge complex behavior.

This ability to say “Yes, we do Scrum” however is only the start, not the end. Scrum is not the goal, Scrum is a mean to a goal. In order to increase the benefits, the way Scrum is used is to be maximized, thereby moving to “Yes, we do Scrum. And…“. There is a “ScrumAnd” for a myriad of elements. In the post Illustrations of ScrumAnd this was demonstrated through (1) the Product Owner role, (2) the ability to create releasable Increments and (3) the level of collaboration within a team.

Note: in 2018 I elaborated on the topic by describing how the ScrumAnd stance requires though and discipline.

Applying the “ScrumAnd” model on the role of the Scrum Master.

The Scrum Master facilitates Product Owners, Development Teams and the wider organization with services. The benefits gained through Scrum depend on the services provided by the Scrum Master. Or is it the other way around?

ScrumAnd - Scrum Master

It is unfavorable, difficult and probably impossible to forcefully command people, teams and organizations into higher performance. In a “ScrumAnd” view on the Scrum Master role, there is less of a deliberate choice or strategy involved to increase benefits.

Teams though can be facilitated and wisely lead into benefits that will last. Yes, you do Scrum if you have a Scrum Master. And the level of services that the Scrum Master provides probably reflects the state of Scrum:

  • A Scrum Master teaches techniques for others to use; how to manage Product Backlog (syntax, sizing, splitting, grouping, descriptions, refining, dependencies), how to create visibility of progress (burndown charts, Scrum boards, cards, velocity, release plans), creating a definition of Done, how to plan and execute a Sprint, how to do a Sprint Retrospective meeting, the value of time-boxing.
  • A Scrum Master helps teams and their wider environment optimize the use of Scrum through Scrum’s foundation in empiricism; how Scrum implements transparency, inspection and adaptation, how Scrum helps when only the past is certain and the future is uncertain and highly unpredictable.
  • A Scrum Master shifts the focus from using Scrum to deliver on a set expectations (scope against time and budget) toward organizing work for creating the most valuable outcome; shifts focus from the process itself to the goal of the process.
  • A Scrum Master focuses on behavior, instead of ‘process’ and even outcomes. Accountability drives behavior, and behavior becomes grounded in the Scrum values, and Scrum is understood and applied through the values and principles expressed in the Manifesto for Agile Software Development.
  • A Scrum Master is present with a team, and within the organization; a silent, non-intrusive, mentoring, comforting, observing presence.

Scrum Masters are often expected to operate on the practices end, to be teaching techniques. Development Teams might want it because they have always been told what to do. Managers might want it because it is as close as they feel a Scrum Master can get to executing control in this new way of working. Scrum Masters themselves have the intrinsic desire to be invisibly present.

Whenever a service is needed, by the Scrum Master’s observation or by explicit request, a Scrum Master assesses the service level required depending on the requester, context, time. The happiest moment for a Scrum Master occurs when teams push back for being provided with too low level services.

The service that the Scrum Master is providing becomes a mirror for the Scrum Master’s work so far. Complexity equals instability, by default. Staffing changes (in the teams and in the organization), relationships change, strategies and objectives change, technologies change. A Scrum Master keeps going back and forth, up and down through the range of services possible. A Scrum Master cannot expect to steadily provide only one type of service.

Where are you, as a Scrum Master? What services are requested from you? Do you provide services that reflect the actual maturity of the team and the organization’s understanding and usage of Scrum?

Posted on by — 9 Comments

Illustrations of ScrumAnd

Although Scrum has an acknowledged body of knowledge, the Scrum Guide, it is -by design- incomplete. Scrum is a framework, not a methodology. With Scrum, an empirical foundation is created from which the details and specifics of the actual working processes emerge. And while the actual working processes keep evolving, the foundation of Scrum provides stability.

Scrum needs the continuous selection, application and revision of good practices, strategies and tactics to be really effective. The rules in themselves provide foundational guidance. The effective benefits an organization gets from Scrum largely depend on how the game is played. Ultimately the benefits gained from Scrum will vary with the implementation, usage and application of Scrum; from roles, rules, players, and principles to techniques, practices, strategies and tactics.

Doing Scrum, and doing it properly, is only the beginning. Yes, you do Scrum if you have the formal elements in place. And from that much more beauty comes within reach. We refer to this idea as ScrumAnd.

Yes, We Do Scrum. And

There is a ScrumAnd for a myriad of elements included in or attached to the use of the Scrum framework. I will illustrate the ScrumAnd potential to augment the fun, energy, and benefits from Scrum upon 3 elements only:

1. The Product Owner role

Yes, you do Scrum if you have a Product Owner. And you will do even better depending on how the role is fulfilled:

Yes, We Have A Product Owner. And

Scrum is at first often implemented as the new IT-process, or is started within the IT-departments exclusively. So, a business analyst is put in the role. In organizations suffering from the traditional Business-IT dichotomy, it is often much later that business comes into play; forcing themselves in or being invited to do so.

  • A (business) Analyst in the role has limited benefits. But development organizations feel like securing control over the process with an analyst as Product Owner; just because it is an IT-person (‘Can’t trust business people!’). However, for many decisions the analyst doesn’t have the answer, needs to revert to product management, look at the project manager, wait for an external decision, get an upfront approval from a steering committee. Every time the Development Team is halted, must wait, pick up other work, restart previous work, park work for a longer time. No flow, no value.
  • A proxy for the business, like an account manager or other gap bridging alternatives, is slightly better. Control remains with IT (‘Still can’t trust business people!’) but IT puts a person in the role who is closer to the business, who is more connected to the business. It creates less delays, less waiting time, less hick-ups; although many of those remain.
  • Often the business gets a smell of the role and sees the fun and advantage of it, or the organization just opens up to broader collaboration. A person is sent in from a business or product management department to fulfill the role. It is another improvement. There is more direct availability of functional knowledge and stakeholder expectations. Yet, still much waiting time for decisions by the real authorities, as the business representative often has limited autonomy in his representation of product management aspects to the development organization.
  • It works better if the person is not only from business, but also has the trust and the mandate to take decisions (on the spot). A mandate is a signal that the role is taken more seriously. Often the person in the role is allowed to spend more time on it. Less hick-ups, less context and task switching, largely improved flow. The Development Team can focus more, and get things done.
  • It is great if the Product Owner is a mini-CEO over the product, a real owner of the product (what’s in a role’s name, right?), a business person with full (functional and budgetary) responsibility over the product and knowledge over all product management aspects (marketing, competition, users, legal, finance). The person’s professional life is dedicated to the well-being of the product. They don’t come much better than this.

2. Releasable software

Yes, you do Scrum if you have a definition of Done. And you will do even better when it reflects ‘releasable’ and all work for it can be done within a Sprint (not post-Sprint):

Yes, We Have A Definition Of Done. And

Scrum has no exact prescriptions for software development practices. However, the empiricism of Scrum thrives on transparency. A part of transparency lies in common standards and agreements, to drive inspection and adaptation. Engineering standards are a crucial part of that. Engineering standards guide the definition of Done, give focus to a team in getting stuff done, help a team in forecasting Product Backlog for a Sprint, define quality, create accountability.

  • Development (here as synonymous to ‘programming’) is quite essential in the wonderful world of software development. Without it, no result, right? And although the importance of it is often even underrated (think of the separation of design from development in separate, upfront phases), programming in itself is hardly enough. Although code aspects like clear code, self-explanatory code, naming conventions, refactoring are very important, it is only the start. But for sure, without development (‘coding’), no progress as there can’t be any working software, the primary measure of progress.
  • Code requires testing. And if all testing is to be done within a Sprint, testing skills are required in the Development Team and testing becomes part of the development activities. Testing is minimally needed at a technical unit and at a functional level. It gets even better if this part of development can be done first, can be automated as much as possible and is performed progressively within the Sprint, not just toward the end of the Sprint.
  • The releasability of an Increment, produced by the end of a Sprint, takes a giant leap if all integration, regression testing and alike work is done within the Sprint, and within the Sprint across multiple teams working on the same product or dependent products. It does help additionally if also this work can be automated and is done progressively in the Sprint, not just toward the end of the Sprint.
  • Teams can do better if they not only have the skills, access and mandate to perform QA work in the Sprint, but are also facilitated by organizational guidelines for quality, designs and architecture. No rework arising from QA on earlier Increments disrupts a current Sprint, or must be added to the Product Backlog. It does help additionally if any QA work can be automated and is done progressively in the Sprint, if quality is built in into the product and not just verified toward the end of the Sprint.
  • Even when doing Scrum, many organizations foresee additional stabilization time to prepare an Increment or a set of Increments for an actual release. Imagine the gain if this work can be done within the Sprint. Every 2-3 weeks a truly potentially shippable Increment of software is available, that can be brought to the market without additional costs or work. A good time to start thinking about continuous delivery.

3. A Collaborative Team

Yes, you do Scrum if you have a Scrum Team with a Development Team, a Product Owner, and a Scrum Master. And you will do even better when the team can improve its relationships and collaboration, often by remaining stable:

Yes, We Are A Team. And

Self-organized team work is the corner stone of Scrum. Teams however cannot be built or constructed like a mechanical object. With support, cherishing and nurturing, a collaborative team might gradually emerge.

  • A team gets formed by bringing a group of people together, preferably -but not always- in a shared workspace. Most of them are in observing mode, are keeping some distance. Formal arrangements and agreements get made, possibly including team agreements, engineering standards, a definition of Done, team values, meeting timings. And the team formally starts following them. Gradually people start expressing deeper thoughts, ideas and concerns.
  • A team goes through some storming as the team members get to know each other better and start expressing options and ideas that don’t match exactly. They sort the differences out. At first they might take it personally only to find out later that they are not used to the others’ gestures, tone of voice and facial expressions. They find out and they build a sense of trust.
  • The group of people jells better and better. The whole becomes equal to the sum of the parts. They become co-operative, they better align their individual work with the work of the others. They adjust their individual expectations to their team peers. They find a productive way to deal with conflicting ideas.
  • The team is really starting to know each other, even share more personal backgrounds. They have grown confidence in understanding each others’ remarks, stop taking comments personally. They stop looking for blame and stop covering up. A solution becomes the goal. As there is trust, and openness and honesty arising from it, they develop shared goals and are committed to these shared goals and objectives. Individual benefits are being sacrificed for the good of the whole.
  • The team has become a smooth, collaborative unit. Everyone’s focus is on the whole. The team members have passionate debates, engage on opposing ideas, look for the best possible outcomes and get their satisfaction from being part of the group. What used to take them hours and hours to sort out now only takes them a smile and a wink.

Organizations tend to overlook the scaling potential in the way Scrum is being played. Take advantage of these options first, enjoy the cumulative effect of multiple ScrumAnds and avoid the additional complexity that arises from volume-oriented scaling like adding people, adding teams, adding roles, adding phases.