Tag Archives: accountability

The Scrum Master and Product Owner as leadership partners

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

After a recent large organizational change that resulted in a number of new teams formed, a product owner (PO) approached me looking for some help. He said, “I don’t think my new Scrum Master is doing their job and I’m now carrying the entire team, do we have a job description we can look at?”

I can already imagine how a version of me from a previous life would have responded, “yes of course let’s look at the job description and see where the SM is falling short of their roles and responsibilities”. But as I considered my response, my first thought was that focusing our attention on roles and job descriptions was a doomed route to failure. Pouring our energy there would likely just extend the pain the PO, and likely SM, were going through.

Sure we have an SM job description in our organization, and it clearly documents how the SM provides service to the organization, team and PO. But reviewing this with the seasoned SM didn’t really make sense to me; they were very well aware of the content of the job description and what was expected of them.

At the same time that this was happening, another newly paired Scrum Master asked for my help regarding their PO. From their perspective the PO was “suffocating” the team. The PO was directing the team in many aspects of the sprint that they felt was stepping beyond their role. “I don’t think the PO knows their role, maybe you can help me get them some training?” was the SMs concluding comment.

Over the course of the next few weeks this scenario played out again through more POs and SMs sharing similar challenges. Surely this was not a sudden epidemic of previously performing individuals who now needed to be reminded of what their job was?

Recognizing the impact of change

A common pattern was emerging from all of this, change was occurring and each individual was relying on, and to some degree expecting, old patterns to continue to work with their new situation. Their old way of working in Scrum seemed to work very well; so it was everyone else around them that was not meeting expectations.

The core issue however was that change was not being fully confronted: the product was different, the team competencies were different, the stakeholders were different, the expectations were different and finally the team dynamic was different all the way down to the relationship between the SM and PO.

Scrum as a form of Change Management

I looked for the solution from Scrum itself, at its heart a method for teams to use to adapt to and thrive with change. Was there enough transparency, inspection and adaptation going on between the SMs and POs in these situations? I would argue, not enough.

A pattern was becoming clear: nobody was fully disclosing their challenges to the other, they hadn’t fully confronted and understood their new situation and hadn’t come up with new approaches that would improve things. Said another way, they hadn’t inspected their new circumstances sufficiently and transparently enough so that they could adapt their role to fit the new need.

One thing that many successful SMs and POs recognize is that they are both leaders dependent on each other, and for their teams to be successful they need to figure out how they will work together in partnership. It doesn’t matter whether the terms of that partnership gets hashed out over a few chats over coffee or through a facilitated chartering workshop. What matters is clarity around how you agree to work together as partners meeting some shared goal.

As an SM or PO, here are some sample questions whose answers you may wish to understand and align on:

  • Do we both understand and support the team’s mission and goals?
  • What are the product goals?
  • How can we best help the team achieve those goals?
  • Are there any conflicts between the team and product goals?
  • When our goals or methods are in conflict, how will we resolve them?
  • In what ways will I be supporting your success as an SM/PO?
  • How will we keep each other informed and engaged?
  • Should we have a peer/subordinate/other relationship?

So if you are an SM or PO, and it’s unclear to you on the answers to some of these questions, you may just want to tap your leadership partner on the shoulder and say “let’s talk”.

Dec17-368b

Martin Aziz
Blog
@martinaziz
LoyaltyOne

 

 


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

The Agile Manifesto – Essay 3: Working Software over Comprehensive Documentation

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

How much documentation does it take to run a project with ten people working for six months?  For some organizations it takes way too much:

Photo of heavy documentation for software project

This binder (about 3 or 4 inches thick) is all the documentation associated with such a project.  In looking carefully at the project, creating the documentation took far more time than the time spent on designing, writing and testing the software.  Yet, the documentation does not produce any value.  Only the software produces value.  The Agile Manifesto, asks us to focus on the outcome (working software) and to make tradeoffs to minimize the means (comprehensive documentation).

The Agile Manifesto asks us to challenge our assumptions about documentation.  In many work environments, documentation is an attempt to address some interesting and important needs:

  • Knowledge sharing among stakeholders and the people working on a project.
  • Knowledge sharing across time as people come in and out of a project.
  • Verification and traceability for contracts or other compliance needs.
  • Decision-making and analysis for business and technical problems.
  • Management oversight and control.
  • Various aspects of individual accountability.

Documentation is usually heavier (more comprehensive) the more the following circumstances exist in an organization:

  • Geographical distribution of people.
  • Lack of trust between people, departments or organizations.
  • Regulated work environments.
  • Depth of management hierarchy.
  • Number of people directly and indirectly involved.
  • Knowledge and skill sets highly segregated between people.
  • Culture of respect for written texts.

Working Software

What if the software itself could address the needs that often documentation is used to address?  Let’s look at them in turn:

  • Knowledge sharing among stakeholders and the people working on a project.
    If the software is functional at all stages, as supported by Agile methods such as Scrum and Extreme Programming, then the software becomes an effective representation of the knowledge of all the people who have participated in building it.
  • Knowledge sharing across time as people come in and out of a project.
    Software that is technically excellent is often easier to understand for people who are new to it.  For example, excellence in user experience and design means new users can get up to speed on software faster.  Use of good design patterns and automated testing allows new developers to understand existing software easily.
  • Verification and traceability for contracts or other compliance needs.
    Test-driven development (code) and specification by example (scripting and code) are forms of traceable, executable documentation that easily stay in-sync with the underlying software system.
  • Decision-making and analysis for business and technical problems.
    In particular, diagrams can help a great deal here.  However, electronic tools for creating such diagrams can be slow and awkward.  Consider the practice of Agile Modelling (basically using a whiteboard and taking photos) as a good alternative to precise technical diagramming if you are doing problem-solving.
  • Management oversight and control.
    Reports and metrics drive much of the traditional documentation in an organization.  Simplifying reports and metrics often leads to a clearer picture of what is going on, reduces the opportunities to “game” the system, and always results in lower levels of documentation.  As well, some reports and metrics can be generated 100% through automated means.  All that said, the fundamental premise in the Agile manifesto is that management should base decisions on what is actually built – the “Working software” by looking at it and using it.
  • Various aspects of individual accountability.
    If you really need this, a good version control system can give you the information for this.  Sign-offs and other types of accountability documentation are typically just waste that doesn’t actually help in process improvement.  Most people who are in high-compliance environments already have licenses and/or security clearances that provide this accountability.  If you software is working, however, then this isn’t even a concern as trust is built and bureaucracy can be reduced.

In my recent training programs as research for this article, I have surveyed over 100 people on one aspect of documentation – code documentation.  Every individual surveyed is either currently coding or has a coding background, and every single person had the same answer to a simple scenario question:

Imagine that you have just joined a new organization and you are about to start working as a software developer.  One of the existing team members comes up to you and introduces himself.  He has with him a piece of paper with a complicated-looking diagram and a full binder that looks to be holding about 250 pages.  He asks you, “you need to get up to speed quickly on our existing system – we’re starting you coding tomorrow – would you prefer to go over the architecture diagram with me or would you prefer to review the detailed specifications and design documents.” He indicates the one-page diagram and the binder respectively.  Which would you prefer?

(I’ve put up a Survey Monkey one-question survey: Code Documentation Preference to extend the reach of this question.  It should take you all of 60 seconds to do it.  I’ll post results when I write the next Agile Manifesto essay in a month or two.)

The fact that everyone answers the same way is interesting.  What is even more interesting to me is that if you think through this scenario, it is actually almost the worst-case scenario where you might want documentation for your developers.  That means that in “better” cases where documentation for developers may not be as urgent or necessary, then the approach of just going to talk with someone is a lot better.

Documentation and Maps

The problem with documentation is the same problem we have with maps: “the map is not the territory” (quote from the wisdom of my father, Garry Berteig).  We sometimes forget this simple idea.  When we look at, say, Google Maps, we always have in the back of our consciousness that the map is just a guide and it is not a guarantee.  We know that if we arrive at a place, we will see the richness of the real world, not the simplified lines and colours of a map.  We don’t consider maps as legally binding contracts (usually).  We use maps to orient ourselves… as we look around at our reality.  We can share directions using maps, but we don’t share purpose or problems with maps.  And finally, maps assume that physical reality is changing relatively slowly (even Google Maps).

Many times when we create documentation in organizations, however, we get confused about the map versus the territory.

Agility and Documentation

Of course, code is a funny thing: all code is documentation too.  The code is not the behaviour.  But in software, code (e.g. Java, ASM, Scheme, Prolog, Python, etc.) is as close as possible to the perfect map.  Software is (mostly) deterministic.  Software (mostly) doesn’t change itself.  Software (mostly) runs in a state absent from in-place human changes to that software.  Software (mostly) runs on a system (virtual or physical) that has stable characteristics.  The code we write is a map.  From this perspective, documentation becomes even less important if we have people that already understand the language(s)/platform(s) deeply.


This essay is a continuation of my series on the Agile Manifesto.  The previous two essays are “Value and Values” and “Individuals and Interactions over Processes and Tools“.

 


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Comparison of the ScrumMaster, Product Owner, Project Manager and Team Lead Roles

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

Often in my classes, I’m asked for a clear comparison between the various traditional roles and the new roles in Scrum.  Here is a high level summary of some of the key responsibilities and activities that help highlight some important differences between these four roles:

ScrumMaster Product Owner Project Manager Team Lead
NEVER NEVER Assign Tasks YES
NO PARTICIPATES Create Schedule NO
NO YES Manage Budget NO
Remove Obstacles PARTICIPATES YES YES
NO Define Business Requirements PARTICIPATES NO
NO YES (Deliveries) Define Milestones NO
Facilitate Meetings NO YES YES
YES (process and people) YES (business) Risk Management PARTICIPATES
Organizational Change Agent NO NO NO
NO Accountable for Business Results RARELY (just costs) NO

Of course, there are many other ways we could compare these four roles.  What would you like me to add to this list?  Add a comment with a question or a suggestion and I will update the table appropriately!


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

The ScrumMaster is Responsible for What Artifacts?

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

Organizations like to have clear role definitions, clear processes outlined and clear documentation templates.  It’s just in the nature of bureaucracy to want to know every detail, to capture every dotted “i” and crossed “t”, and to use all that information to control, monitor, predict and protect.  ScrumMasters should be anti-bureaucracy.  Not anti-process, not anti-documentation, but constantly on the lookout for process and documentation creep.

To help aspiring ScrumMasters, particularly those who come from a formal Project Management background, I have here a short list of exactly which artifacts the ScrumMaster is responsible for.

REQUIRED:
– None – the ScrumMaster is a facilitator and change agent and is not directly responsible for any of the Scrum artifacts (e.g. Product Backlog) or traditional artifacts (e.g. Gantt Chart).

OPTIONAL/COMMON:
Obstacles or impediments “backlog” – a list of all the problems, obstacles, impediments and challenges that the Scrum Team is facing.  These obstacles can be identified by Team Members at any time, but particularly during the Daily Scrum or the Retrospective.
Definition of “Done” gap report, every Sprint – a comparison of how “done” the Team’s work is during Sprint Review vs. the corporate standards required to actually ship an increment of the Team’s work (e.g. unit testing done every Sprint, but not system testing).
– Sharable retrospective outcomes report, every Sprint – an optional report from the Scrum Team to outside stakeholders including other Scrum Teams.  Current best practice is that the retrospective is a private meeting for the members of the Scrum Team and that in order to create a safe environment, the Scrum Team only shares items from the retrospective if they are unanimously agreed.  Outsiders are not welcome to the retrospective.
– Sprint burndown chart every Sprint – a chart that tracks the amount of work remaining at the end of every day of the Sprint, usually measured in number of tasks.  This chart simply helps a team to see if their progress so far during a Sprint is reasonable for them to complete their work.
– State of Scrum report, every Sprint – possibly using a checklist or tool such as the “Scrum Team Assessment” (shameless plug alert!).

NOT RECOMMENDED (BUT SOMETIMES NEEDED):
– minutes of Scrum meetings
– process compliance audit reports
– project administrative documents (e.g. status reports, time sheets)

NEVER RECOMMENDED:
– project charter (often recommended for the Product Owner, however)
– project plans (this is done by the Product Owner and the Scrum Team with the Product Backlog)
– any sort of up-front technical or design documents

The ScrumMaster is not a project manager, not a technical lead, not a functional manager, and not even a team coach.  There are aspects of all of those roles in the ScrumMaster role, but it is best to think of the role as completely new and focused on two things:
– improving how the team uses Scrum
– helping the team to remove obstacles and impediments to getting their work done.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

The Rules of Scrum: I do not track my hours or my “actual” time on tasks

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

Scrum considers tracking the time individuals spend on individual tasks to be wasteful effort.  Scrum is only concerned about time when it comes to the time boxes of the Sprint and Sprint meetings.  Scrum also supports sustainable development, which implies working sustainable hours.  When it comes to the completion of tasks, the team is committed to delivering value.  The tasks in the Sprint Backlog represent the remaining tasks that the team has identified for delivering on its committed increment of potentially shippable value for the current Sprint.  The tasks themselves have no value and therefore should not be tracked.  Scrum is only concerned about burning down to value delivered.  Time spent on individual tasks is irrelevant.  What if I track my hours or my “actual” time on tasks?  This promotes a culture of “bums in seats” – that it is more important for people to be busy at any cost instead of getting valuable, high-quality results.  This also promotes bad habits such as forcing work into billable hours even though it is not.  Overall, time tracking in a Scrum environment does much harm and can undermine the entire framework.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail