Management 3.0: Leading Agile Developers, Developing Agile Leaders by Jurgen Appelo
My rating: 4 of 5 stars
The book is targeted at Agile management of software development teams but the ideas within it are not specific to them. It is written in a mixture of anecdotes, theories from scientific papers and practical approaches you can take. The target is to present a model which has 6 “views”; Energise people, Empower teams, Align constraints, Develop competence, Grow structure & Improve everything. Here are the things which I noted from each of these views.
Energise people – Innovation is the key to survival for a company, and innovation is the combination of information, knowledge, creativity, motivation, diversity & personality. Here people are key to the system, and people are complex. To energise people they need a creative environment which is safe (where people have freedom and can take risks without consequences), has games (allow people to practice their creative talents), is variation (routine kills creativity), visibility (show off creativity breeds more creativity), on the edge (challenges should be a little scary). Traditional management used extrinsic motivation, e.g. target driven bonuses, however these reduce creativity. Instead creativity is best when it comes from intrinsic motivation. Intrinsic motivations are to feel competent, to be accepted, curiosity, honor, purpose, autonomy, order, influence, social contact/relatedness & status from challenging work, achievement, personal growth, recognition & responsibility. Additionally “hygiene factors” such as job security, salary, working conditions, etc – these don’t motivate people but there absence does demotivate people.
Empower teams – No one person can comprehend an entire project, this is why at planning and daily stand-ups the entire team need to be present. As such the team is the best place to make decisions, not some manager since the team has the most information and understands it the best. As such empowering the team produces both the best results but also allows a company to grow. Telling people what to do just builds up motivational debt, but asking empowers people for their input and sometimes results in a better idea as well as the work actually getting done. Additionally a manager should not step in to make a decision but might help the team make their own decision – the worst thing a manager can do is to think “If I want a job doing properly do it myself” as this just obliterates the empowerment of the team. People or teams can be empowered for different tasks at different levels. The proposed levels go from management take control through to the team take control, these being Tell, Sell, Consult, Agree, Advise, Inquire, Delegate. For different people and different tasks they might have different levels (e.g. spending < £500 might be an inquire but for people in their first 3 months this might be at the consult level). There are different levels of maturity for empowered tasks from the low maturity level with little risk for the company, this could be things such as coding guidelines or internal workshops; through to moderate maturity which would be things such as self-organising the team, getting people involved in interviewing others for the team or potentially developing a new business model; up to a high maturity level where people determine their own salaries, choose their own projects or job title. Sometimes you would not empower an individual to do something but you might empower the team, so collectively they are responsible. Empowerment is built on trust & respect; between a manager and the team, team and a manager, within the team and within yourself – it needs to be built. One way to build trust is to be open and visible, if you tell people as much as possible (even if you think it might not be relevant) then they will do the same and build trust further.
Align constraints – Manage the system, not the people. So we now have a group of creative and empowered people and teams. There are always boundaries, and these boundaries should be tweaked and refined to get the desired outcomes from the team. The role of a leader is to develop the self organising system, protect the system & direct the system. Directing the team is to give it purpose. People have three types of purpose intrinsic, extrinsic and autonomous. The intrinsic purpose of a software team is to create software – without this the team no longer exists. The autonomous purpose for the same team might be to develop “clean code”. The extrinsic purpose is imposed by a leader, and this can be for the individual team or company since it is only the leader who can is responsible for the whole system. This extrinsic purpose(s) is the long term vision, for the product the team and/or company as well as the short term mission. These statements should be understandable, concise, memorable, ambitious, actionable, useful, plain, tangible, excitable, and inspiring. Again, a purpose linked to a reward will likely restrict people and reduce creativity.
Develop competence – Growing competencies is key to systems improving. There are multiple ways to grow competencies – self directed, being coached (this does not need to be by a manager), certification (the certificate only attests to your ability at a point in time but the process of certification will give you learning targets), tools (such as check lists), peer review and feedback, supervisors (to check quality), management (to check compliance). Care has to be taken else you get a “what you measure is what you get” approach, and if this is of a sub-system the optimisation of which might be bad for the business as a whole. The dimensions which contribute towards the project are functionality, quality, tools, people, time, process & value so these would give a more holistic view of progress but should be measures at the highest level which they make sense. Competency is a mixture of skill and discipline. Skill is missed out of the agile manifesto, and following which craftsmanship or mastery has been an important topic. Discipline is things such as task board up to date, meetings start on time, code coverage, etc. Skill and discipline are deliverables, where as knowledge or experience is theoretical – people should be rated on their deliverables not on the theoretical. Where possible use relative ratings – how much better are things than the last time, not just how good are things. As with all of agile, people should get feedback quickly. The people who work closely together should provide feedback – not managers who do not work with people continually.
Grow structure – With people being the core of the system, communication is the key to success. Communication is tricky as different people interpret the same thing differently – it is a combination of information, relationship and feedback. Since relationships are key to this whenever a team is forced together the communication will start poorly, as such keeping a team together (even if the project change) is beneficial. Where feedback between team members is poor the communication suffers and the result is unpredictable. The structure of communication should impact the structure of the teams – where communication within the team should be the primary communication. Communication from outside of the team will always be needed but this should be at a slower pace. This has impact on the decision between forming a functional or cross-functional team. Where communication is mostly within a function then a functional team is more optimal but where the communication with with others then a cross-functional team is more optimal. This might also change over time, and it might be worth seconding someone from a functional team to another team to ease communication. Since each team optimises for its own process it is possible that, for example, a functional team might optimise its process so the function is very efficient but this might not be efficient for its users – as such each team should be a value center with other teams as valued customers. For inter-team communication there are two approaches – where all communication goes via management or where teams talk directly. It is mostly the case where teams talking directly is best because of bottlenecks which going via management introduce. The ideal team is one of 3-7 people where members compliment each other in such a way that they get the job done quickly – this is only possible by having a diverse team. It has also been shown that the product developed is a reflection of communication structure of organisations – e.g. have 2 teams working on a compiler and you will get a two parse compiler. So the team needs to be adapted to the product which is being developed. To keep people interested their role should change regularly, so it is best to keep job titles broad to allow flexibility. These broad titles help informal leadership – everyone in the team should take on whatever is needed for the team to function best be it leadership or development. To facilitate this generalised specialists (T people) aid in the team members being able to take on any task required. Build on the communication by connecting people to build relationships and improve communication.
Improve everything – A system is a success until it is not, the best we can do is delay failure – a system has to change to be able to keep up and delay its end. For a system to be changed it has to take into account the current environment the system is in – simply repeating someone else approach to solving a problem will not yield the same results for you as it did for them. Systems can adapted but they also need to explore new ideas as well as anticipate potential shifts – these should be continually being reevaluated to maintain change and prevent failure. The model presented identifies the following steps to improve the system; identify the problem, define the goal of the change, define success metric, identify the improvement, implement the improvement, collect the metric, analyse the results, distill learnings and loop again. This can reach the best peak for this mountain but it might not be the peak of the maintain range – taking radical jumps from one mountain to the next might not land you in the idea place but you can improve from there to get to the top. People naturally don’t like change and sometimes the environment needs to be changed to encourage people to try things. To prevent stagnation it is important for teams to try out new approaches to see if they improve things for them – sometimes even by imposing a little pain for stagnation, this then gets teams to want to improve themselves to reach the next peak. There are three strategies for optimal performance. Changes and improvements to existing practices. When starting new projects try out taking the best solutions others teams are using and see if the combination results in a better result. Increase inter-team communication to spread ideas which teams might then pick up on and use. Some tools for doing this are using retrospectives, improvement backlogs, use catalysts to encourage change, improvement community.