These are slides from the Agile Product Ownership Meetup, where we discussed the Discovery Phase of a product.
Have you ever noticed that late projects only ever seem to get later?
Why is it that any gains get absorbed and delays get compounded?
Let’s say I have a mini-project where I have a builder adding a kitchen to a house, he will construct the walls and then I’ll have a plumber come in to install the pipes and fittings. The builder estimates 4 days and the plumber 4 days.
If the builder is done sooner, say after 2 days, that gain is lost as the plumber was expecting 4 days so is not available until the originally planned date. If however the builder takes longer – say 6 days then this impacts on the plumber and at best delays him by 2 days, but more likely he has other commitments so it may result in delays beyond the 2 days ‘lost’ by the builder if he has to reschedule.
The only way to avoid this is for the plumber to build in slack before and after the planned job which is not practical unless he significantly inflates his fees to enable that level of flexibility.
That is a very simple example of a single dependency between two variable events. The majority of systems have chains of dependencies, each compounding this problem for every additional link in the chain.
Just think about your Doctor, they make appointments every 15 minutes throughout the day, if the average appointment lasts 15 minutes then it is likely by the end of the day as any appointment that runs over will delay the next appointment but any time they get ahead the patient hasn’t arrived yet. By the end of the day they may be running a long way behind and relying on your slack time to ensure you get seen. These are just a couple of examples of the Theory of Constraints in action.
I’d like to share an activity I have been using in training classes to help people understand the impact of variability, constraints and dependencies on a system – including and especially software delivery. The principles are not limited to software or manufacturing but apply to any system where you are dependent on someone or something. It also shows how improvements in the wrong area do nothing to help your team.
I find learning is best cemented when you can take a group and have them look at a problem in a particular way so that they discover the solution and form their own understanding. No matter how respected the teacher offering solutions is they will never have the same impact as when you discover the answer for yourself. This is why I love teaching in a way that involves experiments.
The activity is best played in groups of 4, this gives everyone a role (and a roll of the dice) and enough opinions to have a debate about the implications.
Each team starts with 4 workstations or 4 stages in a workflow.
Each team starts with a backlog of work (a pile of blocks) and each block must flow through each workstation.
In any given iteration, each person in the workflow has the same potential output/productivity and is represented with the roll of a dice. The dice roll simulates a perfectly balanced system and allows for the variability of work: some tasks are easier or harder than others and some days we are more productive than others, but in this simulation we are all – on average – equally capable, we are perfectly balanced.
We run for 10 iterations. Each iteration is started with the first person will perform their work by rolling the dice, moving blocks, and passing the dice on to the next person. Any unmoved blocks remain in progress until the next round, and so on until each person has completed the work for that iteration. Each person in theory is capable of producing an average of 3.5 units of work and after 10 iterations the system at worst case will produce 10 units at best it will have produced 60.
Over 10 iterations, each workstation has an average capability of 35 units, all workstations have identical potential capability. If everyone worked at average productivity the system should be capable of producing 35 units of work.
Planning based on potential capability
This is very similar to the planning process in Scrum where planning is based on estimated times for all tasks. With planning based on the sum of the duration of all tasks being equal to the amount of time available in the sprint. E.g. 10 days worth of team effort in a 10 day sprint.
In the game, we ask the teams to predict the system output, and challenge any team that predicts a system output of less than 35 to justify why they are expecting their workers to be working at below their average potential.
This can be an interesting debate. Some suggest that people are not as variable as dice, or that stories are not as variable, but this usually results in debate and finally agreement that in fact people are MORE variable: tired, hungry, sick, bad day, good day, vacation, level of experience or familiarity with the job at hand etc. all result in huge variation in the person’s output on any given day. Stories can be split to be a smaller size to reduce variation in theory, but the complexity varies. Some need input from 3rd parties, some will go smoothly while others will hit issues, some take longer depending on who is working on it and so on. We take steps to reduce variation but we cannot eliminate it completely. We rarely know everything, so there will always be some surprises.
This conversation is crucial to understanding the the problem that most of us routinely overlook or choose to ignore despite the massive impact on throughput. We allow this conversation to flow to help people understand the fundamental variability in any system.
By the end of the conversation normally there is consensus that variability is the normal situation and a dice roll is an adequate metaphor, albeit real life is far more volatile.
In the first iteration, the teams will be set up so that each player rolls the dice and passes the appropriate number of blocks to the next player, and then that player rolls and passes, and so on until all players have ‘worked’ for that iteration(cycle).
We then repeat for 9 further iterations(cycles) and observe the outcome.
You can run this experiment for yourself and play along here: Tic Toc Game
In general, the result will be an average output of around two-thirds or a little more of what would be expected – e.g. around 23-27 out of an expected 35. Sometimes more, sometimes less, as you would expect when introducing variability but the average for the room is typically in the ~25 range.
We ask the teams to explain why they are running at 70% efficiency and what is going wrong. This usually results in one person being identified as being unlucky or consistently rolling low numbers, but generally there is some understanding that there is a reason for it.
At this point you can dive deeper but usually there is sufficient belief that luck is a factor so you may need them to play again for some to accept that it is not luck.
By running the experiment a few times people generally begin to realise that the nature of variability and dependency have a pretty significant impact on one another and that creating a balanced system is actually pretty futile. We can improve the situation by reducing the dependencies, cross training people or giving them more autonomy – one of the principles of agile is to have a team with everyone needed to get the job done – this is because of this situation. Dependencies have far more impact on productivity than most people are willing to accept. The other factor is variability, whilst there is no way to remove variability completely, we can strive for smaller stories. This is one way of limiting variability. When it comes to humans it is even harder to remove variability, but if we strive for a sustainable pace and a good working environment, this reduces variability even if it doesn’t remove it entirely.
This experiment shows what will happen with a perfectly balanced system, but what is the impact when you have an unbalanced system or add WiP (Work in Progress) limits to a system? And have you ever wondered what the financial cost of big deployments was, we can experiment to see the how much it costs to have daily deliveries compared to monthly or quarterly deliveries.
In the next iteration we can explore the impact of an unbalanced system, where your system has a bottleneck and how you can deal with it.
When talking about the virtual office or remote working in general we often find ourselves comparing to a physical office and talking about how it is almost as good in a variety of situations. Or highlighting the indirect benefits to the business such as the ability to focus less time commuting, the improved happiness of employees, and lower turnover. These are all great but they are not easy benefits to convey to customers.
There are a few areas where a ‘virtual office’ is better and I previously described how we could be more Agile by being virtual but over the last few months we have discovered that we can solve some really fundamental business objectives for our clients without compromising on any of our values, standards, or profit margin.
Example case study
As an example: we have a client that historically outsourced much of their software needs to third parties, the result for them is a mismatch of tools that do not integrate well and have varying standards of quality. They also have problematic and often costly support models and the overhead of dealing with a myriad different vendors.
As a result they have now adopted a policy of owning and supporting their own tools and bringing back in house the tools that had previously been outsourced.
But this raises a number of issues. There are four issues in particular with this situation that they are seeking to resolve. I see these issues as being common to almost all engagements and all companies when they have identified a need for using an external software consultancy.
Bandwidth: their IT department has limited capacity, the teams can only do so much and there is a lot of work to do. There are only so many people available to do it and they have a limited spectrum of skills. Conversely the value of the projects to the organisation is vast. However, limitations on hiring, head count and domain knowledge acquisition mean that the cost of delay justifies using a consultancy to bolster the capability.
Cost: The work could be outsourced and ownership retained if a consultancy firm is employed. After a period of knowledge handover the internal teams could support the software after the project is complete. However, hiring a large team of consultants is expensive, coordination and communication can be difficult. Integration with other tools at the client site is complex – often slow and painful, and knowledge handover is time consuming, all of this is very costly.
Outsourcing to a third party may be difficult from a budgeting perspective. Bespoke software projects are notoriously difficult to assess scope and cost and it is not unusually for projects to exceed initial estimates.
Knowledge/Expertise: The internal teams may not have the knowledge and experience necessary to do all of the work, especially in specialist areas like mobile application support and so it is often necessary to hire experts and then transfer knowledge to internal employees. Knowledge handover is time consuming and when done at the end of a project is often incomplete or doesn’t fully sink in. Risking later failures or expense.
Trust – Generally software is pretty opaque and so when there are problems or delays or unexpected work, or tasks that are more complex than anticipated clients are naturally anxious as it is hard to tell the difference between genuine problems or mismanagement. Trust is often unspoken and hard to rationalize, particularly when you are paying large sums of money for what is often a black box. It can sometimes seem like writing a blank cheque and hoping. Much of this is the nebulous nature of software and the every changing environment but when you are paying the bills this is a hard pill to swallow.
One of our common offerings is co-development this will generally resolve some of these problems.
Bandwidth: We can offer a co-development setup where we intermingle part of the client’s development team with our smaller team and work together on a project essentially half a team each. This is a great solution for this situation, the client retains ownership of the software, they are already working in the client’s IT environment with their employees, so integrating with other systems and teams is easier. Because the client is not committing a full team to the activity their bandwidth is maximized, they could essentially double their capability if they split all of their teams this way.
Knowledge: This method enables the consultancy to supply the expertise and the client to supply the domain knowledge. Knowledge is transferred throughout the project with no need for a clumsy handover period at the end. Knowledge gained by doing the work is far more valuable and reusable. It also shares knowledge of practices and processes in addition to the knowledge of the software.
Trust: By using a co-development effort it becomes a partnership, your team is part of the solution so you have much more insight into the situation so much more confidence in what is being reported. If there is a problem that is more complex than anticipated your own employees are engaged and able to offer transparent and unfiltered insight into the situation giving you far greater trust and awareness. As your team are part of the decisions there is less second guessing and more accepting that the decision made was the best with the information we had at the time. This is not a substitute for good planning and good management but it removes the nagging uncertainty when using a third party.
Cost: The main problem with this model is that unless the client is very close this becomes expensive and inconvenient. The development team needs to be prepared to work away from home for extended periods, there is a lot of lost time for travel. Generally speaking people do not enjoy working away for long periods and of course the client now has travel and accommodation costs on top of consultancy rates, making the service very expensive.
We essentially solved three of the problems but made the cost problem worse and added the complication of inconvenience to the employees. It limits this solution to those where cost is less of an issue or those local to the consultancy.
- + Bandwidth:
- – Cost & Inconvenience
- + Knowledge
- + Trust
Virtual co-development enables us to solve all of these problems. A Virtual co-development model brings all of the benefits of co-development listed above but by the virtue of being virtual there are no travel or accommodation costs, there is no time spent travelling. This cuts out a significant chunk of the cost with very little in the way of consequence.
The virtual nature also makes the team more accessible to the client and the home office, it essentially brings everyone closer.
Shifting to work virtually does come with a slight adjustment period and there are a few technical hurdles to be able to share screens and get access to client’s software environment but these are fairly trivial and common problems and access to a a VPN will resolve this generally and as most companies are already prepared for employees working remotely some of the time it is rarely a complicated request.
- + Bandwidth
- + Cost
- + Knowledge
- + Trust
It is rare to be able to offer a solution that seemingly ticks all the boxes but this seems to me to be one of those rare opportunities where we are able to offer a better service for less cost, with less complications and without compromising profit margins, it really is a win-win situation.
The partnership style of this also reduces complications over scope and budget, it can be more easily budgeted for. By the partnership nature of the work budgets for the outsourced elements can be very accurate as they can be for a fixed duration – rather than arbitrary scope set before the product is fully understood or nebulous outcomes. There is no risk of being forced to extend because of incomplete work or scope change. The ongoing partnership means that the internal team can continue at any time with little or no hand-off. It becomes a much more clean and simple contract.
This model won’t suit everyone and is not ideal for all clients but for those with similar needs to the client above I feel this is a golden opportunity and one where being a virtual team is a clear and distinct advantage.
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.
One of the most common reasons we reject people interviewing for coaching or product ownership related roles is an inability to grasp the purpose and value in splitting stories effectively, especially lacking an understanding of vertical slicing.
This is also a commonly requested topic for me at the meetup or speaking engagements. Yet it is a topic I have struggled to effectively explain. The conversation often ends up as a narrow technical example on certain techniques, or difficult stories or becomes too abstract for people to apply. In short it is a large and complex topic.
But this video sums up the notion of story splitting and in particular vertical slicing and the ‘why’ behind the method so perfectly that I felt I had to share it.
“Successful problem solving requires finding the right solution to the right problem. We fail more often because we solve the wrong problem than because we get the wrong solution to the right problem.”Russell Ackoff
Dr Ackoff sums up the issue with the analogy of the parts of a car, if you assess the purpose of a car to get you to a destination then an engine alone is worthless, even the best designed and most efficient engine cannot get you to your destination. Until it is connected to the minimal set of features to achieve the user’s purpose it is useless and remains useless.
Building any feature that does not work end to end adds no value, and building any feature that does not support the purpose of the user also adds no value. But more crucially it is often the interaction between layers or between components that is the most complex aspect of any development, be it a car or software. and the notion that we can build an engine, and a gearbox and fit them together later and expect them to work seamlessly is laughable. But I hear it all the time in software design.
A system must have an aim. Without an aim, there is no system.W. Edwards Deming
We’ll build the database first then add the other layers, or we’ll work on an API layer 3-6 months in advance of the front end. It is as if we assume that the integration is the easy bit and worse is the assumption that we have anticipated every need of the user (and omitted everything they don’t need) before we design and build the interface, and before we ask for any feedback. And yet as software designers; planners; and project managers we repeat this error over and over, never learning from the pain of not using vertical slicing for splitting stories.
I believe our fundamental attribution error is the focus on the blocks of functionality (the components of the car) rather than the interactions, and rather than focusing on the purpose of the tool and user feedback we plan for efficiency of the workforce. The result is an optimized workforce and an inefficient workflow. We create a sub-par product that has efficient working components but do not effectively work together, and generally this results turf wars over interfaces that do not match the use cases and last ditch efforts to fit square pegs in round holes.
We can learn so much from Dr Ackoff, software alone is not the system, software is a tool, it becomes a system only when it is in use. The only way we can know if the software is efficient is by putting working software in front of a user and for them to use it and give feedback. So the only good way to split a story is in such a way that you are able to get feedback from the user that helps shape the design or to assist in making decisions.
If a story cannot lead to feedback or use, then it has no value, it becomes inventory or work in progress, it is a liability rather than an asset. That Database or API layer that is built with nothing utilizing it is not benefiting you, it is waste, it is an over engineered liability and the pain comes when you integrate it with other components. This extends to unused data fields or unused end points, “we know we will need them later” is a poor excuse for creating additional WiP (work in progress).
Learning is not compulsory… neither is survivalW. Edwards Deming
We as Agile practitioners can learn so much from Dr Deming and Dr Ackoff we are building systems, and the development process itself is a system, if we applied a little more systems thinking I believe we could be far more effective.
But as Deming said “Learning is not compulsory… neither is survival ”
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.
This is a short video giving an overview of #NoEstimates describing how simple and how powerful the tool is but also some clarification of the limitations of the tool.
I recently saw an article where someone said that all leadership, sales and politics can be simplified to just two types of influencing motivations. Inspiration or Manipulation. Essentially you can be stimulated to act or you can be persuaded to act. (Push or Pull)
The manipulation aspect is fairly easy to understand. In leadership this can be reward or compensation, authority or threats. In sales this can be price incentives, offers, fear of missing out or fear of consequences of not having it. Politics is often the same, you will get ‘x’ reward – direct or indirect, or the other guy is worse he will take away ‘y’. We see it all the time it is part of our culture: reward; fear; peer pressure; even bullying; it is rational although not always obvious.
Inspiration is far harder. One person says I believe in ‘x’ and if you do too then you may be inspired to follow them, vote for them or buy from them. A great example would be green companies, we are willing to pay more for environmentally friendly products or animal humane products because we are inspired by their values.
The problem with inspiration is that you limit your supporters to those that believe in the same things as you. For sales and politics this is not a great policy as it cuts down your target audience considerably. The benefit is that if someone shares your beliefs they are a powerful voice they are harder to manipulate and more resilient and enthusiastic about your cause.
By all accounts Steve Jobs was not likable but he was inspiring to his employees and his customers. The same is true for many inspiring leaders even the unpleasant ones. You don’t have to be a nice guy to inspire people you just need to be open about what you believe, to be clear why, and to stay true to your beliefs. Those that share your thinking will support you.
To give you an example of this in action let me talk about Brexit for a little while. Brexit is a difficult and complex topic, I am not an expert and am likely to oversimplify the situation so please don’t be offended. Although I am British I live in the USA and lived here during the referendum so did not get to vote. But I have family that lives in France and everybody British regardless of where they live feels the impact of this decision directly or indirectly. It has been an anxious time for all of us, and it is not over yet!
The UK joined the EEC in 1973, it was presented to the people as a trading union, over the next 45 years it turned into a confederation and now has an open desire to become a federation.
I think it is fair to say that most people in the UK did not know they had signed up for this, and felt that it has evolved without our consent. There is also a sense that we (the UK) have very little influence in the EU.
The decisions by the EU were often in alignment with our thinking and beneficial to us, or did not impact sufficiently to trigger an extreme reaction. There were a few notable exceptions like the Euro and fishing rights, but mostly the EU could be ignored, that is until it became apparent to the masses just how much power had been ceded to the EU.
The referendum was simply a choice: do you want the UK to remain a member of the EU or to leave the EU?
The EU has a mandate for an “Ever closer union” it is currently essentially a confederation of states, with a long term goal to become a federation of states. Ultimately a United States of Europe.
Currently the member states have ceded power for currency and monetary policy, trade agreements, fishing, agriculture, borders, migration and law in too many areas to list here. The longer term the expectation is a European army (including nuclear deterrent), central taxation, and further power. shifted away from individual states to the EU. To Remain is to support the move to becoming a United States of Europe.
To Leave would mean returning the ceded power to the UK and losing the benefits of membership, and likely exclusion from the EU in the future.
Those voting Remain claim that we have benefited from membership and will continue to benefit from trade and free movement, and that EU policy is broadly in alignment with our views so ceding the power to the EU is not an issue as we broadly agree with the decisions and laws created so far.
Those opposed (voting Leave) have quite a large and diverse number of objections to the EU but the majority seem to focus on the issue that the European Commission – the body that creates and proposes laws and legislation – is appointed and not elected, and that they are not transparent. We ‘the people’ have no influence in the laws proposed or in the appointment of the law makers. For a country with a strong democratic history this is a big issue for many. The UK has almost no influence direct or indirect on the EU, we are passengers along for the ride.
And to really set people off, the leader of this group Jean-Claude Juncker is on record for saying : “When it becomes serious, lie to them” and that in relation to a French referendum: if they vote Yes he will act and if they vote No, he will ignore them and continue anyway.
“When it becomes serious, lie to them”Jean-Claude Juncker
Interestingly looking at the two arguments it appears that the Remain have the Inspirational goal and the Leave are based on manipulation and fear.
But the campaign changed that drastically. The Prime Minister David Cameron had the support of his cabinet, the support of the leaders from all the major parties, support of the mainstream media (apart from a few loonie papers), it had uncharacteristically overt bias from the BBC in support of the EU, not to mention celebrity endorsements all over the place. All the PM had to worry about were a few dissenting voices in his own party and UKIP – a fringe party that struggled to get a seat in parliament. He felt the referendum would be a slam dunk. In any other situation he could quite reasonably expect a huge landslide with the way the deck was stacked in his favour.
The Leave campaign was led by a less then credible man that had the aura of a very dubious used-car salesman. I think at the start of the campaign most people felt that the outcome was a foregone conclusion and the vote was simply an opportunity to warn the EU that we are not to be taken for granted and we would like our voices heard in the future.
The primary Remain campaign strategy was “Name calling”
Watching the campaign unfold was shocking to me. The Remain campaign rather than talking up the benefits of the EU or the inspirational goal of the EU, they decided to make their primary campaign strategy to call Leavers names.
Almost the entire Remain campaign seemed to be centered around the claim that if you vote Leave you must be a racist bigot.
Rather than choosing to inspire or even discuss reasonably, Remain were so confident of victory they chose to belittle those that didn’t agree with them. Unsurprisingly those voters with reasonable concerns felt ignored and insulted. They felt manipulated and pressured and that their only voice left was a vote in a secret ballot box.
Leave perhaps in response to the arrogance of the Remain strategy took on a much more inspirational campaign, they talked about “taking control of our destiny”, “taking back our borders”, “making our own trading agreements”, “making our own laws” All this was about independence and autonomy, an inspirational call to arms. It played on out dated notions of empire and sovereignty and in many cases was meaningless rhetoric but it nevertheless inspired the voters.
The Leave campaign certainly had a fair share of manipulation with claims (many questionable) about money not going to the NHS and the waste of funds in the EU, crazy expenses of EU politicians, and there was certainly a vocal minority that wanted to block immigration. But this was all secondary to the notion of independence and autonomy.
In contrast the Remain had similar wild and questionable claims, but I hardly ever heard anyone in the Remain campaign say anything positive about the EU for the UK. It was all just negativity about those voting Leave. Or edge-case examples of how very small groups of people would be worse off. There was nothing inspiring in the campaign nothing to feel good about.
There is an old adage that when you insult the person rather than the policy you have lost the argument, and I think that is what has happened.
When you insult the person rather than the policy you have lost the argument.
Even in the aftermath of the vote, the Remain voters talk about how Brexit will hurt them personally or someone they know, or the near-term disruption to the markets and trade, or the retaliation we should expect from the EU. For people inspired to independence and autonomy, the obstacles, disruption and short-term issues will not change their mind, they have an inspirational long-term vision (that may very well be flawed) but it can’t be countered by complaining about the impact to individuals. They believe in a better future or at least one in which they have some control. Threats of retaliation by the EU just further reinforce the view that they were right to vote leave. I hear a lot of people that were on the fence during the vote but seeing the EU’s attitude since the vote they are now far more against the EU than before.
In my opinion, If you want to counter the Leave vote you need to inspire people to stay, and from what I can see no one has tried. You need to shout from the roof tops why the EU is good for the future and how you and the EU will listen and address their concerns.
The result was a clear and surprising victory for the Leave campaign, the leaders were surprised and confused they had no expectation of winning. and Remain had no plan for what to do if they lost. The country is now confused and lacking direction, the losers are in power trying to achieve something they opposed. People we know and care about are in a situation of confusion and uncertainty. Who knows whether things will be better in the long-run we will have to wait and see.
I think it is a rather extreme example of the power of inspiration and the inherent weakness of manipulation. Threats and promises don’t work if a person can be inspired.
In my opinion the Leave campaign did not win, the Remain campaign went all out to lose. When you openly insult your electorate it is hardly surprising that they rebel against you.
For those in a position of leadership it should be an eye-opener to the power of inspiration. State your intent, your vision and those that share it will be fierce supporters. But if you choose to lead through manipulation, your hold on your followers only lasts until someone makes them a better offer.
We all want to be inspired, we all want to share a vision and work towards it but all too often our leaders don’t share their thinking or in some cases believe we can be manipulated, or worse need to be manipulated, the result is that we become what they believe, we react to how they treat us.
We want leaders that inspire us (and I don’t mean political opportunism) but genuinely tell us what they believe and the “Why” behind their actions and decisions. We want to support these leaders because we believe in the same thing.
Unfortunately inspiration alone is insufficient, you also need a plan. Brexit is now a mess, there was inspiration for the vote but no plan for what to do when they won.
The absence of a plan is disastrous:
Vision without action is a daydream, Action without vision is a nightmare.Proverb.
Right now Brexit looks like a daydream and for many Remain looks like a non-democratic nightmare. Whatever the outcome we are losers.
It is always tricky using politics as an example but I have tried to be impartial. This is not meant to be a debate on the politics. I just want to highlight the contrast in impact when you inspire rather than manipulate. If you would like to comment could you comment on the this rather than Brexit, there are plenty of forums for that.
A question I have been hearing a lot lately is how do you know whether an employee is putting in their hours, or not slacking off. This question seems to be particularly concerning for people in the context of working from home where the perception is that it is more prevalent.
The irony here of course is that being in the office is no measure of not slacking off, there have been many books written about different ways you can slack off whilst appearing to be busy.
I have heard tales of the productive worker that works hard all day long only later to discover they were working on a side project or even for a second employer. Long lunches, toilet breaks, extended coffee breaks, fake meetings, or just browsing the internet or discretely playing games on your mobile phone. Physical presence in an office is not an effective measure of whether you are slacking off.
The average American worker admits to wasting 2.09 hours a day, excluding lunch, according to 10,044 self-selected respondents in a survey released by America Online and Salary.com.
What does it mean to Pull your own weight?
Let’s take a little aside and explore the phrase “pulling your own weight” there are a few suggested origins of the phrase but the one I like best relates to the English Long-bowman, to be considered an ‘archer’ you had to be able to “pull your own weight” Longbows had a draw of up to 180 Lbs. You really did have to pull your own body weight.
An experienced archer could fire 12 aimed shots in a minute at ranges of 200-300 yards, although in battle they were expected to fire at a slower ‘sustainable pace’ of 6 aimed shots per minute. For context a modern bow draws at around 40 Lbs for women and 60 Lb for men.
In a modern terms we usually mean contributing proportionate to your role. We tend to think in terms of productivity and output. Despite this we often tend to focus on hours spent – hence the rise of slacking off at work, even though we can easily slack off time without being noticed, but it is far harder to slack off output or deny outcomes.
So how do you know whether your employees are working?
Personally I think that is the wrong question. When you explore deeper you discover that the employee surveys on why people slack off are far more interesting than the ways which they slack off.
Many described being bored as the primary reason, others felt that their job was easy. So it seems to be a question of engagement.
I suspect in other cases it is that you have hired the wrong people and better filtering at hiring would result in a more motivated workforce. Ironically when you have a motivated workforce getting them to take a break becomes more of a challenge.
So I guess what I am saying is that if you are a leader that is worried about whether your staff are working, then the issue is far more likely to be with you than it is with them.
- Hire the right people. (Hungry Humble, Smart)*
- Be clear what is expected of them.
- Help them understand why it is important – and who benefits from their work.
- Be interested in them as individuals.
Interestingly all of those actions fall to the leader rather than the employee.
If you follow these steps then I suspect that you won’t need to worry whether they are pulling their weight, you will be too busy trying to keep up with what they can achieve.
Where does the responsibility lay
If your employees are slacking off then it is a failure on the part of the leader not the employee. So when you hear someone ask how they can tell if an employee is doing their hours and not slacking off. Ask them if they have hired motivated people they can trust? Have they given clear objectives and set expectations? Do their employees understand the context and purpose of their role? Do you value them and do they know it?
If and when you do see someone slacking in a damaging way, take a look and see if the route cause is one of these 4 issues, you’d be surprised how often it is one of them.
What I am confident of though is that any efforts to monitor time in the office (or home) – such as time clocks, pressure sensors on seats, keystroke monitors, swipe cards on toilets, or a foreman to watch people – and of course a foreman for the foreman – obviously you need someone to watch the watchers. All will have minimal impact on people slacking but will have deeply damaging impact to productivity.
*Taken from The Ideal Team Player, by Patrick Lencioni