I have worked in software delivery for over 25 years now and in that time I don’t recall ever hearing of a project being cancelled due to lack of efficiency. By contrast I have seen numerous project cancelled because of misguided decisions in the name of efficiency. The most common is where team decide to build out infrastructure or data layers or business logic that they “know they will need later” and it is more efficient to do them now. The team works really hard but the client sees little or no progress and cancels the project. This sadly is something I have seen far too often.
This thought process is anti-Lean and it is anti-Agile but still it comes up daily. Teams anticipate future work and prepare for it, they over engineer stories or add elements that were not requested, “while I was here I added somethings we will need later”, all the time giving the impression to the customer that progress is slow. The team themselves feel they working hard and are adding value by being efficient. This lack of alignment between team activity and customer priorities and expectations almost always results in customer disappointment and teams feeling underappreciated. Since it is the customer that pays the bills misalignment with them is destructive to a project. That perceived future efficiency is never realized because the project doesn’t last long enough to benefit from it.
So why is it that we see efficiency as such a powerful virtue despite evidence to the contrary?
The sooner begun, the sooner done
A lot of it stems from misguided definitions of efficiency. From an early age many of us are taught that the sooner something is started the sooner it is finished. Or if you don’t start it, it will never get finished. We have a bulk buying culture and a bulk buy mentality. The belief that over time we will save money or make efficiency gains. What we don’t think about is opportunity cost or what the trade offs are for our actions. These costs in general far out-weigh any efficiency gains.
Cashflow is king
82% of small business closures are due to cashflow rather than profitability. It is not that they are not profitable but that they don’t have the cash available immediately often because it is tied up in unsold inventory or materials waiting to be processed. This is essentially the same manifestation of what is happening in software. We are tying up our time and energy in future potential and we find the project gets cancelled before we get to profit from our efforts. Value to customers is like cash is to businesses. It is no good telling a customer we are accumulating value for later when they need and expect the value now.
So the claim that the best way to get something done is to begin is only half right. The best way to get something done is to finish what you started, before starting something else. If we pay more attention to starting than we do to finishing we end up with many started jobs and very few finished jobs. We need to reverse our sense of efficiency to see value in finishing jobs and efficiency in completing work sooner rather than starting more jobs or extending them.
Stop starting, Start finishing
Whether it be software or manufacturing the efficiency we should be striving for is reducing the number of activities in progress. Be efficient in how many we complete, not how many we start. Starting on something that will not be finished until much later will more often than not create additional work in maintenance and confusion, not to mention the more valuable work that could have been done while you were being ‘efficient.’
Let’s reevaluate our understanding of efficiency and let’s stop starting and start finishing.
I have seen a number of articles recently that refer to the stages of remote work or maturity of your remote team as a linear progression to only one possible Nirvana. The Nirvana in question appears to be 100% independence, 100% asynchronous communication and no need to ever have any work-related human contact at all. Some companies even go so far as to explicitly not allow work related conversations insisting that all are in writing to avoid knowledge silos.
Whilst I understand the reasoning I find myself disagreeing with this conclusion. Yes – Being remote opens up the possibility of hiring from anywhere in the world, which means that there are the potential of round the clock time zones. Yes – being able to work whenever you want around your other commitments and family demands is an amazing benefit. And Yes the inevitable consequence if those are taken to the limits can lead to a conclusion that effective asynchronous written communication as the necessary means of communication. But it is not the only possible outcome.
For some companies especially those embracing full flexibility or round the clock time zones this may be desirable on some level. But I do not see it as the inevitable solution nor a desirable solution for all. Just like in the office there are different solutions depending on the circumstances.
How much flexibility is necessary?
Not all companies will have employees around the world or even want to. Many will already be in a single time-zone or a few closely connected ones so time zones are not an issue. And when it comes to flexibility how much do you really need? Is that flexibility worth trading human contact? I used to work in an office, including drive time I was committing a 10-11 hour block of time every day. Now I am at home we adopt a core-hour system where we ask people to be available for meetings in a daily 6 hours window. Essentially if there is a team meeting booked in that time period we expect you to make every effort to be there, but this gives a huge amount of flexibility. I have more flexibility than I could possibly need especially in comparison to an office. I have gone from 11 committed hours to 2 or 3 per day with a lot of flexibility around that. Some may want more flexibility than this but if it means giving up human contact that extra flexibility comes with a very high price tag.
If I have sufficient flexibility and I don’t need round the clock time zones, why then would I choose a policy of avoiding human contact? In a pre-covid world it has become a widely accepted truth that co-located cross-functional teams are more effective and more productive. Agile prefers Individuals and interactions over processes and tools, and Customer collaboration over contract negotiation. I’ll happily trade some small loss of flexibility for a highly interactive and effective team.
Two years ago when I was asked to create an all remote Agile software development office I began with the assumption that this meant effective interactions and extensive collaboration. The principles behind the manifesto spell out some essentials:
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
None of that supports asynchronous written communication. So you could say that we went against the crowd when creating a remote workforce as we prioritized real-time human-human interactions and rejected, where possible, written interactions.
The path less followed
Going against the crowd is always risky, but part of being Agile is that We are uncovering better ways of developing software by doing it and helping others do it. At the time I felt we were in a position to experiment, not with remote work, that was a commitment the company had made, but on how we implemented our remote office. I worked very closely with a like minded colleague and we came up with a plan for Remote Agile Teams. We decided that we would become pioneers in creating an environment for remote Agile teams with a heavy focus on co-working and collaboration.
We were already largely working as external contractors and not in a situation where we were working as closely as we would ideally like with stakeholders. Just like everywhere else, business-side stakeholders are busy and we were often limited to planned meetings and infrequent touch points. It became increasingly apparent that remote working actually gave us more opportunities to work closely with the business side. Perhaps not face to face physically but our interactions were more effective and more frequent than before. This increased interaction has led to far better outcomes. Because we were all remote there were fewer barriers to interactions with clients.
It was liberating to witness business-side representatives reduce their turnaround time on critical features. It was nice to no longer worry about booking our highly sought-after meeting rooms. And lastly, it was reassuring to realize that the focus should not be on face to face but on determining the appropriate form of communication given the constraints. With a newly established and excellent track record, we began reevaluating these principles and felt confident enough in our abilities to embrace the spirit of the Agile principle and even build upon them in a virtual office setting.
But to do so we needed the right environment, an environment where business stakeholders and delivery teams could effortlessly work closely together daily. Real-time collaboration was key, and we intentionally removed as many barriers as we could to allow for effective communication channels. We relied on training, the right tools, and clear expectations to make this happen.
Is Remote Work compatible with our software delivery practices?
As we follow the Agile principles, we were heavily relying on practices like Pair Programming, Mob Programming and Test-Driven Development. We strongly encourage automated delivery pipelines and team ownership of the code and of the product. In a remote setting, this posed a challenge as we had to consider how we would ensure effective communication and how to deal with connection lag.
To be successful we needed tools and environments that enable our teams to continue with pair programming just as they did in the office. In the office, developers would typically share control of a single computer but with two keyboards and two mice attached. Remotely this posed a harder challenge as we also had to factor in remote communication and lag. The ability to share screen control, see the same things, and communicate clearly in real-time became a challenge. It was crucial to find the right tools for this as it was far more complex than simply sharing a screen.
There were other practices that we needed to support remotely such as stand-ups and retrospectives which are closer to meetings but have individual attributes that needed to be maintained in a remote setting.
Proximity, Awareness & Spontaneity
In looking for ways to enable remote work effectively we did a lot of research and experiments. In our research three terms came up again and again. Proximity, Awareness & Spontaneity these are not simply features of a tool, but words that describe feelings people want to have when using a tool. Software to support remote workers like this is not just a collection of functionality but a virtual environment where we are able to recreate human to human interactions. The best tools allow people to engage on an emotional level. We added breakout rooms as a 4th pillar to round off the expectations we had for a remote environment.
We created a virtual environment where collaboration and co-working was enabled, supported and effective. Yet, we didn’t follow the ‘standard’ work-from-home model that most remote workers are used to. Our environment can be described as a flexible all day interactive workspace which expects ongoing, frequent, and sometimes sporadic communication. We created a sense of situational awareness of our environment and of our colleagues to allow for spontaneous conversations between our team members and between our teams and our business-side stakeholders. We feel close to our colleagues and have minimal barriers to interactions with them. We have an environment where pairing and other agile practices are not only supported and seamlessly enabled but are effective and productive.
We are a workplace that routinely over-communicates, extensively collaborates, and empowers team members to quickly discuss a solution and make decisions. We are able to do this throughout the day and often with short-notice or no-notice. We have working agreements that support variations in time zones but also reflect a need for high-frequency interactive collaboration. We have tools and policies that preserve our culture but allow us to grow and evolve with new work techniques.
In short we are Agile in a remote setting. We believe we are pioneering an alternative to asynchronous working and are hopeful that this is the start of a rapid growing trend.
Two years ago I was asked to set up a remote office with the intent to grow an additional option for our employees and clients. Today we have numerous teams working in this environment, and due to Covid we now have over 500 software delivery team members working from home but still together, we are based all over the USA and in the UK. The patterns we set up for 100 employees scaled seamlessly for the rest of the company So after two years working with remote Agile Teams we can confidently say that not only is it possible to have remote Agile teams, but that they thrive and are exceptionally effective.
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.
– Cost & Inconvenience
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.
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.
I have been asked by a friend to write an article explaining the concepts of Herbie from the book “The Goal” in a more accessible way. The book itself is amazing but in my opinion the language used in the 5-focusing steps has tried too hard to be scientific and precise that it makes it harder to understand. My annotations simplify the terms but likely lose some of the precision of the wording, I offer this as an introduction to the topic but encourage reading the book to get the full impact, I cannot do it justice here.
Herbie is a character from the book “The Goal” he was used in the story as a metaphor for a system constraint and the impact it has on your delivery. I’d highly encourage you to read the book but hopefully it is not essential to be able to follow the explanation, the purpose of the metaphor was to make the thought processes relate-able, hopefully this helps.
The 5 focusing steps
Identify the system constraint
Exploit the constraint
(Make the best use of what you currently have)
Subordinate everything to the constraint
(Make decisions based on the constraint, the system should run at the pace of the constraint)
Elevate the constraint
(Make improvements to the constraint)
Repeat the steps
Step 1: Identify the constraint
We need to figure out which part of the system is holding us back the most – limiting our ability. We should know that only an improvement at the constraint makes a difference.
Herbie: In the example of Herbie, he was observed as holding everyone back he was slow and the rest of the group had to regularly stop to wait for him to catch up or were racing ahead. In the case of Herbie the constraint was evident through observation.
Reality: There are different ways to identify a system constraint sometimes observation and experience is sufficient, or metrics can help. The simplest way is to look at your work is it piling up somewhere? Do you have a lot of stories in Dev Done, or waiting on PO approval or needing wire-frames? Piles of work are a sign of a constraint.
Another common constraint are blockers, if you are consistently waiting on another team, another person or another resource this is a sign of a constraint, we may use blocker clustering or other root-cause technique to see if there is a common theme to delays.
The third most common technique is to review cycle-time for stories, look for stories that are taking longer than others see if there is a pattern, common aspects, this could be a constraint that may be improved.
Step 2: Exploit the constraint (Optimize)
Before we consider adding capacity, we should make the best use of the capacity we already have. We ‘Exploit’ in this sense means doing everything possible to use the constraint to its fullest capacity. This is also the easiest and generally cheapest improvement you can make to your system.
Herbie: In order to maximise the performance of Herbie, the contents of his backpack were shared out so he could concentrate on the most important task of walking. Making the others slower (less efficient) by carrying his stuff was unimportant as Herbie sets the pace for the entire group.
We could also have ensured that he got his lunch first so could start sooner, and others could have covered his chores so he was more rested – our goal is to get the best out of Herbie on his most important task – walking.
Reality: In our systems we need to identify what the most important task is, typically this is getting a story to done and the software in the hands of the user. So when you identify your constraint look for anything they are doing that is not helping to move stories or for anything they are doing that someone else could do. Are they filling in paperwork that someone else could do? does this task really require their expertise? Could you make them a coffee so they could focus. (This is not encouragement to over-work, breaks socialising and generally a healthy working environment always takes priority).
Step 3: Subordinate the non-constraints
The job of all non-constraints is to subordinate their decisions to the constraint’s needs.
That sounds extreme wording but essentially it means that no mater how fast you go, if you are dependent on someone slower you are wasting your efforts, so work at the pace of the constraint, you have reserves so you can catch-up if necessary. Use the time saved to help optimize the rest of the system.
We do this as step 3 because it is more disruptive and more costly than step 2.
Herbie: In the story Herbie was put at the front and the rest of the group were told not to overtake him. When Herbie was able to go faster there was no one in front to delay him so we got the best from him and as the others were able to go faster overall they were able to make up any delays. The goal was only achieved when everyone was done so there is no benefit in getting ahead.
Reality: Don’t let work pile up, if we limit Work in progress we focus on flow rather than utilization, put effort where it has most impact on the whole system. In the case of dependencies on 3rd parties, could you give them advance notice so they are better prepared and can respond sooner. If you are dependent on a 3rd party could you see if there is a time/day they can respond more quickly, could you tailor your process to be more convenient for them? Tailor your process to maximise the effectiveness of the constraint, and this is the tough bit – even if that means making the process worse for others.
Tailor your process to maximise the effectiveness of the constraint, even if that means making the process worse for others.
Step 4: Elevate the constraint
Only once we’ve completed the previous steps does it make sense to add more constraint capacity, and thereby increase system performance. Because adding capacity is tremendously expensive in terms of time and money, we do it as a last resort, not a first step.
Herbie: In the case of Herbie, we could get him doing fitness training so he is quicker, or buy him a bicycle.
Reality: This is typically where you spend money, hire more people, get better/more equipment. Invest in training or education. Remember improvements here improve your entire system so the investment must be calculated based on system income not local costs. Maybe you ship parts by air, maybe you fly in an expensive expert, maybe you lose money on this aspect of a project so that the project as a whole makes more money. Keep the focus on the gain to the entire system and not get distracted by the cost at one stage.
Step 5: Return to step 1
The inevitable result of the first four steps, and the reason this is a “continuous” improvement method, is that the constraint will inevitably move somewhere else.
This step insists that you start back at the beginning, and don’t let inertia become the constraint.
A second example of the steps being applied…
Access to overworked Doctors in an emergency – constraint is a shortage of Doctors:
Exploit: Make the best use of what you currently have
Ensure Doctor is not doing any activity that someone else could do. All admin work is removed, prep work done by nurses or other staff.
Vacations/time off is deferred,
Doctors may work overtime so long as it doesn’t risk the patient or cause the Doctor to quit
Subordinate: Make decisions based on the constraint, the system should run at the pace of the constraint
Any non-urgent treatment is stopped until emergency is over.
Cases are prioritized so Doctors are only working on the most urgent cases.
Patients are only ‘prepped’ according to the capacity of the Doctors.
Patients are prepped in advance so that the Doctor is never waiting.
It may be quicker for a Doctor to move between patients rather than them coming to the Doctor.
Elevate: Make improvements to the constraint
Now we look to increase the number of Doctors or their effectiveness
transferring Doctors from other areas withing the organisation
recruiting more Doctors even at inflated rates or short term contracts,
any increase is an increase so we can hire someone that is semi-retired or part-time.
We may automate activities or buy tools to improve the efficiency and effectiveness of the doctor.
We could train Nurse to perform some of the Doctor’s activities
We look and see whether the Doctors are still the constraint or whether there is a new constraint.
There may be a little ambiguity with some of these improvements, e.g. A Doctor moving between patients may be considered elevating or subordinating, but it doesn’t matter it is an improvement, it is a thinking process and some changes don’t neatly fit into one category, don’t let that distract you from the thinking process itself.
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 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 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.
It may sound overly simplistic but in my experience products generally succeed or fail in correlation to the effectiveness of Product Ownership on the team. Mainly because we under-appreciate the importance and the difficulty of the Product Ownership aspects in the product creation process. In my opinion the choice of this role is far more important than the coach or other team members. The role is full spectrum, they go all the way from discovery to delivery and more.
Ironically, we tend to think of software applications as being primarily technical objectives, our focus is too often on the quality and ability of the engineers, the architecture and design. We will spend time on process and optimization and efficiency. All the while forgetting that the most common and most consistent failure of all software products is that no matter how good the quality, how optimized or efficient it is, or how good the engineers are that built it – if you build the wrong thing it is a failure. A perfectly designed but unused product is worthless.
History if full of great products that missed the mark, how many apps have you downloaded to your phone that are no longer used or were never used after the first 30 seconds. There are many many more products that fail to ever get in the hands of customers at all. Internal IT products are often culprits of this, the assumption seems to be that because the users are forced to use the product we don’t have to actually ask them what they want or how they will use it, we build great products that don’t fulfill the actual user need.
I think probably my favorite and most over used quote is:
There is surely nothing quite so useless as doing with great efficiency what should not be done at all.
I use the quote far too frequently but in 25 years developing software this remains the most frequent sight I see, more products fail for not meeting the most basic customer needs than for any other reason. And yet when I say this, it generally gets scoffed at, until you start asking how many people have worked on products that have been abandoned or shelved mid development. Teams rarely believe their product is at risk of being cancelled, or are too far removed from the customer to appreciate that the user liking and using the product is infinitely more important than whether they are efficiently re-using a section of code. We have created a mindset that ‘done’ is delivering code. A product/feature/story is only really done when the customer is using it.
Product Ownership does not need to be a single person in that role, but it should be a mindset within the team. Ideally I’d love for this to be a shared responsibility. Unfortunately in my experience a true appreciation of Product Ownership is as scarce as Hen’s Teeth, and generally unappreciated and vastly underpaid, those that do it well make it look easy and doing it badly or being indecisive can really destroy a product so it can be a risk to spread the responsibility beyond one person. I have heard people talk of teams where the teams do it well and they don’t need a PO, but I have yet to see this for myself. Because of this experience I think of the Product Owner as the most important ‘hire’ for the team, getting the right person in this role can be crucial to the success of the product.
A good PO these days is hard to find…
So why is a good Product Owner so hard to find and what makes the role so difficult?
1: Differentiating what is needed from what is wanted
A significant part of the role is identifying what is needed to solve your users problems or to fulfill their needs, to enable them to be better at their job, or to maximize their fun or relaxation. The role is about understanding the problem and creating a vision of how that could be solved – not the technical solution but discerning the true need or true problem.
If I had asked people what they wanted, they would have said faster horses.
The reason this skill is so tough is that users rarely know what they need, typically a user’s vision is constrained by what they currently do. As a result many products become re-works of a paper system or re-engineering an old system. A poor product owner gives a customer what they want or what they ask for, a good product owner listens and watches and blends wants and needs to solve the customer’s problem and give them what they need.
I often seen backlogs that are full of stories that are unfiltered customer requests, it is lazy and it is easier to do what is asked. But to find what is needed typically requires experimentation, feedback, conversations and observation. It is far harder to build what is needed than it is to build what is asked for. Similarly this can manifest itself when department managers decide what their team needs or wants without involving them in the discussion, a good Product Owner will spend time with the users of the product and ideally see how they use it.
A Product Owner with the creativity, the initiative and the Vision to create a great Product is worth their weight in gold,
2: Understanding what is required to create a successful application
A second aspect of the role is the one I see most frequently overlooked. Perhaps because of the emphasis on 1, the need to understand the business, I see people choosing someone from the business to become the Product Owner, their knowledge of the business is seen as their primary qualification and in many cases their only qualification for the role. And worse they are often asked to do the role in addition to their normal job.
However, a great Product Owner understands not only what to build but is familiar with the development process, they understand the ebbs and flows, they understand the implications of technical debt, automation and testing. The understand how crucial it is to have working software in the hands of users as soon as possible. I am sorry to say that business POs often lack this knowledge and experience, they will mistakenly perceive a desire for a fully working product rather than appreciate the value of early feedback. Many are plagued with the last bus syndrome, trying to include every imaginable feature rather than working towards a minimum feature set to get feedback and derive value early.
Personally I’d invariably trade an experienced Product Owner with zero business knowledge for an expert in the business with zero software delivery experience. Business knowledge can be gleaned from effective conversation, observation and feedback. The understanding of a good Agile Software Development lifecycle is far harder to learn and there is no substitute for experience.
Typically the best products result from experiments, reviews and feedback, a willingness to be flexible and respond. The other disagreeable quality of a Product Owner taken from the business is that their knowledge is about how the work is done now, and they are often blinkered to the possibilities.
Remember that the Product Owner sets priorities and interprets the Vision, they have more influence on the product creation than anyone. Their choice of priorities can profoundly impact the value, and the quality of the product. If they lack the understanding of the importance of testing, feedback and good software principles it can lead to conflict and disharmony in a team.
3: Communicating effectively with both technical and business stakeholders
Finally there is a need for effective communication. We always talk about effective communication to the point that it becomes background noise. But the importance cannot be overstated.
A great Product Owner, listens, they observe, they probe and they reflect. The ask for feedback and they read between the lines, they watch body language, they see and hear what isn’t said as much as what is said. When it comes to understanding the user they have great attention to detail and they look intently for pain points and points of pleasure, they are looking for a way to serve their users in the best way they can. Most of us think of communication as speaking, but for a Product Owner watching and listening are so very important. Empathy with the user, the customer and the ability to communicate using their terms and understanding their domain and conversing with them in a meaningful way is crucial, and if you don’t understand the terms develop an attitude of attentive student ask questions and show you are interested and are learning.
A great Product Owner learns to say ‘No’ powerfully respectfully and does so in a way that conveys they understanding to the person asking, a great Product Owner should not be seen as an obstacle or a hurdle but a steward of good decisions. The word ‘No’ should be delivered in a way that leaves me feeling confident that the Product Owner will deliver the best product within the parameters and leaving me confident that this decision is right even if it is not what I initially wanted. The Product Owner should be able to convey the implications of saying ‘Yes’ so that I understand why I am being told No. A great Product Owner has any number of tools that can help people see this and yet we regularly see backlogs full of feature requests that will never see the light of day because the PO doesn’t feel capable or sufficiently empowered to say NO!
But the PO must also communicate with the development team, they must understand technical development terms, to have a grasp of the technical implementation, even if they do not have authority over the ‘How’ I’d expect them to have a vested interest in understanding it. They also need to be able to communicate the business needs and the business terms in a meaningful way to the development team, This requires a versatility in speech and communication that is unusual to say the least. Being respected and understood by both the business and the technical team is a major feat, and as we all know any cloistered group speaks in three letter acronyms that only they understand and the audible sign when they have to explain to an unlearned outsider can demoralize the best of us. Do not underestimate this ability.
But there is more, they need the creativity to communicate design ideas or if the ideas come from others the scope to understand that creativity, to imagine what could be and express that to the business and to the technical team. And then we get into the really tricky realm of the stakeholders as opposed to the users, this generally is the group that funds the product, they want to see progress, they want to see good stewardship of their investment, they may ask for forecasts and may even press for commitments.
We have now loaded our Product Owner with the need to communicate with senior people that make financial decisions, to express Risk and Forecasts in a manner that it concise but meaningful, we want to be transparent and informative, but confident. If we are using forecasts especially mathematical forecasts we had better understand them and be able to back them up with explanation and confidence. A Product Owner my stand their ground in the face of authority and speak truth to power. A Product Owner that makes unrealistic commitments or promises, will lose the confidence of her team and her stakeholders in a flash.
If a Product is to be sold it is likely that you will need to be involved in Sales and Marketing, which brings a whole host of other skills and communication issues to bear, understanding the implication to the market, and how you measure that and how you engage with that is a new realm of understanding and confusion.
A great Product Owner is a master communicator, they have an insatiable desire for knowledge, to understand and be understood.
As you can see the skill set of a great Product Owner is monumental, and yet the good ones make it look easy. If you have a mindset suited to Product Ownership it is likely you already have good communication skills and enjoy learning more domains.
It is likely you are the sort of person that thrives on the delivery of a product and revels in the feedback, enjoying the flexibility and change, is unmoved at the thought of redoing something twice or even more to get it right.
Solving problem is a thrill and being able to see beyond the obvious and draw out information from users and then present something back is a joy.
That doesn’t mean it isn’t incredibly difficult, overwhelming at times and sadly unappreciated, and very often underpaid.
At some point the industry dismissed all these skills as unimportant and we see a flurry of Product Owners that write stories exactly as dictated by users, that input data into forecasting tools without the vaguest notion of what the forecasts mean or how they are calculated.
As I said at the start a great Product Owner is the lynchpin of a great Product, we should be seeking them out and rewarding them appropriately, you will be amazed at what can be achieved with the right person in that role.
There are two ships traveling a busy shipping route, each ship has a complex engine and the engineering team has a chief engineer. Both ships are a similar age and size.
The first ship has a very busy chief engineer running this way and that, fixing any and every problem that comes up, he knows every inch of the engine and many parts of it are custom made by him. He is dirty and oily and hard working, whenever there is a problem – and there are many problems – he is on hand to fix it. He is dedicated and hard working, he works long hours and is always ready and willing to get his hands dirty. Without him the ship couldn’t function.
The second chief engineer has spent his time not fixing things, if a part is unreliable he has replaced it, if a component is troublesome it is gone. If there is a problem he ensures one of his team fixes it (with guidance initially) and will encourage them to spread the knowledge so that after a while he rarely if ever gets his hands dirty. He is rarely dirty or oily and it is a very rare situation to see him fixing anything. On many voyages he can seemingly sit there with his feet up doing very little in maintaining the ship and can use his time on other productive activities. Frankly if he missed a voyage the ship would probably run just fine without him.
Now which in your opinion is the better chief engineer? I know which one I would rather have on my team.
It is often said that the goal of a good Scrum Master is to make themselves redundant, I take exception to this a little I think as in the tale above it is possible to create a situation where you are not necessarily needed all the time. But I wonder how long a team would last as a top-performing team if the Scrum Master was taken away, perhaps in the short term no one would notice, but growing and shaping and coaching a team takes time and effort, but slipping back into bad habits can happen quickly. Creating a situation where the Scrum Master has time to do other things is a good thing and a reflection of success not a sign he is not needed. A Scrum Master that is essential to a team is one that has failed, in fact if ever you feel you have an employee you are overly dependent on you have a serious issue.
How many top athletes would say “I’ve reached me peak I no longer need my coach”? My guess is that if they feel they have reached their peak they will seek out a new coach that can push those limits further.
A good coach or Scrum Master guides the team to independence, and then pushes their limits further. They may be more useful elsewhere but that is very different from becoming redundant.
Over the years I have discovered that the more I learn on any subject the more I come to realize that I know very little, it doesn’t seem to matter how much I study or how much I learn, the awareness of scope of my ignorance grows far faster. Does that make me wise or just aware that I know very little? I suspect that I’m slowly fighting my way out of the valley of despair.
No need to improve
One of the most challenging aspects of being an Agile Coach and working with teams is that to improve you first need to accept that there is room to improve. There are a some teams and team members that believe there is nothing more that they need to learn, they are so supremely confident in their own capability and knowledge that they refuse to consider that there could be a better way to do things than the way they have always done things.
On the other-hand I can’t be confident that there is a better way, only that we won’t find a better way unless we look. I don’t like the notion there is a ‘best practice’ as this limits our thinking. But this puts unwavering certainty that this is the ‘best practice’ against encouragement to explore the possibility of a better way, certainty is very powerful.
Sometimes this ‘certainty’ is founded in fear, especially when dealing with transformations where former roles are called into question, I find this an understandable reaction, but the situations I struggle with most are the team members that become blinkered to opportunities, they have found one way that works (even poorly) and simply are unwilling to try anything different. Their Ego, prevents them considering anything else.
As a coach I have no desire to force processes or ideas on people, only to open their minds that there could be opportunities and alternatives. So it can be heartbreaking when people refuse to even consider alternatives, or worse impose their views on others through sheer force of will.
Perhaps I am mistaken and maybe the right answer is that if something isn’t broke don’t fix it, but that notion doesn’t sit well with me.
So how do we persuade people to open themselves up to learning new things?
I recently had an experiences that I found tough, there was a QA who refused to ‘leave his column’ on the board, he would not do anything that was not ‘testing’ and resisted anyone working with him in ‘his column‘ thankfully it is not often I see that level of obstinance. But this situation was further compounded by the rest of the team enabling his behavior. The developers were all too happy not to be involved with the QA aspect and were seemingly unmoved by his unwillingness to cross boundaries.
The QA column was regularly a bottleneck but rather than addressing this the team wanted to mask the issue by pushing cards through and raising new cards for rework. What was tough was that the team saw no need to experiment with alternative ways of working: suggestions included either helping the QA, or even getting the QA involved earlier, and despite raising QA as a bottleneck repeatedly in retrospectives the team didn’t want to change behavior even in the form of an experiment.
As a coach you can shine a light but not force a change. I felt the team was capable of far more but the team were getting things done and were seemingly content with the status quo. For me this is the dark side of coaching, where you must watch a team not reach their potential, out of respect for their independence. Ultimately it is a trust issue as things so often are.
Ownership of Columns
In general I dislike explicit roles when there is a shared responsibility, and I dislike the notion that a column on a board is in anyway related to a person or a specific role, the board should reflect the progress of the work (stories) not ownership of the work and when the two become muddled people become defensive and territorial.
When there becomes an association between a column and a person the focus moves from getting a story done as a team, to moving a story on to the next column, we switch our context of efficiency to a narrower view.
This is often seen as a subtle and unimportant distinction. But when the team loses a cohesive sense of ownership for getting to done and can hand off responsibility to another sub section of the team, bad habits emerge. At it’s worst I have seen teams (thankfully not one I coached) where at stand-up one part of the team will brag about how many stories they are ahead of an other part (be it front and back end or Dev and QA). In one extreme case I saw a team decouple testing from development by splitting stories and I overheard one standup where the developers were gleeful that they were now 3 sprints ahead of testing (the sprints were 3-week sprints). It is 9 weeks before they will see value from their work or even know if their work had value, and yet they were so proud.
Dunning Kruger Effect
Adjusting your mindset to one of learning rather than certainty can be tough, especially for those that grew up in a culture that rewards confidence and certainty, but accepting that you don’t know everything and being aware that there is always the potential to improve can enable you to become far more capable, the only thing stopping you is your ego.
The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts.
As a coach it is very easy to get wrapped up in theory rather than practice, the topic itself is challenging because it is so simple to understand but so difficult to execute. We see so many Agile Transformations fail, so many poor implementations of Kanban or Scrum and at times it feels great other time so futile, the concepts are neither complex, nor new, but they are very difficult to implement effectively and in a lasting manner.
Successful Agile Software Development is in my opinion based on three similar but intertwining thought processes and if any one is absent the strength of the whole is significantly diminished.
Reflective Practice and Application
Sometimes we get focused too heavily on the principles and the values but the Manifesto begins with what I think is a statement more important than the rest.
Manifesto for Agile Software Development We are uncovering better ways of developing
software by doing it and helping others do it.
At the very heart the manifesto is about getting better at delivering software.
“We are uncovering better ways” – it is a journey of discovery, we do not have all the answers. “by doing it and by helping others do it” – It is not just theory, and we share our successes with others so they can benefit from our past successes and failures.
It sounds grand and perhaps I would be better served coming up with a less grandiose title but essentially the issue here is that YOU are not the center of the universe. You could mean you personally, or your team.
Systems Thinking = YOU are not the center of the universe
The goal is effective Agile Software Development, solving a problem for a user, with software. Our system is the whole process from identifying a need, through to the delivery of a solution, and that solution being used to satisfy a need.
Our system is not coding; it is not moving a card from one column to the next.
Having great code on a branch that will not get to the user for months or years (if ever) is not satisfying customers, however proud you are of it. The same is true for designs or perfect architecture for features not needed .
In my experience I would attribute a significant majority of unsuccessful transformations (and many business failures) as a result of a failure by members of the team to grasp that they are contributors to a larger system, it sounds insensitive, but you are just a link in a chain, a cog in the machine. Focusing too much on one small part is not helping the organisation or the system as a whole.
And yet we expend a lot of effort on improving local efficiency, and at the same time failing to grasp that your efficiency is irrelevant without context. By focusing on your own local efficiency is at best doing nothing for the larger system and at worst making the larger system less efficient – by not focusing on what is needed. The obsession with coding efficiency in particular kills a great many software products. I see teams actually proud of a growing pile of stories in need of testing, or a team dedicated to front end UI proud of having endless features complete against mocks and how the back end teams can’t keep up. Sadly these teams seem oblivious to the fact that they are not adding value to the system.
Systems thinking refers to the context and the domain but within that is a team – often many teams. The teams are a collection of individuals – all distinct and all different, and your ability to work together (or not) can determine how well you are able to produce software. Teams that bond and grow together achieve amazing things, teams that fail to establish trust can and do churn without making much progress.
An understanding that software development is about people first and foremost, may sound an odd statement when media presents it as a lonely and socially awkward enterprise. But all aspects are about interactions, within the team, with users, with stakeholders, with other teams, the list goes on, but effective communication drives software development.
Those that master the understanding that product creation is a people centered activity and overwhelmingly a team activity will thrive, we build cross functional teams in the belief that self-organisation and motivated groups produce great software – and they do.
It can be tough adjusting from thinking about you as an individual to you as a member of a larger community, but when we can act in a way that best serves our community rather than ourselves we start to become a high performing team, it is worth noting that you do not create a high performing team by simply grouping a number of high performing individuals, often that is a disaster. High performing teams arise when we learn that we are more that the sum of our parts.
The second part of this is that part of being in a community is sharing knowledge and offering support. The manifesto calls out that part of being agile is not just doing it but helping others do it. We find ways to grow as individuals and together.
Reflective Practice and Application
Finally and this is the pillar that binds it together and makes it so strong. We take time to reflect often, so much so that we become skilled in self-reflection and in giving feedback to others to aid their self-reflection.
I believe every team – not just technical teams should take a break and reflect regularly, no matter what you do, you can improve, but you need an environment conducive for that thought process. An hour away from your normal environment may end up being the most productive hour of your week if you can learn to reflect effectively.
Facilitating retrospectives is a difficult skill, getting past the noise to get at the real issues can be difficult and takes skill and practice, but both the facilitator and teams get better at this over time, especially if they reflect on how to improve this skill.
As a group and individually we should take time to identify learning opportunities, we continually observe ourselves and our teams looking for ways to improve. We learn to give and receive feedback in a way that helps us grow – not to diminish us.
We challenge our thinking, we question our beliefs and we look for ways to grow.
We learn how to experiment in structured ways trying new things and observing, we learn the value of metrics and measurements, both in our team and our products.
But the learning and reflection is for nothing if we do not apply what we learn, the application becomes yet another skill we can develop, may of us can become analytical and observant but continue to do the same things despite what we see.
If you always do what you’ve always done, you’ll always get what you always got
Learning to apply our observations and reflections in a structured an effective way is another challenge, and bringing this back full circle to systems thinking we should focus on the area that is holding us back the most and deal with that alone, and then repeat the process.
Trying to fix too many things or focus on too much at once can lead to confusion and particularly if you are measuring impact of changes if you change more than one thing it can be very difficult to know which one had impact.
All three of these thought processes overlap, intertwine and often depend on each other, but when bound together are extremely strong, and we can and will get better at delivering software and helping others to do it.
For this blog post I’d like to make a change from my usual style and share a personal experience.
For the last few months I have taken on the role of Product Owner for a new product our company is developing. It is a bit of a change for the company as they have limited experience in developing their own products, most of the work is typically implementing work on behalf of clients where much of the product development is obfuscated from us.
It is also a big change for me. I have been coaching Product Ownership for a fairly long time now. I previously lead the company’s Product Ownership Chapter and I run a local Product Ownership Meet-Up event each month and I frequently teach Product Ownership and Story Writing workshops.
You might say I am becoming an expert in the theory of Product Ownership. So I could be forgiven for thinking I would find it easy. It is also not my first rodeo, I have been a Product Owner of sorts previously for both hardware and software products .
Before you criticize someone, walk a mile in their shoes. That way, you’ll be a mile from them, and you’ll have their shoes.
It’ll be easy he said…
Maybe it is because I have been coaching for quite a while now, but the transition back has been far harder than I expected. I am (too) impatient to see progress, I am finding it irritating to write stories for things that I find obvious or repetitive. I found myself tempted to make unilateral decisions rather than involve the team; I wanted to get involved in technical decisions; initially I hadn’t made time to create personas; I was using expediency as a very poor excuse for not doing activities that I believe add value. (all things I used to coach against). In short I am a bad bad man, and a hypocrite too.
We did however create a pretty good Story Map and Road Map, the team got together with some subject matter experts and over a few good discussion and we developed a pretty good understanding of our road-map and high level priorities, still at a high level but with enough understanding to make prioritization decisions. We have got in the habit of writing enough stories for the next week or two and there are a good set of wireframes to enable us to start getting feedback on our designs before we commit to the code. We have found a great balance between getting knowledge value, and then delivering working value.
As the product has progressed we have maintained the Road Map turned it into a living user story map and used it for forecasting and release projections and planning, such a simple tool but so effective for enhancing communication. It’s simplicity served us well, communication became very easy internally and externally, and when when we needed to the forecast was very straight forward – and informative.
The aspect I am most pleased with is that one of our first priorities was setting up a delivery pipeline alongside the first stories so now every commit we are able to deploy directly to an environment reflective of our customer (no mocks) and a releasable package is created after every check-in. I cannot understate the significance of this and how this one decision has made almost every other aspect of the delivery process easier.
There are certainly things we could be doing better, but overall I am very pleased with what we have done and I am really impressed with the team, they are an exceptional team that makes my job easy. But most of all I feel I have a much better appreciation for some of the issues that Product Owners are facing and I am reminded what a challenging and important role it is in shaping a product, conversely my hope is that I have made the team’s job easier, being on hand to clarify my understanding of customer needs, making design decisions promptly and making clear the priorities. The joy of being part of a team is that we each contribute something vital to the success and we only succeed together.
I have worked to get and interpret valuable feedback from customers and stakeholders, and as ever this is a challenging task. It would be easy to pass on every request and turn it in to a story, but this is OUR product and our role is to interpret requests in the context of our vision, and the reality is that we reject more suggestions than we adopt, every person you ask has a different and often conflicting opinion of what is needed and that filtering process is challenging and daunting, I hope I have shielded the team from the frustrations that entails. But for product owners out there this filtering is one of the hardest but most important parts of the role.
The role itself is paradoxical at times, some days it feels like there is little to do, but everyone else is busy, other days you are making decisions that will determine whether the product will be a success or not.
Early on in the process it was hard to convey credibility, I am no SME in the domain and our teams are not used to decisions being made in-house, my vision was questioned, it took a lot of will to maintain my course and build trust, I had a rocky couple of months. I controversially chose to go against some of the key stakeholders and not implement some features they wanted, I was vindicated later, but I knew this was a risk and could easily have gone the other way.
This is the hardest aspect of the job especially when you want this to be a team activity and for the team to share responsibility and credit, but the reality is that the role of the PO is to get feedback from the stakeholders and the team, and then make a decision, that decision can be lonely as there is a lot of subjectivity and rarely a consensus.
Product development is very different to project delivery it is much more fluid and we have evolved a lot over the last 6 months the product has grown and improved and now we have two releases under our belt and a happy customer it is an exciting time for us.
I cannot overstate how happy I am with the team or how successful I feel this has gone, I feel like a minor player in such a great team – which I hope is reflective of how well we have worked together and that it means I played my role effectively – although I am pretty sure I was the bottleneck more often than I would have liked.
I will say that we got lucky with the first customer and the support of stakeholders and the team have made it very easy for me. But the one thing that has made this most successful in my mind was the decision to deploy the very first story to a production like environment – that one decision set the stage for a smooth progression and confidence with every subsequent story. I’d encourage that to be the first decision any new team makes.
I was doing a demo the other day and as I was presenting I am thinking (with a disappointing amount of surprise) “Wow – what an amazing product this is” it looks as good as any product out there. Somehow being involved in the process meant I didn’t take the time to sit back and see what we had achieved until that moment.
This is only the first major release and we have many more to come as the product evolves and customer numbers grow. Naturally there are still a few quirks to iron out.
It is my hope that I have learned a lot from this project and be able to use the experience to be a better coach, I’ll be more able to empathize and advise with Product Owners and perhaps be more confident that when challenged I can still apply some of that theory and speak with confidence when I am coaching others.
I hope you will forgive the obvious pride at being part of this team, but aside from that it has served as a reminder to me how difficult being a Product Owner is and how much software is a team sport and the whole team should take pride in the outcome, without any one of us it would not have been successful.