These are slides from the Agile Product Ownership Meetup, where we discussed the Discovery Phase of a product.
Medical students are taught early to carefully consider the possible impact of their actions, this often translates to a bias towards inaction. A paradox when many of us consider them as being ‘fixers’.
“Given an existing problem, it may be better not to do something, or even to do nothing, than to risk causing more harm than good.”
This reminds physicians to consider the possible harm that any intervention might do.
The rationale behind this is that the human body is a marvelous piece of engineering and has an astonishing capacity for self-healing. A staggeringly high proportion of injuries, ailments and afflictions will simply fix themselves if we do nothing, and almost all remedies come with some risk of side-effects or unknown complications.
Which is why a doctor will often advise rest of some description, or suggest that you monitor and come back in a week. Or they will prescribe a low dose of a low risk remedy to buy time for you to heal, this gives you confidence they have acted and the time for you to heal.
Physicians are therefore faced with the certain knowledge that doing nothing will in most cases result in the problem resolving itself and the certain knowledge that any remedy bears some risk of harm. And yet their chosen profession is to help, they chose the profession because they are motivated to ‘act’ to help people. Helping by inaction is excruciatingly difficult for people with a desire or bias to act, their desire to act very often overrides their desire to help. This is compounded by patients that expect action even when no action would be better.
For a physician the real skill is the ability to evaluate which situations from the multitude presented truly require intervention and then diagnosing the correct intervention.
A similar phenomenon occurs in management. As an organisation typically we structure teams to be largely autonomous (or have delegated authority), we hire individuals who are capable of getting the job done without regular interference from management.
The rationale behind this is that a
human body self-organizing team is a marvelous piece of engineering and has an astonishing capacity for self- healing improvement. A staggeringly high proportion of injuries, ailments and afflictions problems the team will simply fix themselves if we do nothing, and almost all remedies interventions come with some risk of side-effects or unknown complications.
So our starting position should be non-interference, if you hired the right people and they are structured effectively they should be able to resolve most situations themselves. Intervention should be an abnormal action not your go to response.
The problem is that we are humans: managers generally become managers because they have a bias for action and because they care (either about the people or the work or both). They also suffer the most horrible of curses, they are curious.
When an employee comes to you with a problem or you observe something that sparks an interest we as curious fixers have an overwhelming urge to jump in. We want the details, we want to help, whilst the person is describing the problem we are evaluating and preparing a response, an intervention of some kind. We are so interested in a situation we forget to ask whether it is in the interest of the individual or team for us to be involved.
We forget that we lack the same level of information, or context or situational awareness. We substitute this for our experience and opinion. Don’t get me wrong we hire managers for their experience and opinion, but like any tool it must be used judiciously.
I see this happen over and over, especially in a matrix organisation, a variety of managers become aware of a problem, often trivial and want to ‘help’ but the reality is that the responsible party – either the team or the responsible leader is already capable of resolving the issue and is already acting, but now they must also to respond to your advice, they must keep you informed and as the situation escalates the number of people to inform and respond to grow and becomes a problem of it’s own. The lack of context may often result in bad advice that the team feels compelled to follow because of the assumed authority of the manager giving the advice.
This chap is Ethelred the Unready, king of the English (Not England), the poor man has gone through history with this title. But in this context Unready is somewhat unfair pseudonym for him. The Anglo-Saxon noun unræd means "bad advice" or possibly "evil-council" it is not a reflection of him being unprepared. He was badly advised, he came to the throne at 12 and suffered from interference from his political advisers. The bad advice he received has led to a reputation for over 1000 years.
The true gift of a leader/manager is the ability to listen and evaluate when it is beneficial to act and when it is better to let the situation resolve itself in an acceptable fashion. And that there is the stumbling block suffered by many inexperienced managers, they see a situation and possibly even a potential solution and they ‘know’ they could handle the situation better. They would handle it differently and want to step in. This inability to delegate and to trust others is the hardest part of management and the part where most fail.
Just like physicians, the true skill of a manger is knowing when to intervene and the strength of character to sit on the sidelines and watch when your intervention would be unnecessary.
Agile and self organized/self managed teams
So what does this have to do with Agile Coaching? First you could very easily replace the word Manager with Coach in the last section and heed that advice. Teams in most situations could and should be able to resolve situations themselves. However, I am going to take a slightly controversial stance on this and suggest that in Agile communities we have taken that advice a little too far.
In many ways Agile has created a community that shuns medicine. We have heard that 95% of health issues resolve themselves and we have interpreted this as a belief that physicians are therefore completely unnecessary. Not only unnecessary but should be chased from the land with pitch forks. In essence we have become zealously anti-management.
I have been in a number of agile workshops where we assess the role of a manager and conclude that most of the responsibilities of a manager can and possibly should be performed by the team. #NoManagers This is a really great exercise and is very empowering for the team and will generally give them the confidence to step up and take ownership. The downside is that whilst in theory the responsibilities of managers can be delegated to the team it is not always possible to delegate big picture awareness, experience and capability. These tend to get dropped on the floor as they are only valuable when things go wrong.
Even Scrum Masters seem to be being shunned now in favour of more remote Agile Coaches or in many cases the belief that because SOME teams are capable of autonomy and have the necessary experience and understanding of Agile that they can function without support, that this somehow translates to ALL teams should function without ANY support. Companies will abandon Coaches, Scrum Masters or leaders of any kind and expect even relatively junior teams to make effective decisions.
In those 5% of cases where the team hits a situation they cannot handle they are by definition lacking the knowledge or experience or support needed to resolve it. We have moved from a situation of too much unnecessary intervention to a totally hands-off situation where teams are left to flounder, with no one willing or able to intervene. In some cases those that do step-in to assist are challenged as being anti-agile for undermining the team’s independence.
One of the key elements of a management or support role is the natural distance from the team, the ability to distance oneself and see the bigger picture, something that a team member can rarely do.
As an example I recently worked with a very capable and experienced team, they were working hard and getting the job done. The problem was they were not delivering value by the customer’s standards (not overtly articulated by the customer). Through a variety of small and seemingly insignificant events the situation had evolved. Early on there were some obstacles relating to a production environment that at the time and with the information available the team chose to postpone, choosing to remain productive(busy), later more obstacles arose and again the team didn’t want to slow down so chose a path that enabled greater utilization(rather than value delivery). The result was a very happy and busy team, they were getting a lot of work done. The team was unaware there was a problem until the customer grew frustrated at the perceived lack of value being delivered. The team would have eventually resolved this issue but the cost to the customer would have been considerable.
The Quest for Balance
This is a typical tale of a team optimizing for itself, there needs to be someone with an eye on the bigger picture and an emphasis on the entire system. It is hard to assume that every team has this, when it is a rare skill. Of all the responsibilities of a traditional manager this is the hardest for a team to replicate. The ability to see the system is the primary reason we hire managers/coaches/delivery leads/product owners/project managers, in my opinion the key skill to look for in those roles is the ability to visualise the big picture and to know when to act on this knowledge.
This is not a claim that teams cannot self organize or that managers are necessary in all cases. This is a request for balance and awareness of the bigger picture. Previously I talked about the greatest skill of a physician or a manager being the ability to discern when to act and having the strength of character to do nothing when it is unnecessary. The flip-side is true for teams, you cannot handle every situation without support, the ability to know your limitations and when to ask for help is a significant skill and highly underrated. But equally the willingness to listen to advice from those with a better view of the entire system is also crucial.
Yes the team might be able to resolve a situation eventually, but at what cost and who is footing the bill? The cost here is one of those ‘Big Picture’ areas that is often underrated by those who are abstracted from that. Self-organization is very powerful, but understanding when a problem is one that should be left for a team to resolve and when someone with a better understanding of the big picture should step in, is one of the hardest questions to answer.
Generally I like to believe inaction is best, trust that we have hired the best people and that we have set them up for success. But also being aware that self-organization is not a silver bullet and it comes with a cost that may not be appropriate to pay in all situations. Learning is costly and we do not learn from all failures. Having people prepared and skilled enough to act is crucial, knowing when to act comes with experience and not acting requires a huge amount of self-discipline.
By nature I am insatiably curious, I have an opinion on everything and I have a strong bias for action. Of all things not intervening is one of my personal challenges. This post is as much a letter to myself as anything else. It is a reminder to trust and to observe rather than prematurely act.
I am a very lucky person, I have my dream job. I work for a huge Solutions Provider as a member of their software consultancy group. The consultancy group has multiple physical offices in the St Louis area, and offices in Denver, New York and London. we have now decided to expand into the virtual space and launch a Virtual Office dedicated to collaborative software delivery. My role is to create this office, define the tools, practices, processes and then to build the team: hiring and supporting the staff and managing and growing the office. It is an incredible opportunity and it is not overstating to say that I wake up excited (and daunted) about it every day.
I wrote a while ago about the new role and about the challenge of remaining true to an Agile mindset. My goal was not to lose our agility as we became separated by technology and tools. https://yorkesoftware.com/2018/10/11/a-3-pipe-problem/
It was a surprise to discover that with the right attitudes and the right tools we are actually able to enhance our agility. We are actually more agile in a virtual space than we were in the physical space.
What is Agility?
To many this will sound like an exaggeration, but as a consultancy firm we sometimes operate in a less than optimal situation, there are challenges when you are working in a slightly abstracted situation. To be truly ‘Agile’ the goal is generally to get the team and business working together and to shorten feedback loops, deliver software quickly. But the reality is that ‘the business’ is a client. They are removed often physically which is bad enough but often they have other priorities and so are removed in an availability sense too. So whilst our teams are together, it is rare that we get the business (SMEs and Product Owners) on site and embedded with our team, when we can this is the ideal situation.
More often we get together for project kick-offs and planning and regularly for demos and retros. But stand-ups are often conducted via web conferencing tools, as are story writing and weekly planning/prioritization meetings. This puts a barrier between the team and the business, we do our best to break down these barriers but the reality is that they exist.
I call out being a consultancy as it is an extreme case but it also happens in most businesses, the PO and SMEs generally have another job and other priorities and the development team gets a slice of time and attention, so this is not unique to consultancy.
Brave New World
So understandably I went into this new venture with the expectation of doing my best to mitigate an already existing problem and to strive to not let it be worse in a Virtual Team.
In the early stages we found a tool called Sococo which is very hard to describe as technically it offers the same as many other remote communication tools, but it uses the metaphor of a physical office to make it easy for us to relate to the situation. When we used this tool something quite amazing happened, suddenly we were in the same metaphoric space as ‘the business’, we were truly working together. If I had a question for the PO I can drop by their office. If we need clarification from a SME we can invite them to join an Ad-hoc meeting.
We were no longer waiting for scheduled meetings to ask questions, we were chatting immediately. Feedback loops became immediate conversations, if someone was busy they would drop in between calls or other meetings rather than scheduling something formal. The casual nature of the metaphor brought us all together. This is how I imagined agile teams should behave in an office, but all too often logistics (read lack of meeting rooms) meant this was rarely a reality.
As a little tangent I worked with a delivery team a few years ago where the PO was available to the team all day but was in an office maybe a 60 second walk away. She made it clear the team could drop by or call her. But they never did. As an experiment I asked her to sit at a desk in the team area, immediately the team was a buzz of questions and conversation, we worked faster and discussions were spontaneous and relevant to the work at hand. This is how Sococo feels now. I can’t express how excited I am about it.
An interesting thing has happened too, the team had an aspirational goal of daily demos, demonstrating completed stories and getting feedback on direction each day at stand-up. The aim was to challenge the team to keep stories small and to focus on shortening the feedback loop.
What happened instead was the realization that you don’t need to wait for stand-up. When a story was done the team would pull everyone together immediately get feedback and then discuss and plan what was next.
We realized that scheduled meetings for everything from story writing to stand-ups were primarily about availability of people and especially meeting rooms, they had little to do with the product or agility. When not restricted by availability of meeting rooms you can simply talk about what is needed when you need to. It is so liberating.
Naturally such a change requires a great deal of discipline to be effective but you have the potential to be focused on the shortest feedback loop, and reacting immediately.
By moving to a virtual environment we are becoming more agile than we were even together in the office, and having fun doing it. These may not sound like ground breaking discoveries but I can assure you they are having a profound impact on our work.
Slides from the presentation this evening at the Agile Product Ownership St Louis Meetup group.
The talk was a very high level overview of Lean thinking and how the wastes can be applied to software delivery.
For those interested in joining future meet-ups, we are open to all. The group is aimed at those interested in Agile and in particular the Product Ownership aspects of it.
Topics are varied and not always limited to Agile as was the case this evening where we explored Lean thinking and how it applied to software delivery.
For those unable to attend in person we are now offering remote attendance via Webex.
We meet on the second Monday of each month. We hope to see you at the next meetup.
Sherlock Holmes was a master of deductive reasoning and problem solving, rarely was a problem beyond his capability. However, every once in a while he encountered problems that required a greater level of consideration, it would stretch his mind to it’s limits and required him not to be disturbed for an extended period, he described these as 3-pipe problems, he would need the time it took for him to smoke three pipes.
I am no Holmes but I have the joy of a 3-pipe problem to immerse myself in. I have been asked to lead an endeavour to create, build and run a virtual office comprising of cross-functional teams that create software. The challenge is to grow an office but maintain agility, retain our company culture, and have the teams happy and engaged. Oh and be profitable too.
Where I have seen remote work successful in the past has been where there were clear tasks assigned and collaboration was a minor element of the work. My observations of many remote workplaces is that they focus on individual contributions, collaboration is asynchronous and there is a heavy overhead of management assigning tasks.
What I am envisioning is a workplace where the team is self organised, and whilst there is likely an increased element of asynchronous working it will be alongside effective collaboration. I see my role as identifying healthy boundaries that enable collaboration and creativity.
Naturally communication is key, just as it is in brick and mortar offices, but when we are face to face we have a lifetime of skills to rely on. Instinctive awareness of body language, sensing mood and tone, not to mention touch – hand shakes and physical contact create bonds we don’t fully understand.
Remote teams communicating effectively is far more complex than simply joining a webex. I see the ability to communicate and collaborate as the number 1 challenge of this role.
As an agile coach I strongly support the Agile manifesto (alongside Lean, ToC, and Lean Startup) and the manifesto favours individuals and interactions over processes and tools. It also advocates face to face communication. And yet I am taking on a role that is putting barriers between people and pretty soon I’ll be talking about how processes tools are vital for enhancing individuals in their interactions.
So why take on a job that seemingly flies in the face of this? The answer is twofold, First I believe the manifesto is a mindset for guiding teams in improving their way of working to get better at delivering software. I believe we can adhere to that mindset in this environment, I don’t see a conflict. Secondly I think that the focus and scope of the manifesto didn’t consider the larger picture and the changing state of the workers needs. Face to face is better – no argument from me, but it comes at a cost. We need to weigh up what is lost and what is gained from remote working and decide if what we gain is worth the sacrifice and I think with the right attitude, training and tools the desired outcome of effective collaboration can still be achieved and achieved in a way that is better for many team members.
What is more, I think this will be one of the most challenging coaching roles I have faced. Just like teams, coaching is far more effective face to face. The coaching may take on a different dynamic but I still very much see this as a coaching role.
Processes and Tools.
I warned you! To have effective communication and collaboration in a virtual workplace processes and tools are vital ,and are a prerequisite to the individuals and their interactions. But I don’t see a conflict here, in face to face communication there are processes and tools, we just don’t feel the need to mention them as they are natural to us.
Don’t shout, don’t mumble, don’t interrupt, pay attention, look at the speaker, be respectful. Lots of processes and a lot of non-verbal communication. And just watch for hand gestures or pens on post-it’s or whiteboards these are all tools, we hardly consider them that way and we certainly wouldn’t object to any of those processes or tools, they are necessary for our interactions.
In a virtual world the need is the same but the tools are different, tone of voice and body language are harder to decipher, so we need to be more attentive and more explicit. pen and paper are replaced with online collaboration tools, shared screens, electronic gestures and Slack messages to clarify misunderstandings.
The scope of the task is daunting but I so excited about this. My employer is already a leader in Agile software delivery, this is the chance to demonstrate that we can be agile about flexible work environments without sacrificing what has made us successful: collaboration and self-organization.
This blog will continue to be Agile focused but I’ll also share some of the experiments as we discover what works for us.
I was chatting to a friend recently, he is a manager of an IT department and I used to manage a software department before I became a Agile Coach so we tend to talk a lot about management techniques and especially how a lot of the successful traditional techniques map to an agile work environment.
It was performance review time and the topic of conversation got around to a frustrating belief by some staff that working long hours without being asked is something that should have an implied reward. That working long hours is in itself a reason to be praised.
I can’t speak for all managers, but for the two of us I can say that we consider it to be the opposite, when someone works late on a regular basis without being asked, we see that as a bad thing, it is a red-flag. Certainly not to be commended and very likely a sign of deeper problems.
I used to pride myself on being a good manager, I felt I was fair and sought to do what was best for my employees and the business, sometimes it was a fine line and often not easy. But one of my strongest principles was to be fair. I would never assign someone more work than I felt they could handle (that is not to say I didn’t seek to challenge them), I would generally discuss in advance what they felt was fair and I would always say very clearly that they should come back to me if they had problems, and I would review on a regular basis – usually at least weekly.
As an Agile Coach I have obviously changed my behaviour a lot and learned so much along the way but generally speaking it could be said that the roles are reversed, the team decide what they feel they can commit to and they review with each other on a regular basis (at the daily stand-up) and can ask if they need help, they should assign themselves small chunks of work and no more than can be reasonably achieved.
Have I assigned too much?
In either of these scenarios there should be no scope for voluntary, unpaid, overtime. In the case of assigned work: if you cannot get it done in the allotted time then it is a failure of my management – either I have incorrectly assessed the amount of work or I have misjudged the individuals capability to do it, and unless I have opportunity to be aware of that I cannot correct my behaviour and the cycle will repeat.
The same is true in Agile, whichever chosen framework you use the model is built on empirical evidence, if your forecasts are off you learn and adjust next time. Working overtime hides problems and perpetuates failing cycles, it also causes an imbalance in the team, it makes pair programming difficult and sends mixed messages to others. Very simply as a team manager or a self-organizing Team you cannot fix a problem you don’t know about. Overtime is analogous to cards not on the board, it is hiding work, this is very damaging to a self-organising team.
Rewarding bad behaviour
So should you reward someone for working late, for their dedication and loyalty? or should they be reprimanded for their lack of transparency, or their inefficiency of working? Are they displaying a lack of courage in not challenging an unrealistic expectation? Are they stretching work to appear more busy? Should we reward their failure to communicate an excessive workload, or for failing to ask for help with their lack of knowledge/training/understanding to achieve the objective at hand?
As a manager if I ask you to work overtime I would do so with a very heavy heart, I know that it is not good for you, I know it is not good for the business and any gain is short-term and short-lived. It will only be in exceptional circumstances, where there is justification or benefit in working overtime.
As a member of a self-organizing team you should set those same standards for yourself: You should know that it is not good for you or the team, You should know it is not good for the business and any gain is short-lived.
So if you do voluntary overtime which conflicts with our team plans or expectations please don’t expect to be rewarded for it. That may sound harsh but I value communication far more than I value you giving extra time, especially if by doing so it is hiding problems elsewhere that we could and should be addressing.
This is not a call to work to rule, this is a request to understand the difference between being a team player and expecting recognition and reward for setting yourself up as a martyr. By doing so, try to understand that you are working against the interests of the team, this is not behaviour we should be rewarding.
Sometimes it is necessary to work overtime but this should be a deliberate team decision with a clear objective. It should be open and transparent and should not be one person acting alone.
*Note when I saw reward, this is everything from a positive comment from leadership to financial reward. Sometimes leadership even acknowledging this behaviour is seen as a reward, the belief that your actions were noticed is quite an incentive for some.
I occasionally get asked why and how I became an Agile Coach and whether it is a fulfilling role. When I began my career I certainly had no intention or expectation to be here, I was a software developer, I loved writing code and like most developers I wanted to create something that made a difference.
What followed was 15 years of… I want to say frustration but that is unfair because I generally loved my work and got to create some great software, but I always had this belief that there was a better way, a more effective way to get the job done, I dabbled in project management and team management believing I could do better than those I had worked for in the past. My problem and I suspect it is a very common problem is that I spent a lot of effort trying to do my job better, to be more efficient, more effective, to deliver more etc. etc. It turns out that was wrong and I was wasting a lot of effort and not getting the results I expected.
And then quite by accident (and for all the wrong reasons) I stumbled on to Scrum. I was running a software department and we were forever fire-fighting and I saw Scrum as a tool I could use to control the workflow and manage the demands on the team. It worked, and in the breathing room it created I was inspired to look deeper, beyond Scrum to Agile, and then Lean and Systems thinking and the Theory of Constraints and then I saw it. I felt like I had discovered the meaning of the universe, and once you see it you can’t un-see it, you see it everywhere, it feels like it is staring you in the face.
There is nothing more deceptive than an obvious fact.
― Arthur Conan Doyle
Of course I hadn’t discovered anything, I had just opened my eyes and it was right there in front of me and it was so unbelievably obvious that it almost feels stupid writing this.
And it is this simple:
All we have to do is work on the thing that adds the most value and stop working on things that don’t add value.
Work on the thing that adds the most value and stop working on things that don’t add value.
So I said it was simple but it took me 15 years to start to understand it and nearly 10 years later I am still figuring it out, because whilst it is so simple that it should have been obvious all along, it is also remarkably difficult to do.
What is Value?
The primary problem is to understand what value is. figuring out your value stream in a system is key, and to be fair most businesses do this to some extent, but most individuals do not understand how they fit into the system they are in, nor do they understand how their local system fits into the big picture.
We cannot see the value we contribute to the system and when we don’t see what is most valuable, we do what we see as most valuable in our line of sight. Crazy as that sounds it is nearly always the wrong thing, optimizing for us nearly always optimizes against the larger system. The bigger the organisation the more this happens and the more inefficient it gets.
- the loss of potential gain from other alternatives when one alternative is chosen.
Another aspect is that so much value is obfuscated, it gets lost in opportunity cost which is invisible on balance sheets and yet is likely the biggest cost you pay when developing software. Or cash flow, leverage and return on investment, these are fundamental aspects of successful business but they are generally encapsulated and decoupled from the parts of the business that can impact them most – especially IT and software product development. Many projects get given budgets and time lines, which is a horrible way to run a business and it cripples cash flow, it also significantly limits investment opportunities and increases risk significantly. But worst of all it delays delivering value.
So that is actually two problems, first is that we need to figure out what is valuable and then we have to communicate that to those doing the work.
In that sentence is the heart of being an Agile Coach, my role has become one of helping organisations understand their value stream, especially how software impacts and interacts with it, helping visualise that value and prioritise it and then to help communicate that to those that will create the software and deliver that value as quickly as possible.
- Discover what our goal is – how do we deliver value? What outcome are we trying to achieve?
- Communicate that to everyone so we each know how we help to get towards the goal and how we avoid getting in the way.
Unfortunately the majority of the time is spent dealing with people that are just like I was, they are doing their very best to be as efficient and possible in their domain, simply because they cannot trace what they are doing to the value delivered. So I spend much of my time doing my best to help them see that often what they are doing is at best not achieving anything useful and more often is actually damaging to the bigger picture.
Let me give an example that a friend of mine shared recently: My friend was baking some cakes for an event and needed to bake 10 cakes, but only had one oven. Her husband offered to help out and so she asked him to measure out the ingredients for the cakes in advance so that it would be quicker to get the next cake in the oven.
When she came to get the ingredients for the cake, they were not ready, her husband had optimised for himself and not for the goal. He concluded it would be much more efficient for him to measure out 10 batches of flour then 10 of… etc. after all he knew they would be needed later and it was quicker and far more efficient for him to do that than to do small batches and keep switching.
The result was that whilst he was being efficient for himself, the system grinds to a halt and must wait, his efficiency came at the cost of massive losses to value delivery (cakes baked).
Perhaps if he had understood the full picture, and how his contribution impacted the value stream he would have planned his work differently? He would have prepared one cake at a time even though it was less efficient for him. Together they would have reached the true goal more quickly.
But the funniest part of this story for me was that she was so frustrated, she thought it was obvious, and he thought he was being efficient. Those opposing view points are so common in this line of work.
When you see it, it is obvious but until you do it remains an enigma.
Why be a coach?
Now imagine that confusion on an industrial scale, a whole organisation of people conscientiously working hard in the belief they are being efficient but still struggling to deliver software, delivering software that is not what is wanted, features that are not needed, struggling with integration and so on. Then this loony guy comes in and says that you might actually contribute more by being less efficient. – I’m the loony guy and I love it.
Agile is a mindset for getting better at delivering software and coaching is about helping you. But my goal is not to help you improve just a part of the system, the goal is to help you improve the system, and that starts by helping you and the whole organisation see the system. and learn how to communicate where we can add value.
Obviously there is a lot more to Agile than communication and value, but in my experience if you figure those out the rest falls in to place.
There are a handful of books that I repeatedly recommend, all of which display true Agility and yet to be contrary not one is about ‘Agile’
This talks about being clear in your goal and how to communicate it to your organisation, it is not quite as specific as I am hinting at in the article as we must delve deeper but it is an amazing book and the emphasis is on over-communication.
This book uses a production plant as a metaphor for delivering value to your customers. The emphasis is on the manufacturing equivalent of delivering working software, doing it regularly, and that delivery is not about development, OR production OR deployment it is about everything – essentially encouraging Dev Ops. It also has a lot to say about the non-sense of Dev-Done and how the only Done that matters is to have it in your customers’ hands.
Read it! This is hands down the best book on Agility I have ever read. There are many others by this author all of which are great but this is my favourite.
I wholeheartedly subscribe to the Lencioni school of thought on many things (hence two books by him in this short list). On team building this is one of the best books out there, it describes the stages of team development, and you see this time and time again. Team dynamics are such a crucial part of agility and fundamental to success, this helps teams see those stages and is a great tool for helping teams bond.