Showing posts with label TWEAK. Show all posts
Showing posts with label TWEAK. Show all posts

Tuesday, January 24, 2017

TWEAK: Willingness

When trust is given, it must be followed with a desire, a willingness. Willingness is "the other side" of motivation. Agile Development regards intrinsic motivation over extrinsic motivation, so when willingness is impeded, you must find out the root cause so that people can release their potential.
As a Scrum Master, you should consider, as taken straight from Dan Pink's "Drive":
  • Purpose: Is the product important to the:
    • Product Owner?
    • Customer?
    • Management?
    • Team?
    • Society?
    • World?
  • Autonomy: Who calls the shots on:
    • Team constellation?
    • New features?
    • Processes?
    • Technology?
    • Activities (e.g. team events)?
  • Mastery: Considering Shu-Ha-Ri. Where is the team regarding:
    • Being a team?
    • Their technology?
    • The Product?
    • The Market?
    • Agility?
Do not feel pressured to achieve full willingness within everyone, both management and the team, on day One. Moving a rather complacent individual to be highly willing may take a long time, depending on the circumstances and duration for which complacency had set in.

Saturday, December 26, 2015

TWEAK: Knowledge

Creating great products requires the right environment, the right people - but also the right knowledge. In an ever evolving world, knowledge is not something you can "have", but something to continually strive for. On the quest for mastery, knowledge needs to be taken with special consideration. For each domain, you should see if your team is "struggling to keep up", "well in the loop" or "forerunner". While not everyone can win the race, it is a good idea to invest effort into getting ahead of the game.

As a Scrum Master, you should encourage everyone to broaden their knowledge regarding:

  • Technical ExcellenceRegardless of whether it is Java, CSS, JavaScript, Databases or virtualization technologies - the team must be keen on their technical skills.
  • Engineering Practices
    Testing, Refactoring, Emergent Design, Automation and many others are all essential to build the product right - all of these are easy to learn, but extremely difficult to master. 
  • Product Domain
    Developers who are only technical experts will build the wrong product, unless they actively strive to understand the domain of the product they develop. Low hanging fruit may be out of your reach when you can't make the right connections.
  • Agility
    The ideal of infinite Return on Investment requires responding to demand without any delay. Every step you take to be more agile will pay off - but what steps are available to you?
  • Organizations
    The team must take steps to actively shape the organization in a positive fashion. To do this, they must understand well how their organization and the world around them "ticks".
Since "knowledge" itself is so broad, there is no definite way to approach broadening knowledge. You may read books, share experiences with your team or others in the organization - build up Communities of Practice, join Special Interest Groups or whatever you see fit. You need to make sure is that people are thirsty for more knowledge. You can't "push" knowledge. People must want it.

TWEAK: Ambition

Ambition is the desire not to just fulfil a duty, but to excel - do something better, achieve something better, be something better. There are many ways to increase ambition in a team, but Trust, Willingness and Energy are preconditions. Ambition is usually present in every person, but unfortunately dormant in poorly managed organizations.
As a Scrum Master, you should look out for these factors to raise ambition:

  • Feedback Loops: Acknowledge and credit:
    • Positive attitude
    • Good ideas
    • Good results
  • Opportunity: Provide the means for developers to:
    • try out new things
    • be themselves
    • Accomplish something
  • Safety: Give people an environment where they can safely:
    • Try things that might fail
    • Say the wrong thing
    • Be silly when they feel the need to

There are pretty much two styles of ambition. Negative ambition cares only for personal advantage and is destructive towards the organization. Positive ambition cares for mutually building things up and usually benefits the individual as much as the organization. Raising up ambition is as important as turning negative ambition into positivity.

TWEAK: Energy

Energy is how things are in motion. Low Energy usually implies that something, somewhere is impedited. Leadership activates energy, on which others either thrive. Similar to physics, in an agile environment, there is the law of "conservation of energy" , i.e. energy exists - the question is: In which state?
As a Scrum Master, here are some forms of energy to look for:
  • Motion: Do you see things happening regarding:
    • Improving the product?
    • Improving the process?
    • Teamworking?
    • Technical excellence?
    • Becoming a better organization?
  • Heat: Do you see people caring about these?
  • Light: Do people communicate about these, make them transparent?
  • Magnetic: Where is conflict or tension regarding these?
  • Nuclear: Where is unharnessed, raw potential to create motion, heat or light?

You must understand where the energy is - then, how it can be harnessed - and with whom to work. Where is the heat, where is magnetism - Do you want to shed some light, or set things into motion? There are many ways and there is no "final state". Harnessing energy is a continuous process, and the less directed it is, the more agile the organization becomes. 
The only important aspect of working with energy is: Always make sure the energy is positive. 

TWEAK: Trust!

Your team requires a high level of trust within, from the outside in, and towards the outside. Otherwise it will be difficult to perform properly: Performance will be wasted on "looking good" rather than "being good". Schemes and politics will reduce results accordingly, so trust is your primary factor to work with.

As a Scrum Master, here are the dimensions you should consider:

  • Does the team trust 
    • each other?
    • the Scrum Master?
    • their management?
    • Product Owner?
    • Customers?
  • Is this trust mutual?
  • What is the basis of the trust relationship?
  • Is the trust relationship also transitive, for example: Does the Product Owner also trust the Management dealing properly with the team?
  • Is the trust relationship also indirect, for example: Do Customers and Management trust each other?

Building trust is the first and most important pillar for team success. Only when trust is present, technical improvement activities will be effective.