Category: Scrum.org

Posted on by — 20 Comments

Scrum Master – A Manager

Manager – Traditionally

Traditionally an individual is declared a ‘manager’ when having hierarchical control over other individuals. A traditional manager exerts power. A traditional manager commands people through the assignment of to-be-done work; expressed as tasks or work packages, given on a daily base or via to-be-followed plans. Subsequently a traditional manager follows up on the execution of the assigned work. The traditional manager does not wait for the results of the work but wants to see how the work is being carried out, who is doing it, when the tasks are being performed and how much time it is taking. The time it takes is in general compared to the time that was instructed the task should take.

This and other performance information is recorded and stored, mostly in reports and other forms of documents. The traditional manager (in)frequently uses the stored information to evaluate a subordinate in order to steer that person’s career; via carrots like education, promotion, incentives, bonuses, salary. The traditional manager acts as the one who knows it all, and is supposed to act in the best interest of the company and its shareholders, even if that interest is obscured from the people assigned with the actual productive work.

Not limited to, but certainly in a context of agile, there is not only no need for a ‘manager’ behaving according to this authoritarian pattern and traditional expectation, it is even highly counterproductive and extremely discouraging. Dan Pink - DriveIt undermines enthusiasm, disregards intrinsic motivation by focusing solely on extrinsic motivators, kills job satisfaction, is an open door for politics and bribery and is therefore catastrophic for an organization depending on people. It is without doubt disrespectful and inhumane.

Is the notion of ‘manager’ therefore forever corrupted? Evil by default? A lost case?

Management – Actually

Scrum, like all things agile, has a very different viewpoint on working with people and on the aspect of management, but it does not the disregard that the activity of managing is required.

Let’s explore this different perspective upon the statement that “Scrum Master is a ‘management’ position”.

Indeed:

  1. A Scrum Master is a manager. Contrary to the traditional idea of a ‘manager’, a Scrum Master has no formal power over the people in the Development Team, not deciding over their careers, incentives, etc. A Scrum Master does not manage the people or their tasks. But a Scrum Master does manage (via) the Scrum process. Within an organization a Scrum Master is accountable for the maximization of Scrum, for ensuring that people, teams, departments and the organization realize the highest benefits possible from using Scrum. A Scrum Master is accountable for the way Scrum is understood and enacted. This requires management skills, traits and insights.
  2. A manager is a Scrum Master is a manager. A Scrum Master is explicitly responsible for removing Impediments. Impediments are elements that limit the efficiency and progress of a Development Team in areas that are beyond the reach of self-organization of a Development Team. Impediments are most often found in the wider organization, in company processes, procedures, and structures. Removal of Impediments works better if the Scrum Master is a manager turned Scrum Master, thereby adopting facilitation as the primary management tool and seeing the workfloor as the primary habitat.

A Scrum Master indeed is a manager, albeit not in the traditional sense. It is clear that a Scrum Master does not manage budget, people, work and tasks. Product Owners manage investments. Teams manage themselves. However, self-organization as promoted through Scrum does require goals and boundaries. A Scrum Master manages the boundaries that Scrum provides to augment self-organization; time-boxing to limit risk, focused efforts, cross-functional collaboration, releasable results, validated learning.

The Scrum process does no more than framing the creativity of people in their joint creation of valuable software. The process of Scrum lays out a foundation for rhythm and discovery. A Scrum Master manages the Scrum process through the provision of specific services like removing Impediments, facilitating teams, educating the organization, coaching people and keeping the road open to perform, to work, to innovate, to be creative. The services that the Scrum Master provides, needs to provide or is allowed to provide become a mirror to the state of Scrum in an organization.

Scrum Master can be seen as a management position because the Scrum Master role holds what is expected from a manager in an agile context, not because it reflects what traditionally is expected from a manager. A managing Scrum Master is a wise leader that engages people through organizational purpose and vision.

Manager – A Scrum Master

A manager who acts like a Scrum Master optimizes the value of management to the organization. The optimization lies not in commanding and controlling tasks and detailed work items. The value a manager brings lies in identifying wasteful activities, eliminating waste, removing impediments, embracing complexity by assuring Scrum is understood and enacted, from its principles and roots in empiricism, building on the core Scrum Stance, propelling on opportunistic experimentation, setting goals, and maintaining purpose.

The Scrum Master-manager is strongly affiliated to the Lean idea of “Go See“. A manager turning Scrum Master is a person that does not hide in a far-away office. Not hiding is much more than merely creating an open door policy. An open door is a fake measure, as it still lays the burden with the people wanting to see and talk to the manager. The workfloor buzz does not enter through that door. The flow needs to be reversed. The Scrum Master-manager walks around, is part of the workplace with the teams, the place where the real value is created. In Lean this place is referred to as Gemba.

It can even be taken some steps further with the idea of Empirical Management.

Management – Definitely

Even in an agile context, the act of managing remains a valuable activity. The act of managing is performed by managers.

Teams manage themselves. They organize their work autonomously. They are managers too. Product Owners manage the product’s vision and the investments in the product. Others manage boundaries, company objectives and identity, technical environments, the Scrum framework. ‘Management’ is the collection of all such activities. Management done properly thrives on servant-leadership. ‘Management’ is not a collection of people executing hierarchical powers. It is an emergent, networked structure of co-managers, people with complementary skills, focus and accountability, mutually exchanged services. All seek direction. Collaboratively. Continually. Skills and meaningful conversation prevail over title, hierarchy and position.

“What you say has priority over how you look.”

Is a manager who turned Scrum Master still a manager then?

Posted on by — 4 Comments

A Software Development Profession

Creative, artful thinking and craftsmanship are ESSENTIAL QUALITIES for any software developer. But shouldn’t software development be about more than an act of art, a craft in best case? Isn’t there a need to add professionalism to it? Shouldn’t software development be a profession?

It is tempting to believe that software development already is a profession. After all, many people are employed in developing software, making a living out of creating and sustaining the working code of software products and services, as a team or as individuals. Many more are employed in and make a living out of all the side-activities in the wider software development industry; like funding, exploiting, selling, promoting software products and services. This however is not sufficient to state that software development already is a profession.

Some take their dreams for real and call software development a profession. For others it is more a matter of pride, status or ego to say they are part of a profession, instead of an artisan discipline. That still is not enough to state that software development already is a profession.

A profession has regulations, codes, expectations and rules, all building upon a recognized body of knowledge. A profession sets explicit expectations on ethics, conduct and behavior to be demonstrated by any member of the profession. Official exams are in place for members to demonstrate a level of required skills and knowledge before receiving an attestation, and the permission to bear an official title that is protected and reserved. A healthy profession’s regulations and standards have a purpose, a purpose that goes beyond self-serving the profession and the profession’s institute. All regulations and standards should serve to assure the best possible execution of work in order to protect the people and organizations taking part in or being subject to the profession’s activities and its outcomes, and the decisions taken as part of it.

It is difficult to predict if and when software development might transform into a profession. It seems unlikely in a short term. There is the gigantic amount of software development work, there are the endless variations of what might be considered ‚software development,’ the absence of a widely accepted definition and understanding of ‚software development,‘ disagreement over the work activities that should or should not be part of the profession.

Reasonable doubts may be expressed on whether being a profession will augment the quality of service, avoid charlatanism, etc.

Furthermore a variety of people and instances may have personal, political, career, financial or other interests in software development, possibly even outside of the activity itself. Such people and instances might see regulation as a threat to their interests. Or might see it just as a limitation to their artistic freedom. Not to speak of the difficulty in growing a body, ethics, assessments, instructional guidelines and a code of conduct that would be widely accepted within the industry.

Where there are many elements that probably impede software development from growing into a regulated profession, there are also very valid reasons why software development would be better off if it transformed into a profession.

Not the least reason is the overwhelming and crucial presence of software in society and our daily lives. Software has become increasingly vital to society. A major shift is happening. Software products and software services are at the front and at the back of many public, industrial and consumer services and facilities. Software no longer is a ‚nice to have,’ for amusement purposes only. Software is at the heart of the economy. Software is core to many, often even critical, services in the private and in the public domain; financial services, taxes, energy, retail, health care, education, defense, telecommunication, transport, the automotive industry, just to name a few. Numerous organizations thrive on software. Even when they are not software companies, their services largely depend on software.

The omnipresence of software leads to a huge demand for talented and skilled software development people. The demand for professionalism that goes beyond talent and skills is less acknowledged but equally important in the light of the crucial functions of software in society. It would be comforting to know that the level of professionalism shown in the industry grew at the same rate as the growth of presence and criticality of software products and services itself, although even a higher rate is required.

Software development deserves professionalism in doing and in managing it. Such professionalism would benefit much from being structured in a profession.

This post is one of the inquiries I have planned into the values of professionalism in software development and the potential of the scrum framework to induce the formation of a software development profession. A matter of incremental writing. I hope you enjoy it, and the future follow-ups and iterations.

Posted on by — 4 Comments

Scrum – A Pocket Guide (3rd impression)

Gunther Verheyen, Scrum - A Pocket Guide (A Smart Travel Companion)Early 2013 I wrote the book “Scrum – A Pocket Guide“.

It was published in November 2013 by Van Haren Publishing. The pocket format used by my publisher coincides with the sub-title of the book “A Smart Travel Companion” and my views of Scrum as a journey, not a destination. Scrum is a journey toward increased agility, and my book is designed as a small guide that any traveler can easily take along.

Here’s what some of my best friends in the world of Scrum said about “Scrum – A Pocket Guide”:

Best description of Scrum currently available.

says Ken Schwaber, Scrum co-creator.

The book on Scrum I wished I had written.

says David Starr, also known as ‘Elegant Coder‘.

My publisher now informs me that the third impression is about to be produced (June 2014). It is still the first edition as the content is stable. The second impression dates from February 2014. I am humbled by this success and grateful for the appreciation.

If you have read the book, leave a review at Amazon UK, Amazon.com, GoodReads or one of the other shops where the book can be found. It provides me and potential readers with very valuable feedback.

Although Van Haren Publishing has its head quarters in the Netherlands, they have a great global distribution network. Here are some sources where “Scrum – A Pocket Guide (A Smart Travel Companion)” is available from, in varying formats:

And find many more search results at Google (24900 results), Bing (1110 results), Yahoo (1140 results).

Posted on by — 8 Comments

The Product Owner – An Entrepreneur

A vast majority of software development work concerns new product development. Every software product is essentially unique. We create previously non-existing products, suites, integrations and product extensions. We never create the same product twice. We expand existing products into the new product area. Competition, market expectations and technologies move so fast that acquired concepts, practices and approaches are outdated by the time they become well adopted, forcing us de facto into new product development anyhow.

Software development, as new product development through and in complex conditions, requires a startup mindset, no matter the size or age of the product or the master company. The Product Owner, as promoted in the Scrum framework, becomes an Agile Product Manager, the product’s president, its mini-CEO, an entrepreneur. The rise in complexity and uncertainty renders big plans into meaningless waste. The Product Owner drives iterative development from an exploratory attitude, aiming at incremental progress through continuing discovery and validated learning.

Every Sprint has a Sprint Goal as next horizon to work against. The Sprint Goal describes a (business) challenge, from an assumption of (market) value for the (Increment of) product. The outcome of a Sprint provides an important learning option. But the learning is only meaningful when it can be assessed against the product’s external impact and adoption; in affirming or negating the assumption of value underlying the Sprint Goal. The goal of the learning is to find out whether an opportunity is real, whether there is an audience willing to use the product, whether the audience appreciates the delivered functions.

In the absence of a release, value remains an obscure assumption. It is a major unknown and a risk for further investments. The unknown remains unresolved, and the risk is out of control, until the product is brought to market; be it a contained market segment, be it a limited or the full user base. With every Sprint without an actual release, the risk increases exponentially that the Product Owner runs out of tune with the evolving market and is wasting money, time and creativity. Increments of product, seemingly incomplete but offering minimal usable feature sets, provide the foundation for validated learning. Users need it to provide the Product Owner with feedback on the actual value of the performed work, the base to decide on the best future direction of the product. No document, design, paper document or simulation provides the same, high level of validation. Without that ultimate validation no informed decision over strategies or tactics can be taken, not in the least the decision whether to continue on the chosen path or to change direction.

Learning requires not only goals and feedback loops, but also measurements and data to support the validation process. Evidence of value is needed to confirm or contradict the assumptions. Evidence-Based Management can guide the entrepreneur and the stakeholders in their investment decisions.

Scrum can be at the heart of such entrepreneurship. Scrum frames the creativity of people to better deal with complexity and uncertainty. The empirical foundation of Scrum is a structured way to steer experimentation and discovery through frequent validation. In a situation where uncertainty is too big to plan, it is a way to make real progress; progress that is founded in reality, not in plannified imagination.

Seeing the Product Owner in Scrum merely as a requirements engineer, a requirements provider or someone to prioritize a preset Product Backlog is unlikely to help organizations capitalize on the entrepreneurial potential of Scrum. Seeing Scrum as a goal in itself results in gazing at internal performance, volume (of features, of hours, of points) and productivity (velocity or derivatives). Scrum is designed as a mean, a mean to maximize the value of software; value to the market and value to the organization and its people. Scrum is designed to make progress, grow and prosper trough validated, incremental learning. The Product Owner, the owner of the product, takes up the essential role of entrepreneur.

In today’s complex and unpredictable world, Scrum can be the engine of innovation and exploration. It is a choice though. It is your call on how you want to use Scrum.

Posted on by — Leave a comment

Happy Scrum Year

I hope your beginning of the year 2014 was as good as mine was. I wish you a great future no matter!

Crossing from one year to another is often a time for some retrospective introspections. It is a time where we more naturally step away from the daily, monthly and quarterly rush to look back and learn in the face of the upcoming times. As a result, but even besides it, it is also a good time to reground ourselves. Obviously we should retrospect and reground more often, but let’s say that this is a good time to absolutely do it.

My life has much to do with Scrum (below picture has some 2013 highlights). Here are some simple foundational aspects of Scrum I’ve ingrained over the years. They have often helped others to keep grounded or reground. These are bare basics that may seem non-essential at first sight. They have little value when respecting them. However, they become more essential when not respecting them. Not respecting them diminishes credibility in the communities, and it damages how Scrum is seen outside of the communities.

  • Stop calling Scrum a ‘methodology’. It is not. It is a framework. Note that we have even overcome the perception of Scrum as a method for ‘Agile project management’, and the Scrum Master as an ‘Agile project manager’. Focus on the software product, continuous discovery and value.
  • Stop writing Scrum in capitals (“SCRUM”). Scrum is not an acronym, nor an abbreviation. Write “Scrum”.
  • Cherish that Scrum is incomplete. It is by design. This is not a restriction nor a dysfunction. It takes away the illusive and deceptive certainty that from the method itself every possible answer, for every possible situation, at any possible time can be deduced. It actually applies to any method but only Scrum makes it an explicit tenet. Use Scrum as a foundation, and apply the ScrumAnd thinking to address your specific problems and situation.

Happy Scrum Year (2014)

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.