productivity (2)


Top 8 Books for Technical Leaders

We’re always in the search to develop and maintain high performing teams, reduce risk, improve quality and increase speed to market. The below books have helped in the journey to become a better information technology / software professional and technical leader. The books discuss productivity, leading / managing knowledge workers in creative work, growing technical leadership skills, agile leadership, lean thinking, change & financial management.

Peopleware: Productive Projects and Teams – Tom DeMarco & Tim Lister

Peopleware - Productive Projects and Teams 

Peopleware is a great book for leaders of knowledge workers and creative environments. Through their experience and research, DeMarco and Lister provide examples on how to enable productive teams and describes common productivity killers. Peopleware discusses:

  • How to keep staff happy, retention high, burnout low.
  • How to setup your team environment for maximum productivity.
  • How to create a learning culture.
  • Setting up the office and work environment to maximize flow time and team work.
  • Leadership, management, goal alignment and networking.
  • Factors that will lead to teamicide – i.e. breaking teams.
  • Creating a culture of transparency and trust.
  • Empowering people to define methods most appropriate for their work, rather than strict adherence to prescribed methodologies.
  • Tips for effectively and pragmatically managing risk and change management.
  • How to run effective meetings, avoid ceremonies and ensure working meetings have outcomes and are efficient and effective.
  • How to grow community and culture, make work fun, enable innovation, keep motivation high and teams happy.

You can find a detailed Peopleware: Productive Project and Teams summary here.

You can review and purchase Peopleware: Productive Projects and Teams on Amazon.com.au.

 


The Manager’s Path: A Guide for Tech Leaders Navigating Growth & Change – Camille Fournier

The Managers Path

<<< Summary In Progress >>>

<<< Summary In Progress >>>

<<<Summary In Progress >>>

You can review and purchase The Managers Path: A Guide for Tech Leaders Navigating Growth and Change on Amazon.com.au.


Leading Geeks – How to Manage and Lead the People Who Deliver Technology – Paul Glen

Leading Geeks

<<< Summary In Progress >>>

<<< Summary In Progress >>>

<<< Summary In Progress >>>

 

You can review and purchase Leading Geeks – How to Manage and Lead the People Who Deliver Technology on Amazon.com.au.


Management 3.0 Leading Agile Developers, Developing Agile Leaders – Jurgen Appelo

Management 3.0

Management 3.0 is a book designed for the agile manager / leader and is presented via a synthesis of theory, science, nature and practical real world experience of Jurgen Appelo. Through understanding the differences between ordered systems (i.e. predicable) and complex systems (i.e. unpredictable), better structures, processes, methods and approaches can be used to manage, lead & motivate teams, reduce risk and increase the chance of success. Management 3.0 discusses:

  • The differences between ordered-systems and complex-systems and selecting the right method for your environment and challenge
  • Improving chances of success by embracing a constant flow of failure, learning & evolving cycles
  • Reviews existing agile methods such as RAD, Scrum, XP,  Lean, CMMI, PMBOK, Prince2, RUP and some of their limitations including the CHAOS report on project failure.
  • Discusses the role of complexity – the state between order & chaos where innovation & creativity thrives.
  • Highlights the importance of social networks within an organisation and osmotic communication (overhearing conversations & information). Connectivity of an individual & team is one of the best predictors of performance.
  • How to manage a creative environment including core tenants of safety, play, work variation, creative visibility,  and an environment which challenges the comfort zone.
  • How to create an environment of motivation for knowledge workers
  • Enabling self organising teams which are best suited for complex/dynamic environments, delegating and enabling decisions to be made at the right level (where the knowledge resides). Through aligning constraints, setting boundaries & protecting the environment, managers can define direction and shared goals of autonomous teams.
  • How to develop competence within individuals & teams and capture key project performance metrics for feedback loops
  • Communication and feedback ideas
  • Organisational structure, team size & makeup and generalising specialist / t-shaped individuals
  •  Embracing continuous change in search for system optimisation through adaption, exploration & anticipation.
  • Continuous improvement through plan – do – check – act cycle and similar models. Often as the team tries different methods to improve productivity it will take one step back and two steps forward.

You can find a detailed Management 3.0 summary here.

You can review and purchase Management 3.0 Leading Agile Developers, Developing Agile Leaders on Amazon.com.au.


The Lean Startup: How Constant Innovation Creates Radically Successful Businesses – Eric Ries

The Lean Startup

<<< Summary In Progress >>>

<<< Summary In Progress >>>

<<< Summary In Progress >>>

You can review and purchase The Lean Startup: How Constant Innovation Creates Radically Successful Businesses on Amazon.com.au.


Leading Change – John P. Kotter

Leading Change

<<< Summary In Progress >>>

<<< Summary In Progress >>>

<<< Summary In Progress >>>

You can review and purchase Leading Change on Amazon.com.au.


The Mythical Man-Month – Fred Brooks

The Mythical Man Month

<<< Summary In Progress >>>

<<< Summary In Progress >>>

<<< Summary In Progress >>>

You can review and purchase The Mythical Man-Month on Amazon.com.au.


Beyond Budgeting – Jeremy Hope

Beyond Budgeting

<<< Summary In Progress >>>

<<< Summary In Progress >>>

<<< Summary In Progress >>>

You can review and purchase Beyond Budgeting on Amazon.com.au.


 

I hope you’ve found the above books useful. Have I missed any books you think software / information technology professional and leaders should read?
Would love to hear your thoughts and feedback below…

 

* As an Amazon Associate I earn from qualifying purchases…



Software Delivery – Optimise for predictability or productivity?

This blog post was inspired by a recent work rant:

/Rant
It may be worth having a conversation around what a delivery plan is (and isn’t). Once the delivery-plan has been communicated, it will likely be out of date as we’re working in a unpredictable complex system (not an ordered predictable system). I hope we consider the delivery plan as an alignment tool which will constantly change as we learn, react & adapt (not as a stick for fixed dates/deliverables). If we need a guaranteed delivery plan and dates, then perhaps we need to use a different method of planning & delivery (perhaps Waterfall, with lots of buffer, contingency & lead times).
/End Rant

Often when delivering software we have two competing interests; being predictable in delivery (i.e. hitting targets / deadlines) vs. maximising productivity (delivering valuable output). For this article we’ll define predictability as ‘delivering software features on time, to budget and to an acceptable level of quality’ and define productivity as ‘maximising value-add features, maximising learning and minimising waste’. From experience these two concepts can be opposing and depending on the type of work at hand can land your initiative in a different place on the scale below in figure 1.

Figure 1. Predictability vs. Productivity in software delivery

Often the more predictable a team needs to be, the less actual value adding work (or validated learning) it will produce, and will often partake in poor processes and generate low-to-no value-add artefacts. My hypothesis is if two independent teams were to solve the same problem, within the same environment, with the same constraints and technical stacks etc (i.e. identical space), the team choosing to be more predictable would be between 10% to 40% less productive. The more predicable team would spend more time on upfront analysis, design, architecture, upfront spikes on unknown areas, more time breaking down work into detailed tasks, estimating & planning. They would then likely deliver in larger batches and have longer release cycles, but the team would hit delivery targets, budgets and be predictable – happy days (or so we think)!

I suspect the more productive team would be less predictable, most likely starting by completing a high level delivery plan upfront (i.e. a mud map), identify dependencies with long lead times (early on), look to attack hidden complexities through working software and be constantly evolving their delivery plans, budgets and forecasts. The more productive team would spend less time producing upfront artefacts such as business requirement documents (BRDs), solution architecture documents (SADs), detailed work breakdown structures, detailed delivery plans & budgets, but would plan to deliver the smallest vertical increment of working software, and continue to iterate and build based on rapid feedback from the environment. Valuable working software would provide the best feedback, documentation and risk reduction and any artefacts required such as architecture diagrams, user documentation etc would be produced just in time. The team would frequently evolve the delivery plan based on historic velocity with just enough detail to communicate dependencies, ensure alignment, communicate actual & forecasted dollar burn-rate and set/reset delivery expectations as value is realised and the ecosystem changes.

Methods of Software Delivery

The Waterfall method is an extreme example of large up-front effort with little to no early value and long lead times, Scrum introduced time-boxed, value adding increments and lands in the middle of Predictability vs. Productivity scale and Lean / Kanban method is an example of a fluid, flow based delivery method as seen in figure 2.

Figure 2. Schedule based vs Flow based software delivery methods

Extreme caution should be used when moving too much towards big up front delivery planning (such as the Waterfall method) where there is a need to try to understand and solve all problems at the start of a project, as highlighted in the 2015 Standish Chaos report smaller projects have a much higher chance of success, and in all project sizes Agile methods delivered success 39% of the time (challenged 52%, failed 9%), compared to Waterfall which delivered success 11% of the time (challenged 60%, failed 29%) . Ignoring Waterfall, the predictable team above may choose the Scrum methodology and assuming a 7 person delivery team, two week sprint and a 40 hour work week we see the following time spent on Scrum rituals per team member:

  • 15m daily standup
  • 4hr backlog grooming, story breakdown & estimation
  • 1hr sprint planning
  • 1hr showcase
  • 1hr retrospective

Total of: 9.5 hours per sprint or 12% of sprint time per team member
Total of : 66.5 hours of team time per sprint

Spending time breaking down the backlog into smaller backlog items, discussing visual and technical designs, teasing out complexity & dependencies, poker-planning and thinking about execution are very valuable activities which lead to higher confidence levels and better predictability. With a little bit more work relatively-estimating the delivery backlog, some historic velocity and some contingency built in, the predictable team can now forecast delivery in the 2-3 month window with a level of confidence.

The productive team may feel spending 12% of their time on rituals as heavy and would look to spend minimal time on overheads. As work comes in and is prioritised, the team would break work down into small (similar sized) items and tackle the next most important issue, continuously deploying value and seeking feedback. They would likely spend less time breaking down work and planning, and more time doing and assessing the results; more of a continual flow based method. Often the flow-based delivery teams are good at forecasting days-to-a-week of work, but not great at forecasting weeks-to-months of work, and are often less predictable than a typical Scrum team, but arguable more productive.

The culture of the productive team is likely to be more focused on being brave, attacking problems, compelled to action, taking calculated risks, rewarding failure & learning cycles, supporting each other and focused on getting things done whilst the predictable team will likely play it more safe, be more risk adverse, compelled to analysis and more focused on delivering to expectations rather than striving for stretch goals. The culture of the team and the broader ecosystem the team operates within is a major influencer on the teams ethos; to be predictable or to be productive.

The above example indicates both extremes of the predictability vs. productivity, there are many different considerations when choosing where to land on the scale and my hypothesis above assumes a certain context & problem; however many things needs to be considered such as:

The type of work at hand – is it well known, repeatable, complex or unknown?

Following the Cynefix framework, where does your work or ecosystem fit?

Are you operating in business as usual mode (BAU) of an established well understood application?

Are you building a new application from scratch and don’t fully understand the customer problem or domain?

Are you working on a pure innovation front, or with bleeding edge technology?

The team & individuals

How experienced are the team within the current ecosystem and technology?

How much career & technology experience does each team member have; graduate, junior, mid or senior?

How much cumulative experience does the team have (a team full of graduates, mid-tier developers or senior specialists or a good mix of all)?

Do you have an established, battle hardened team, or a newly forming team (going through Tuckman’s forming, storming, norming performing phases)?

The size of the feature, application or system

Are you building a small increment to an existing application or are you building an entire business support system?

Are you modifying a standalone feature, or a full customer or business workflow?

Are you building for a local market, or one that spans across language, time and culture?

The surrounding ecosystem of the feature, application or system

Are you working in a startup, trying to find customers, or in an established and highly regulated industry such as banking or insurance?

Do you have millions of customers on a legacy platform?

Do you have full freedom of ways of working to define your own processes, or are you bound to an existing corporate environment?

How much lead time does the business need for change management and go to market activities?

How many up-stream or down-stream dependencies do you have, and what are their lead times?

How easy is it to make a change in your ecosystem, how much effort is required to handle changes to an upfront plan?

The initiative, project or program of work in play

Are you working on a single, isolated system with limited dependencies or part of a complex, interconnected large ecosystem?

Are other teams and systems dependent on the work you’re producing to deliver on a program of work?

How many people are involved in the initiative, project or program of work – one team of 5 people, 15 teams and 150 people or hundreds of teams and thousands of people?

The lifespan of the feature, application or system

Following the lifespan of an feature, application or system by Kent Beck – Explore, Expand, Extract & Extinct

Is this feature a learning and innovative piece of work (i.e Explore) and needing extreme productivity and validated learning cycles?

Is this application or system scaling up and expanding (i.e Expand) and needing to overcome technical, system, process & people limitations?

Is this feature being delivered to an existing large customer base (i.e. Extract) where predictability and profitability are key drivers?

Is this feature, application or system being delivered at end of life (i.e. Extinct), hard to coordinate & expensive to change?

All problems are inherently different

Experience has taught me there’s often more than one way to solve a problem, each having a unique context & ecosystem; one size never fits all. Like most things in life, to move forward some trade-offs are likely required and most teams will find themselves somewhere in the middle of the scale, doing enough work to be predictable, without suffering significant productivity loses.

Where do you fit on the scale of predictability vs productivity?
What are your unique needs?
How fast do you want to go?
How predictable do you want to be?