Tuesday, January 17, 2017

Show your work!


Myth: Teams show their work during Review
Variations:
  • During a good Review, developers show everything they have done
  • Every backlog item must be part of the Review
Follow-up myths:
  • The Review meeting is the (bi-)weekly status report where management gets to inspect the team's productivity
Category: General Scrum myths
Danger: High

The basis of the myth

There are many people who believe that the Sprint Review is a meeting for management to see what the teams did. Probably the most noteworthy source of misunderstanding is the SAFe4.0 Scrum Master Orientation, which names an event called the "Team Demo" where, quote, "Teams demonstrate every Story, spike, refactor, and NFR".

Why is it a myth?

There are some misconceptions about the nature of the product: First of all, the Review is an Inspect+Adapt event for the product, not for the work. Secondly, the 10th agile principle states, "Simplicity- the art of minimizing the amount of work done - is essential.", so teams should actually have done as little work as possible.

Assumption #1: "Work done" matters
Neither spikes, refactoring, bugfixing, tests, documentation nor models are customer relevant.
When you go to a restaurant, you don't care if the cook had to run to the nearest gorcery, get fresh vegetables, peel them, cut his finger, run to the doctor, get a tetanus shot and a bandaid, find a helper who can continue the peeling duty ... well, you care that you get a platter of food - preferably one that looks and tastes great.
What matters is tangible customer value. The customer cares about only one thing: "What can I use?" - as such, a Review should focus on the customer's perspective, not on the team's "Done" backlog.

Assumption #2: The team has to justify what they did
As a business owner, I don't care (at all) who did what. I care that I get what I paid for. If I don't get that, then it doesn't matter what the team did - they failed. If I get that, then it doesn't matter what the team did - they succeeded.
Typically, customers do not pay for spikes or refactoring - they pay for a useful product. If the team has no useful product to show, they have nothing to show. And they shouldn't bother inviting stakeholders to show nothing.



Assumption #3: The team is good when they did many things
Coming back to Agile Principle #10, the team is probably not good when they had to do many things. In many organizations, there is a pervasive culture that people should be busy. On the contrary, value creation works best when people are not busy!
Management must abolish the thinking that it's a good idea to track how many things developers did. If the value the team creates is worth the investment, the team is good enough. If that isn't the case - the team is working on the wrong things (i.e. the Product Backlog isn't good enough).

Consequences

Boring Reviews
When teams use the Review to tick off backlog items one by one, people will feel very bored. How often do you plan on attending events where people pretty much waste your time by overloading you with details that are completely irrelevant? Probably not often. Important stakeholders will stop attending, eliminating the entire purpose of the Review.


Lack of feedback
As teams force-feed their "work done" to others, the Review becomes a one-way communication channel. The primary intention of the Review, collecting feedback to maximize the value of the product, will be missing.


Utilization culture
Once teams feel the need to show their work and the Review focuses on demonstrating as much work as possible, the organization displays a utilization centered culture. As there is only one "center", this idea is contrary to the idea of customer centricity. Teams that learn showing as much work as possible is beneficial will lose sight of the customer and be unable to please the customer in order to maximize output.


Remedies

The Scrum Master needs to work with the Product Owner, teams and management alike to establish a Review that centers fully on customer value.
Questions such as "Why do you think this backlog item is important to the customer?", "Why do you [as a manager] care how the team completed this task?"and "What impact will the presentation of this backlog item have on the future backlog?" help the organization reflect on the current value of their Review meeting.

Monday, November 7, 2016

Mandatory PO task approval




Myth: Developers can't do Refactoring or architectural redesign without getting PO permission first.

Variations:
  • Technical tasks require PO permission.
  • The team only works on items presented by PO.

Follow-up myths:
  • The PO needs to understand the technology very well to properly prioritize the work

Category: General Scrum myths
Danger: High

The basis of the myth

Traditional project managers create a Work Breakdown Structure, laying out the details of the work to be done by the developers in detail. Everything on the WBS must be done by the developers, and everything outside the WBS is "not in budget", and therefore not done by the developers. The misunderstanding that a PO behaves like a Project Manager leads to the idea that the PO needs to approve all the work.


Why is it a myth?

The Scrum guide states that the PO is responsible for "Optimizing the value of the work the Development Team performs" and "Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next". The intention behind this: The PO has to take care that the investment into development is money well spent. When the team has to do certain work, it has to be done. In that case, the PO's approval is typically granted by default, because failure to do necessary work impacts the value of the product detrimentally.


Assumption #1: The PO personally manages the work
Some Product Owners feel the need to be in full control over everything the developers are doing. This is a very time consuming pastime without any real value to the product or towards customers. As per the Scrum Guide, the PO doesn't even need to do any of the backlog work - they can entrust all of this to the developers: It just needs to be clear that the PO has the responsibility that proper backlog management happens.

Assumption #2: The PO must approve technical tasks
While in general, every technical task has a value and cost associated, this is usually very difficult to express. What is the cost of not including this-or-that framework, what is the customer value of extracting a microservice? When the team decides that a certain activity is mandatory in the best interests of the product, it needs to be done. Refactoring is no different from testing: you won't ask the PO to approve testing, would you?


Consequences

Task focus
The PO focusing on technical tasks is looking more at the work done by the team than at outcome. This may blind them towards real customer expectation. A good PO should be able to completely ignore the "How" in the work and focus fully on the "What" in order to create a satisfying product.

Owning the work, not the product
The PO spending precious time to understand and approve every single technical task loses the same amount of time pondering the strategy of the product and exploring customer demand. Instead of owning the product, they become owners of a to-do list.

Micromanagement
As the PO involves with every technial decision around the product, they strip autonomy from the developers. This will form a dependency relationship where the PO becomes a key decision maker even for questions outside their domain of expertise. From micromanagement will come a culture of finger-pointing, blaming and distrust. 

Unsustainable development
When the PO gets a say in whether technical improvements are priority now or later, a business-savvy PO will often prefer another marketable feature over better technology. While this may be a good decision on some occasions, driving the product completely from a feature marketing perspective will result in fatal amounts of technical debt.


Remedies

When anyone feels that the PO should approve tasks, you should question the "Why". Potential reasons might include:

  • The team is not sure of the current priorities and market situation. In this case, the PO can support the team by providing deeper insight.
  • The PO does not believe that technical changes are necessary. In this case, the team might want to examine their own stance on "gold-plating".

Hardening Sprint




Myth: Every few Sprints, we need a Hardening Sprint to make the product robust
Variations:
  • Test Sprint
  • Bugfix Sprint
  • Integration Sprint


Category: General Scrum myths
Danger: High

The basis of the myth

Many teams come from a project-oriented background where "after the development work is done", if any time is left, remaining effort is put into stabilizing the product. As Scrum is product-oriented and intended to "last forever", these teams frequently suffer from accumulated technical debt. A well known solution is the Hardening Sprint to stabilize the product so that it can be shipped.
This myth was supported by the old use of "Potentially shippable product increment" (PSPI) in the Scrum guide, which gave leeway to the interpretation "Well, we don't ship just yet...", which has since been abolished in favour of the "Increment".

Why is it a myth?

The Scrum Guide clearly states that an Increment must be Done. This is explained literally as: "This Increment is useable, so a Product Owner may choose to immediately release it." There is no leeway to accumulate technical debt until a later date.
The Scrum guide does provide a certain amount of leeway for teams who are not sufficiently adept at Software Craftsmanship or work with an unsupportive product to weaken their Definition of Done to an appropriate level. This implies that team members and the organization understand their constraints and are actively working to continuously improve their DoD.
The institutionalization of a "Hardening Sprint" is contrary to the spirit of agility, namely: releasing value early and often.

Assumption #1: We can do the work later
Later, there will always be more work. That's the idea of a Product Backlog. At any point in time, the Product Backog contains the most valuable things to do. Any work for a backlog item that is deferred to the "Hardening Sprint" is either sufficiently important to do now - or sufficiently worthless to do never.


Assumption #2: We'll fix the bugs later
Many teams institute hardening Sprints because they don't have test results yet. A common misconception is that another team does the QA for the last Sprint while the developers code more stuff. To ensure that the current Sprint does not get disturbed by bugfixing, the bugs are postponed until the Hardening Sprint, where they are consequently eliminated.
Well - there are many issues here:

  • Scrum does not separate functions. The idea of a separate test team is un-Scrum. "Tests passed" would be part of a good DoD. 
  • Development and test should always be in sync. Practices like BDD etc. help in designing a defect-free product from the beginning.
  • As code always builds on preceding code, a defect found "down the line" will cause significantly more rework than a defect just created: Hardening Sprints create massive waste!



Consequences


Poor quality mindset
Developers should be proud of creating a product that is usable at any time. When they get used to the idea that "later, we'll get time to increase the quality", they will learn that low quality is acceptable.
As typically, there is always something more important and always one more bug, the product accumulates technical debt which is usually just kept at bay instead of systematically managed. 


Value denied
When the team relies on an upcoming "Hardening Sprint" before releasing an increment, the value of any increment is Zero until then. The incurred delay for delivery may be quite costly for the product organization.


Branching hell
As the product itself is "hardened" at a later date, emergency fixes are typically created in "branches". Since each fix needs to be stable both on Production and in the Increments, each fix will require an independent "bug branch". All of these then need to be merged during the Hardening, resulting in exactly the problems which Continuous Integration intends to fix.



Remedies

Abolish the concept of a "Hardening Sprint". It induces tremendous waste.

Think very carefully about which activities are considered necessary during a "Hardening Sprint". List them out explicitly and ask the following questions: "Why do we need this activity?" and "What would need to change so that we either don't need this activity any more?" If the latter is inconclusive, ask, "What would we need to change so that we can do this activity during each Sprint?"

Common solutions to fix the need for Hardening Sprints include:

  • A strong Definition of Done
  • Test Automation
  • Firm Engineering Practices, such as: BDD, TDD, Continuous Integration
  • Collective Code Ownership
  • Truly Cross-Functional teams (including Design, Development, QA and Ops)
  • Feature teams
  • Giving Developers a Prod-like development environment (thanks @Docker!)


Tuesday, October 11, 2016

No specialists!




Myth: Everyone should be able to do everything.
Variations:
  • Nobody should be specialized as anything.
  • We're looking for a Developer who is good in Frontend, Backend, Databases, Testing, Architecture, Design, UX, DevOps ....

Category: General Scrum myths
Danger: High


The basis of the myth

The Scrum guide says, "Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment" - which is misconstrued as "Every developer should be cross-functional".
It's an exaggeration/misunderstanding of the idea of "T-Shaped People"; the concept that people should be able to do everything, but specialize in one field.

Why is it a myth?

While a jack-of-all-trades-master-of-all is every IT manager's fever dream, there are two problems here:
1. There are probably not enough of these people in your network that you could fill a team with them
2. They're probably not going to work at the average rate of a software developer.
So, you're not going to get those people on your team. And since you don't have them - don't expect them to be.

Assumption #1: It's easy enough to know everything relevant.
Well, if it is - why don't you just grab a book and learn the necessary things about Frontend development over the weekend for a start? After you got that, maybe you can look into Software testing. At least that makes you a Frontend developer who can test their own code - no backend, database, UX ... yet. And when you're done, please re-visit those lists, because they might have changed. Keeping up to date in one field is hard enough. Keeping up in all would take so much time that no coding could possibly get done.

Oh, and we haven't talked about domain knowledge in your product yet.


Assumption #2: People can be good at everything
Yes, but not everyone can be good at everything. Everyone can be good at something.
Everybody specializes based on what suits them. Some people just have a knack on turning ideas into running code - while others are naturally gifted at finding the fly in the ointment. Some people can simply "feel" good design, while others are completely oblivious to the impact of their ideas on UX.


Consequences

Wrong team constellation
When you believe you've got the Jacks-of-all-trades, your team members are either coincidentially good at the things others are not good at, or you're missing something potentially important. 

Long staffing times
While waiting for "Mr. Right", you've probably missed a hundred opportunities to find the person who would have been perfectly suitable for your team. The harder you look for a jack-of-all-trades, the more you become blind to good opportunities.

Just asking to be fooled
Given how much knowledge modern development takes, a person who claims that someone can know everything is just asking to be fooled. Buzzword bingo and sly talkers will probably win the interviews in a company where hiring decisions are based on the jaded idea that someone, somewhere has found the Philosopher's stone and is just waiting to peddle it for pennies.


Remedies

Simply accept that people specialize.
Rather than asking people to do everything well, make sure people can do one thing that really contributes to the team - and they're sufficiently flexible to fill in the gaps as needed.

It's good to develop your team members to adopt new skills over time, but remember:
1. Nobody can know everything.
2. Attaining a new skill takes time.

Individual goals



Myth: People need personal goals
Follow-up myths: Variable salary based on personal goals

Variations:
  • Personal goals help people grow
  • Personal progress reports
  • Personal stretch goals
  • Division goals

Category: Development team myths
Danger: High

The basis of the myth

Management by objectives is a common method of traditional management. In many organizations, this is propagated downwards in the organization. Every person receives certain goals, oftentimes tied to some salary proportion for attainment. While MbO is not bad in and by itself, it is merely a legacy process that may not be suitable for Scrum.

Why is it a myth?

It simply doesn't have a place in Scrum. This has nothing to do with Scrum and is exactly the opposite of Scrum's idea of "shared team accountability".

Assumption #1: Individual growth helps
Growing each person is good, but they should grow into a stronger team. Anything that a team member does which does not further the team's objectives is actually counter-productive. Do we really want team members to invest time and energy into that? If not, why would we want to give them goals forcing them to do exactly that?

Assumption #2: Tying goals to salary makes sense
When my goals are tied to my salary, I'm stupid if I don't negotiate for goals that are difficult to attain. People typically negotiate goals that they can reach without much of a stretch. These goals do not help anyone grow.
On the other hand, a goal that requires something worthwhile learning within the (usually long) time for which the goal is defined, contains so many Unknowns that only the most gullible people would voluntarily agree to have them tied to their salary.


Consequences


Mis-Alignment
The Scrum value "Commitment" clearly states that "People personally commit to achieving the goals of the Scrum team". As soon as the Scrum team does not have exactly the same goal as the individual, the person must choose whether to pursue their goal, or the team goal. By tying a financial component to the individual goal, the person is dis-incentivized to pursue the overall team goal.
It is impossible to give different people the same team goal, but differing individual goals. This will cause schizophrenic behaviour within the team. The result will ultimately be a bunch of individuals pursuing their personal goals rather than one team pursuing a common goal.

Missing Sprint goals
When a team member is forced to choose between investing time into furthering their own, financially relevant - and the team's mutual (not that directly relevant) goal, most people will choose to first secure their own finances. This may cause team members to diverge from the team goals, which (if the Product Owner is doing a good job) maximizes the financial impact to business.
It is never a smart idea to encourage people to optimize their own situation in disregard of the company success.


Remedies

Get rid of any kind of system rewarding or promoting behaviors that are inconsistent with teamwork or the team's goals. Focus on teamwork, team goals and synergies rather than individual contribution.
Encourage people to grow within their team rather than by themselves.
If you can't really go without a reward system (which has already been proven detrimential in knowledge work), reward and promote behaviours which benefit the team and the overall organization.

This may require overturning the roles of division managers and existing HR processes - but unless you do that, you will never attain a truly gelled team.


Pigs & Chickens




Myth: The Scrum team consists of "Pigs" (committed) and "chickens" (everyone else).
Variations:

  • We treat people differently based on whether they are part of the team or not.


Follow-up myths:
  • Chickens don't participate in Ceremonies.
  • Chickens are not allowed to talk in the Daily.

Category: Development team myths
Danger: Low

The basis of the myth

The "Pig and Chicken" metaphor is often applied when there is a lot of outside interference with the team.
It is used by many agile coaches and trainers to convey the idea that members of the Scrum team should be absolutely committed to the team and those who are not committed might be a disturbing factor.
That is, the "pigs" on the team should only be working on items which do not contribute to the team's goals during the Sprint period, and nobody has the right to distract them. Those who are either distracted or causing distraction are unwelcome ("chickens").
The Scrum values "Focus" and "Commitment" lend credibility to this claim that Scrum team members should be "pig".


Why is it a myth?

Simply put, the metaphor isn't part of the guide.
And, for cultural sensitivity reasons, some people might be offended when they are told they should be "pig", regardless of how adequate the analogy is.

Assumption #1: Autonomy
When a Scrum team is not autonomous, then people who are not part of the team directly affect their success and are unequivocally contributing to the team's success.
Just like a child who can not wake up on time to go to school can not claim autonomy, a team which relies on external help can not claim autonomy.
Many fledgling Scrum teams are not autonomous in the sense of a meaningful Definition of Done. While it is aspirable to get there, during the journey, they better not discriminate against those they rely on.

Assumption #2: Separable goals
The "pig" may feel that their value to the success of the Ham+Egg restaurant depends much more on their contribution than on the chicken. However, the pig must understand that there will be no Ham+Eggs without a chicken, so the goal will not be attained. If business success depends on selling both Ham+Eggs, then the pig alone can commit all they want, they will still not succeed.
It is healthy to remember the contribution of others as essential, especially when the team stands at the verge of having to answer how they can pull the "chicken" capability into the team in order to get a better Definition of Done.


Consequences

Two-Class mentality
The "Pig-Chicken" metaphor creates a mindset where Scrum team members may disdain those not on their team. This can foster an extremely unhealthy, inappropriate elitism.
Even if the team was truly autonomous (even financially), elitism is not within the spirit of agility.
And when the team actually depends, it's especially harmful to look down on those you rely on.


Communication breakdown
The "Pig-Chicken" metaphor may lead developers to believe that "chickens" don't understand their problem or are of little or no help. Essential communication with outsiders may be considered a "waste of time", potentially resulting in huge opportunity losses. Even if the development team is fully autonomous, communication with the environment is part of natural Inspect+Adapt.


Remedies

The benefit of the Pig-Chicken metaphor is that it provides a simple explanation for discriminating who has the right to change team decisions and direction - and who does not.
However, it can quickly get overstretched and turn into a boomerang.

The best way is not to use it prescriptively in training or team building ("Define:Who is pig? Commit!") but only take out this analogy where it really makes sense - in situational coaching.

Monday, September 26, 2016

Flexible team members



Myth: Staff rotation helps teams learn
Variations:
  • We choose the team members at the beginning of each Sprint
  • Lots of 10-30% team members

Category: Development team myths
Danger: High

The basis of the myth

Some organizations transfer their classic Project organization into Scrum, where "resources" are allocated on the timeline based on presumed need. Others consider outdated HR mechanisms, such as staff rotation, a good way to bring fresh wind into a team.

Why is it a myth?

Scrum does not go well with the idea of "flexible team constellation". For example, the team should collaborate, and in order to collaborate, the team needs to have a good understanding of each other. Whenever a person leaves or a new person joins, the Working Agreements need to be reconsidered. Likewise, every person needs to reconsider their own role to maximize team success. This overhead destroys the delivery capability of the team. When done on a per-Sprint-basis, the predictability of the team goes to Zero: The team becomes ineffective.

Assumption #1: Teamwork does not take time
Probably the worst assumption causing people to decide for inconsistent staffing is ignorance of the cost of team formation. Teams need a few Sprints to stabilize. The faster the shift in staffing, the more likely the team will perform below their potential.

Assumption #2: Resources
You can easily take a monitor to a different desk, and you can just as easily install new software on a server. But people are not resources. People need to get familiar with their environment and people around them. This adjustment has tremendous impact on productivity. The cost of a change in staffing should be carefully considered.



Assumption #3: Expendability
Some managers still falsely assume that everyone is replacible, so they do exactly that: Replace people with others, in order to optimize utilization. Disregarding whether a person can easily be replaced, the problem is that "it costs more to add a person to a team than to remove a person from the team". The replacement affects the entire team.

Assumption #4: Timesharing
When team members are working only a fraction of their time for the team, we see two problems: Either, their work becomes queued while they are unavailable, resulting in partially-done work, or they equally get disrupted and disrupt the team. There's some numbers floating around that as the amount of projects a developer is engaged with exceeds 2, effectiveness quickly goes to Zero: Why have ineffective team members?

Consequences


Low performance
As teams rearrange, their performance takes a hit. Based on experience, the team's performance stabilizes after about 3-5 Sprints. Occasionally, onboarding will obliterate the team's delivery capability and reset it to Zero. Sometimes, this turns into the disease of rotating even faster, until nothing ever gets done any more. This is not the fault of the new team member, but a flaw in the system.


High cost
The reduced team performance directly translates into increased delivery costs. As cost-per-feature increases, the business case turns sour. Flexible teams are probably the easiest way to ruin an otherwise profitable venture.


Morale
Teams working as teams also have "team spirit". Continuously shifting people in and out of the team makes it difficult to build up morale. Potentially both the core team and the fluctuating members will be challenged to remain motivated for the team's vision when there is no constancy of purpose.



Remedies

Get over the ideas of project thinking and resource utilization.
Consider the total cost of the team, not just the cost-per-person. Factor in the long-term cost of change.
Make changes to the team constellation sparingly and consequently.
Communicate clearly why and when team constellations change.
Give the team time to stabilize.
Do not use management intervention to bring skills into the team. Trust them to acquire skills by any means necessary and only act on demand.