Getting Things Done: The Art of Stress-Free Productivity by David Allen
My rating: 3 of 5 stars

The main learning – write everything you have to do down unless the task takes less than 2 minutes in which case do it immediately.  Get it all out of your head.

The five steps to mastering work flow

1. capture what has our attention
2. clarify what each item means and what to do about it
3. organise the results
4. reflect on the options
5. engage in chosen result

Leading Snowflakes: The Engineering Managers Handbook by Oren Ellenbogen
My rating: 3 of 5 stars
Overall this is an ok book but there are a couple of nuggets in it which are quite useful.

Initially there is the highlight the difference between makers and managers – the role of the manager being to amplify the team. It highlights the importance of balancing making and managing and the need for concentration in the making zone. The key for managers is not to measure your output but the output of the team.

When making something we can review it quickly, such as by running unit test on our code. As a manager we rarely review the decisions we make to actively learn from them. The book highlights the importance of this and proposes a template to achieve this and get more continuous feedback. These decisions could be to postpone a decision, but this itself is a decision. There are no right or wrong just different takeoffs between different approaches.

The importance of feedback is discussed and this being hard as a transition from a team mate to a team leader. I diverge from the book here as we should not only be getting feedback from the leader, all members of the team should feel comfortable providing feedback but it might be that the team leader needs to deal with harder situations. Dick Costolo, Twitter’s CEO, uses the term “The Leader’s Paradox” – as managers and leaders, we need to care deeply and thoroughly about our people, while not worrying about what they think of us. It is key to share your own lessons learned, to summaries and share written feedback, using the wrong medium to present a message and delaying feedback.

Getting things done by extreme transparency, reducing risk (releasing smaller chunks etc), planning, leverage peer pressure, retrospect & delegate. Using the Must, Delegate and External lists – where Musts are absolute musts that as a manager we must do, if it is not a must then we can delegate it. External are things which are outside of your sphere which impact you.

When moving from maker to manager people approach it with a view of productivity. In reality building trust should be a higher importance, both inside the team but (crucially) with other teams.

Optimise for value. Depending on the product phase this could be focusing on Acquisition – how to bring in more users, Activation – increasing the usage of the product, Retention – keeping the users using our product, Referrer – having happy customers who recommend our product, Revenue – making more money or gaining more customers. When we are uncertain optimise for getting answers fast, “If you can’t make engineering decisions based on data, then make engineering decisions that result in data.” (Kent Beck). When we have business certainty, optimize for predictability and optimise bottlenecks. “Companies fail when they stop asking what they would do if they
were started today, and instead just iterate on what they’ve already done.” (Aaron Levie) this statement is a bit contentious as there are many re-writes which have failed so this is not a proven answer but reviewing what you would do with what you know now is a very important task to undertake.

“Culture is to recruiting as product is to marketing.” (Dharmesh Shah). This is what attracts employees and keeps them. Building an inbound feed of candidates by showing what you are doing, exposing your culture and demonstrating your tech to attract people to work for you.

To build a salable team requires an alignment of vision (Will it move the company into a winning position? Is it big enough as an engineering challenge?), alignment of core values without which the team will self-destruct as such it might mean loosing some key individuals (e.g. Never let someone else fix our own mess, Loyalty to each other above all), distributed responsibilities (What can you expect of me? What can you expect of being part of this team?), sense of accomplishment.

You can’t empower people by approving their actions. You empower by designing the need for your approval out of the system (Kris Gale)

Humble Inquiry: The Gentle Art of Asking Instead of Telling by Edgar H. Schein
My rating: 3 of 5 stars
The book introduces three types of humility basic humility – the status in society you are born with, optional humility – the way we feel when in the presence of someone who has done great thing and here-and-now humility – when you are dependent on someone else. The humble inquiry comes from a place of interest and curiosity with here-and-now humility, this maximises the interest in the other person and minimises bias and preconceptions.

The book talks about espoused values, the values which we openly talk about e.g freedom, equality, etc, however these are sometimes in contradiction to tacit assumptions which are the values which are actually in action, e.g. poor education, discrimination. The problem with the humble inquiry is that cultures which value task accomplishment over relationship building and telling over discussing means there are cultural forces working against it.

The Johari Window contains four sections:

• Open Self – things we know about our self and others know too
• Concealed Self – things we know about our self but we hide from others
• Blind Self – things we don’t know about our self but others know
• Unknown Self – things which are known neither by our self nor by others

Through the use of the Humble Inquiry we can expand the amount of Open Self which a person feels confident to display, reducing the Concealed Self.

Product Mastery: From Good To Great Product Ownership by Geoff Watts
My rating: 4 of 5 stars

• A good Product Owner delays when they can.  A great Product Owner decides when they must.
• A good Product Owner trusts themselves to make the tough calls.  A great Product Owner knows when to call for help.
• A good Product Owner knows what is needed.  A great Product Owner knows what can wait.
• A good Product Owner takes calculated gambles.  A great Product Owner also knows when to walk away.
• A good Product Owner trusts their instinct.  A great Product Owner finds data to test their ideas.
• A good Product Owner knows enough to make a decision.  A great Product Owner knows enough to ask questions.
• A good Product Owner is reliable and dependable.  A great Product Owner knows  flexibility is essential to strength.
• A good Product Owner defines a cohesive vision for the product.  A great Product Owner empirically evolves the product.
• A good Product Owner leads from the front.  A great Product Owner leads from within.
• A good Product Owner writes good stories.  A great Product Owner tells great stories.
• A good Product Owner represents many different parties.  A great Product Owner knows they can’t please everyone.
• A good Product Owner avoids bad mistakes.  A great Product Owner makes good mistakes quickly.
• A good Product Owner knows how to use agile tools and artifacts.  A great Product Owner are driven to develop their subtle, softer skills.

Extreme Programming Explained: Embrace Change by Kent Beck, Cynthia Andres
My rating: 4 of 5 stars

Values

• Communication – important for creating a sense of team and effective cooperation
• Simplicity – eliminating unneeded work the simpler things are the easier communication is
• Feedback – this is a vial form of communication contributing to simplicity
• Courage – to speak the truth, pleasant or unpleasant, fosters communication and trust; to discard failed solutions encourages simplicity; and seek real, concrete answers in feedback.
• Respect – the contributions of each person on the team needs to be respected, I am important and so are you
• Team values – this is adding extra values which the team feel are important and by having them explicit means they are important e.g. safety, security, predictability, quality-of-life etc

Principles

• Humanity
  • Basic safety – freedom from hunger, physical harm, threats, fear of job loss.
  • Accomplishment – to be able to contribute
  • Belonging – to identify with a group from which they receive validation and accountability
  • Growth – to develop skills and perspectives
  • Intimacy – to understand and be understood deeply by others
• Economics – delivering bussiness value, meeting business goals and serves bussiness needs.  For software development the economics are that the sooner there is delivery the sooner there is value.
• Mutual Benefit – help me now, in the future and the customer
  • Automated tests – help design and implement better solutions today, in the future this benefits people maintaining the system
  • Refactor – removes additional complexity giving me satisfaction today and fewer defects, in the future it makes the code easier to understand
  • Names – makes code coherent and explicit which speeds up my development, in the future the cleaner code is better for new programmers.
• Self-Similarity – try to keep the same structure even at different scales, such as the processes you do in a week you might do at a larger scale every month (e.g planning, demo etc)
• Improvement – things are never perfect, starting with something and evolving it in the right direction to provide a solution which is good enough
• Diversity – this brings creativity and different perspectives to the problem
• Reflection – exposing mistakes and learning from them after the action
• Flow – aiming to produce value quickly with new features flowing through the team at the highest possible rate
• Opportunity – taking each problem and using it as an opportunity to learn
• Redundancy – this might be needed to ensure the product is correct, it should not just be removed immediately but work should be done to improve the process until it is not needed and then removed
• Failure – this could be the cheapest way to learn given the option for weeks or research compared to a similar time trying things the latter might result in multiple failures but result in a good solution quicker
• Quality – quality can not be cut to save time or cost, for software quality needs to be improved to identify defects early, enable new joiners to get up to speed etc.  If time or cost need to be cut then feature scope is the only leaver that can be pulled.
• Baby Steps – and grow in the right direction rather than a big bang approach
• Accepted Responsibility – a person should be responsible for the whole feature from estimate it, designing it, implementing it and testing it.

Primary Practices

• Sit Together – to boost communication
• Whole Team – all the skills needed to complete the project, everyone in it together
• Informative Workspace – such as whiteboards, stories on the wall etc
• Energised Work – actually getting quality work done, not just clock time – if you are unable to sustain working more then stop working rather than burning yourself out for the next few days
• Pair Programming – keep each other on task, brainstorm refinements, clarify ideas, support each other, hold each other accountable for the team’s practices
• Stories – plan units of customer-visible work and estimate them as soon as they are written, the estimate gives more visibility for prioritisation
• Weekly Cycle – plan the work a week at a time, review progress, select stories and break them down into tasks
• Quarterly Cycle – reflect on the team, the project, its progress and align with the larger goals.
• Slack – it is important to meet your commitments to build trust with stakeholders so including minor tasks which can be dropped if needed could be beneficial
• Ten-Minute Build – produce the shortest feedback time possible and certainly less than ten minutes aka the time to get a coffee
• Continuous Integration – ideally in a synchronous way get the whole system built, integrated and deployed (even if only into a test environment)
• Test-First Programming – write failing tests first so that you can prevent scope creep, improve the loose coupling and high cohesion of the code, improves team trust and produces a rhythm focused on delivery
• Incremental Design – regularly reviewing the design and then allowing for refactoring so that the design emerges as more is learnt about the way things need to work.

Corollary Practices

• Real Customer Involvement – this is to increase the value produced by the system
• Incremental Deployment – when replacing something gradually take it over small piece by small piece as early in the project as possible
• Team Continuity – keep effective teams together and move them to other projects
• Shrink Teams – try to get the team as small as possible to deliver the work required
• Root-Cause Analysis – the aim is that when an issue occurs that it is not just fixed but a similar type of issue can not occur again
• Sharing Code – the team should own the code so anyone on the team can make changes to it
• Code and Tests – should be the only permanent artifacts other documentation should be generated from them
• Single Code Base – there should only be one code stream and short lived branches
• Daily Deployments – getting the code to generate value as soon as possible but this needs the support of sufficient tests etc which take time to build up
• Negotiated Scope Contract – have shorter contracts with fixed time, cost and quality but negotiable on scope
• Pay-Per-Use – this is a great feedback for which features are actually used, should be developed further or removed

Who Are You, Really?: The Surprising Puzzle of Personality by Brian Little
My rating: 4 of 5 stars

Biogenic : This is the biological you, and can be split into The Five Personality Traits

1. Open to Experiences (vs. Closed) – being attracted to new ventures and exploring new things.  Such people succeed in coming up with novel solutions.
2. Conscientious (vs. Casual) – being laser focused, this helps achieve more academic pursuits and conventional problem solving.
3. Extraverted (vs. Introverted) – being attracted to potential rewards in their environment choosing quantity of experiences (as opposed to introverts who look for quality).
4. Agreeable (vs. Disagreeable) – smooth other conflict and build alliances.  They are highly trusting and might be seen as being naive.  They have high levels of empathy.  Disagreeable people are cynical and distrusting of others.
5. Neurotic (vs. Stable) – being attuned to punishment and which leads to anxiety, depression and vulnerability.  Such people are the canaries in the coal mine.

Sociogenic : This is the environment in which you are and are your historical experiences, this is how you engage with the world.

Idiogenic : All people are essentially scientists creating experiments and testing hypothesises about the world and evaluating their results.  This is the personal way that we view the world that is constantly in flux.

The Biogenic, Sociogenic and Idiogenic aka nature, nurture and the way you view the world work together and evolve as you experience every day.

The book goes on to detail how can you build and develop the traits that you might want with the key to these being the projects which you undertake. Some of these projects will be you working by yourself (e.g. keeping the lawn tidy) or it could be projects which you do with one or more other people (e.g. looking after a pet).

The Five Dysfunctions of a Team: A Leadership Fable by Patrick Lencioni
My rating: 4 of 5 stars
The book presents a story which dives into a team and the problems with them working together towards a common goal.

Dysfunction 1 : Absence of Trust
When you have a group of people who feel that they have to be great to be in their role it is important that people can be open and honest, without this people hide mistakes and work for their own personal aims.

As a leader it is important to lead by example for people to be open and to share without fear of negative criticism or reprisal.

Dysfunction 2: Fear of Conflict
Where there is no trust there is no ability to have tough discussions and for people to actively come to the best decision for the organisation.

If you present an idea which you know is bad and no one challenges it then you know that people are not engaged or they fear an active discussion on topics.

Dysfunction 3: Lack of Commitment
Once there has been an active discussion and an outcome agreed then people need to commit to it and run with it. If this is not the case then people go against the decision intentionally and this can cause conflict elsewhere in the organisation as a result e.g. between teams from different departments.

There needs to be closure on issues. To focus the mind deadlines can be set and a formal review scheduled to reevaluate the decision.

Dysfunction 4: Avoidance of Team Accountability
If there is a lack of commitment then there is a lack of holding people to the decision. This can result in poor performance and the leader becoming the sole source of discipline since no other people will hold people against the agreed decision. When accountability is in place then things are clear. can be reviewed and helps teams remain healthy.

Dysfunction 5: Inattention to Team Objectives
Care needs to be taken that it is not every person for themselves e.g. personal recognition etc. The team needs collective goals and team members need to be constantly striving for the achievement of the team. When the team is working well then team members will be glad to feel part of it and will be focused on delivering value.