Isn’t it obvious?

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.

opportunity cost

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.

Two Problems

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.

Example

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’

The Advantage by Patrick Lencioni

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.

The Goal by Eli Goldratt

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.

The 5-Dysfunctions of a Team by Patrick Lencioni

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.

The 3 Elusive Qualities of a Product Owner

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.

Peter Drucker

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.

Henry Ford With 1921 Model T — Henry Ford stood next to his ‘Faster Horse’

If I had asked people what they wanted, they would have said faster horses.

Henry Ford

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.

Summary

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.

Never talk about politics!

I grew up in the UK but I have lived in the USA for a little over 6 years in total, which equates to around a quarter of my working life, so whilst I still feel very British there is an element of the mid-Atlantic creeping in. That is to say I feel like I have grown a level of understanding for some of the quirks of American culture and am a little more sympathetic to the perception of the UK culture from the American side of the pond.

However being so overtly British I get to hear the same questions repeatedly and some of the misinformation is a little troubling at times. Especially when it can be fact checked so easily. Since this is my soapbox I’ll indulge a little before I get on to the topic at hand.

First the USA did not win the war of 1812 please take 5 minutes to read wikipedia. Second, the UK NHS: I have been in the USA for 6 years and in that time I have worked for two employers both of whom tell me that the health insurance they provide is the best there is. My colleagues tell me it is better than anywhere else they have ever worked. I have no reason to doubt that this is great Health Insurance, and apparently it costs around $27,000 per year – mostly paid by my employer and that is in addition to the social security deductions which are approximately 8% of my paycheque.

In my experience the quality of service offered by the ‘best‘ Health Insurance is approximately identical in quality of healthcare to that received from the NHS. Yep you heard me, I find no discernible difference in quality of care. There are certainly differences, I have to pay a co-pay to see my Doctor here in the US which is free in the UK. Doctors in the USA want to push you to take every test under the sun so they can bill the insurance, where in the UK they assess if there is a need first. In the USA if there is a referral it is on you, whereas in the UK your doctor would follow-up. The Doctors’ surgeries here seem to be a bit more lavish and they need an army of staff to administer the insurance bureaucracy but as far as wait times, quality of medical treatment and accessibility of treatment I see no difference.

So I do get a little upset when I say people describing the UK medical system as having poor treatment and long wait times and something to generally be afraid of. Think of it as having the best medical insurance you can buy, and then imagine that it is free to you, I can see why that is so incomprehensible when you are used to spending nearly $30,000 per year on that service. I am sorry to say it so bluntly, but the USA spends on average 4 times as much for what is very much an inferior system for most people.

Okay I’m off-my NHS soap box now.

But the third and most troubling perception that I am regularly confronted with is the notion that the UK is a ‘Socialist‘ country and the USA is a ‘Capitalist‘ country. This notion troubled me a lot and got me thinking, but first let’s clarify the definitions:

Socialism: political and economic theory of social organization that advocates that the means of production, distribution, and exchange should be owned or regulated by the community as a whole.

Capitalism: an economic and political system in which a country’s trade and industry are controlled by private owners for profit, rather than by the state.

Essentially the extent to which you are a capitalist or socialist country is determined by the extent to which the government interferes with the free market, either through spending or through legislation.

Measuring Capitalism

Spending is pretty easy to assess as we can see what proportion of GDP comes from government spending and how much from ‘the free market’ However, legislation is much harder to measure and by definition any intervention in the market is ‘socialist’. E.g. Defence, immigration, policing, taxation, tariffs, subsidies, etc.

I think most people realize that pure socialism is fatally flawed and equally flawed is pure capitalism, so it is really a question of how little or how much government is needed and how much can the market provide on it’s own. We all have a reasonable expectation that infrastructure, defense, police, jails etc cannot be provided by the market and that the whole country benefits from education and healthcare for the poor as the benefits are far reaching to the economy but how much of the rest is open to debate.

Let’s take the USA, the US spends a staggering 35% of it’s GDP on socialist activities, that is more than a third, and is incredibly socialist in it’s government policies and legislation, just recently there have been some very high profile trade tariffs, a trade tariff is direct manipulation of the free market by the government – it is the very definition of socialism. Lobby groups regularly persuade the government to invest in particular parts of the country or legislate for the benefit of certain industries. Both the UK and the USA bailed out banks and the USA bailed out the car industry and corn farmers.

By contrast the UK spends 41% of it’s GDP on socialist activities, and also heavily regulates the free-market with employment laws, they provide tax-breaks for entrepreneurs and subsidies for ‘green’ businesses to name a few, but notably didn’t bail out the car industry or steel industry or mining industry.

In my anecdotal experience and to be clear this is opinion based on only very limited education in Economics and Politics, neither the UK nor the USA has any claim on being capitalist countries, both may claim to be slightly right of center but are both squarely ‘Mixed economies’ and have found a balance that is slightly further from Socialism than Capitalism but not by much. And whilst the UK spends more, my observance is that the USA regulates more and is far more interventionist in investing, bailing-out, propping up and otherwise supporting USA based industries.

TL:DR Summary:

The UK and USA are broadly similar in terms of the degree to which they are Socialist or Capitalist in practical terms, but in my observation the UK is more willing to intervene for the benefit of the people – especially the poorer and the USA is more likely to intervene for the benefit of business.

What has this to do with Agile?

So what does that have to do with Agile? Well it strikes me that there are a great many parallels. If we equate Socialism – a planning heavy form of governance, where plans are made by a few experts:- with ‘Waterfall’ and Capitalism – a responsive form of governance where the market leads and the many respond independently of governance:- with Agile, then maybe you can see where I am headed.

In small scale both Waterfall and Agile succeed, but as we scale both suffer in different ways. In Waterfall as in Socialism the planners become further removed from the market they are serving and are less responsive to particular needs and more and more out of touch. a great deal of overhead is needed to align the vision from the top and unsurprisingly they are often so far removed they get it wrong, corruption sets in and effectiveness (the true productivity) plummets.

By contrast in Agile as in Capitalism works very well in small scale but as we grow the decision makers are not able to see the big picture and whilst they are responsive to what they can see, they fail to see the larger system and optimize for themselves rather than the larger organization and problems set in with misalignment. There are some aspects of a business that simply don’t work by being responsive and need to be planned and organized.

Governance

So where does that leave us? Well at heart I am both a capitalist and an Agilist so I am biased, but the way I see it as we scale with Agile and in business in general we discover that we need governance, some degree of consistency, infrastructure and support and most of all a clear direction. But I believe we should keep that governance as small as practical and only govern that which we cannot govern ourselves.

In the case of big government I believe that includes socialised healthcare because normal market forces do not apply when it comes to our health and so the market cannot effectively provide what we need, I also believe that we should invest heavily in socialised education as better educated workers make everyone wealthier.

When it comes to Agile teams I don’t think the teams should do the hiring or decide pay and they don’t generally want or need to be bothered with administration or infrastructure, I feel that is governance that they should be spared, similarly I think ‘health care’ such as vacation, benefits, and support (HR) is governance. Start-ups will need to deal with all of this but at scale we shouldn’t have to. Nothing controversial so far, but where we may start to see differences of opinion is the level of governance needed for teams.

In my opinion we achieve the best results from small teams, that are given clear direction and are empowered and enabled, that means direction not a director, so team leaders, project managers or any other similar role is bad for teams, it is unnecessary governance and is in my opinion fundamentally anti-agile.

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

The best architectures, requirements, and designs
emerge from self-organizing teams.

That doesn’t mean we don’t need managers or leaders, but we don’t need them involved in the work. In Scrum we empower Product Owners to set direction and priorities but they stay out of the HOW, we empower Scrum Masters to coach us on process and guide us on improving flow, we even empower them to remove impediments on our behalf but we do not empower them to tell us HOW to do the job. In my opinion Project Managers (when they are deemed necessary) should respond to information provided by the team and not the other way round, they are a consumer of information only! They should convey no authority.

Where we need managers is NOT for doing the work, a suitably cross-functional team should be able to do that without an anointed leader. What we need managers for is the ability to create those cross functional teams, and do this by listening to what is needed, hiring and enabling the forming of those teams. We need leadership to provide clarity of direction, clarity of culture and clarity of values. We need managers to help us by enabling us grow as individuals in our individual careers in parallel to our goals for the team. We need managers for ensuring that we as an organisation are planning for the future so we can focus on delivering in the present.

If you feel you need a manager to manage the team doing the work then in my opinion you have failed elsewhere, it is a sticking plaster to a bigger problem, all you are doing by instilling team leaders/Project managers or team managers on a delivery team is masking a bigger problem elsewhere, possibly in hiring, training, education or communication.

The prime role of leadership is ensuring clarity, they have the big picture, making sure their employees see it too should be their number one goal, any other governance in the day to day job is an unnecessary overhead and a smell that there are problems elsewhere. The corruption inherent in larger systems needs to be cut out at the source not covered up with a layer of management. If you are hiring the wrong people then fix your hiring process, don’t hire people to manage problem staff. If you are struggling with consistency or maintaining values then it is an issue for education and clarity, putting a manager on as team is not the solution: enforcing values is not the same as instilling values.

In Agile, like Capitalism, we want government to be as small as possible and only get involved in things that we either can’t do ourselves or are necessary but unrelated to our day to day work. Unnecessary bureaucracy and governance are well, unnecessary.

Give them the environment and support they need, and trust them to get the job done.

Hire the right people and let us do our job, educate don’t regulate, enable don’t enforce, but most of all trust us, don’t try to control us. Set a direction, then get out of our way.

Goldratt User Stories

As a product owner we should be building products to deliver on the Vision and a set of defined objectives or success criteria. But often our plan is not closely mapped to those criteria or it can be difficult to measure whether we have achieved our Vision or delivered on our objective.

Let’s change the way we write stories

So I wondered if we could expand on a desire for delivering measurable value by changing the way we both plan projects/product and write our user stories?

Tell me how you measure me and I’ll tell you how I will behave.

Eli Goldratt

The notion of this is that rather than defining our User Stories in terms of behaviour, or actions or activities – in which we primarily focus on the ‘What’ we should change, our start point should become us defining the “needle we want to move” Let us start with the measurement of success. Understanding how we will be measured and identifying behaviour that impacts the measurement.

E.g. our goal is to increase the number of items per basket for online sales, our measurement is therefore the average number of items sold per transaction.

Equally it could be to increase the average value of the basket per transaction, or increase the number of units sold of high profit products

Hypothesis rather than Story

Our ‘story’ then would be to ask the Product Owner and Team to identify one or more hypothesis for ways that could impact that measurement. The notion being that a hypothesis must be tested before the story could be considered done.

This could take the form or a brainstorm session to identify the more traditional stories or it could simply be left for the team (in conjunction with the PO) to determine the best way (possibly two or three alternatives) to achieve the desired outcome after the story has been pulled.

This is building on the principle:

The best architectures, requirements, and designs
emerge from self-organizing teams.

Already happening?

You could argue that this is already the role of the Product Owner and that the Product already does this, and in identifying and prioritizing stories they have already considered the impact. In some cases I would agree with you, in a few cases I have seen products or projects with clear objectives in terms of the goal of the product and even sometimes a measure of success in terms of measurable objectives.

I have yet to see the end goals mapped even at a high level to the stories and features, in most cases success criteria are wooly or undefined and more often than not the Product Owner and team will brainstorm stories (story mapping) without reference to the goals, and even Impact Mapping often will not extend to measurable goals.

That is not to say that the Product Owner is not considering this holistically, the measurements are generally part of the consideration but many stories creep in that have no material benefit or impact on the success criteria of the product.

Measurements for Goals as the basis for Story Mapping

For reference I love Story Mapping, I consider it my favourite tool for Product Ownership and have been known to rave a little too much about it on occasion.

The start point in story mapping is typically to identify themes of user activities (you could call them epics but don’t get hung up on terminology they are essentially big rocks and then we will progressively break them down in to smaller rocks arranged underneath the big rocks.

We can then prioritise the work in the context of the whole rather than being constrained by a linear backlog which makes the context difficult to visualise.

It is also a fantastic tool for explaining the product for release planning and forecasting and so on. Like I say one of my favourite tools.

But what if instead of starting with activities or big stories, what if we started with our measurable goals or success criteria. e.g. new subscribers per month, revenue per visit, time to achieve objective using application etc. And we then identify stories that best enable us to achieve that goal.

There may very well be some overlap so there maybe the notion of tagging a secondary objective, but imagine if this helps us weed out stories that are not taking us to our goal or have limited value in the context of our goal.

We would ask which of these stories has the potential to move the needle the most? and prioritise accordingly.

Make it measurable

Focusing our efforts on measurable impact to the product should implicitly be the goal of any Product Owner so why not make it our explicit goal?

The 4 steps to successful software delivery

After [reading / posting] a recent article on waste, (read it here), someone asked me why we shouldn’t do work that we will need later if it is more efficient to do it now? You have already dug the hole—doesn’t it make sense to do all the work in that area together?

This is very similar to the argument for splitting stories horizontally along business layers: “We can be more efficient if we optimize and specialize.”

Yes, you might achieve local efficiencies by taking these steps. But local efficiency is not the most important factor in your decisions. Efficiencies and optimizations need to be considered in the context of the whole system.

The primary goal is to Maximize Value Early

For both project and support work, our goal is to maximize value for our organization, and to realize this value as early as possible. In a consultancy firm, there is a slight abstraction, as work is paid based on time and materials, and these steps are distributed between client and team. Regardless of who owns the following steps, success depends on shared awareness of these priorities.

The 4 Steps

The four steps are designed to focus our energy where it will have the most impact first, and then building upon the previous step by shrinking the focus area through each subsequent step. Hence they are in descending order of impact.

1 – Prioritization
(Selecting Which Project/Product to Build Next?)

The most important decision your organization needs to make is which work will bring the most value NEXT. This has the most impact on your company’s bottom line, so should get the lion’s share of effort and focus.

Describing the value a project will bring is far and away the most important aspect of software delivery. If possible, create a formula for calculating business value to help with these decisions. If you are unable to quantify or qualify the value to the organization of the work being undertaken (at a high level), then you are likely working on the wrong thing and all other actions you take could be waste.

Some projects/products will obviously bring in huge amounts of revenue. Others may save huge costs in manual entry and work-hours. Some may support business-critical systems that, if not supported, create extensive risk and potential cost. A project might also fulfill a safety or regulatory concern, or business objective.

Naturally this is complicated and can be difficult. Priorities change. Time factors and organizational politics come into play. A lot of the time you will be making informed guesses about value and costs. But this decision dwarfs all of the others in the impact to the bottom line, so is critical to put the right amount of effort here.

I would consider this to be the responsibility of the Program Manager or Project Management Office, but I see the responsibility to be to identify the projects that will bring most value to the organization as the end of their role. “Day-to-day Project Management” responsibility lies elsewhere.

I would however strongly encourage this decision-making process to be transparent and inclusive. Hold a regular Project review board and invite the stakeholders. Make the process clear and help everyone understand how the decisions are made. I would also suggest a visible roadmap of work planned.

Finally, I would encourage you to not plan beyond your company’s horizon. If new work is likely to emerge in the next 3 months that may significantly change priorities, then only plan for 3 months. Only start a product or project at a point you feel committed and certain it will be completed. Starting something with the expectation of pausing or pivoting suggests it wasn’t the most important thing to work on next.

2 – Direction
(Product Ownership – Building the right Product)

Whether this a new product or supporting an existing product, it is important to ensure that you build the right product, Product Ownership is covered in lots of detail in other places so I won’t go in to details but I suggest watching this video:

Like prioritization in Step 1, the most important responsibility in Product Ownership is Maximizing value–Are you working on the most valuable thing next? You do this through experience and through feedback from users and stakeholders.

Feedback is crucial. To get frequent user feedback, you should be thinking about how you intend to deploy your software and then update it regularly. You should be thinking of this before or with your first story.

Deployment and ongoing updates should not be an after-thought.

Product Ownership is also about maximizing the work not done. The product should meet the needs and goals but only do what is necessary. There will be a point when the returns diminish. All work carries an opportunity cost, and at some point your time is more valuably spent elsewhere. Understanding this is vital.

Finally, I want to stress the importance of getting value to the customer quickly. Value is only realized when the software is used. We should be striving to getting the software in use as soon as possible. This may be in an unfinished state. It may be only a partial solution, but it should be adding value. e.g. it can be used alongside an existing product, or it could be used for this workflow but for another you use another tool etc.

Feedback from people actually using your software is the most valuable feedback you can get.

Just like prioritizing projects, prioritizing stories has far more impact on the success of the project than the following steps.

3 – Quality
(Build the Product Right)

Building the right product is more important than building it right. Building the wrong product is just a waste. But that doesn’t mean that quality is not important.

Quality means doing it right when no one is looking.

Henry Ford

When assessing cost of software, it is easy to focus on the initial development cost alone. But support maintenance and future enhancements all fall into the total lifetime cost of a product. The cost of defects magnifies over time, and the cost of supporting poor quality code is significantly higher and more risky. Re-learning and knowledge transfer are painful and costly to an organization and I can think of numerous examples where companies have been forced to abandon projects or replace software because they lost a key employee who had the knowledge locked in his head–or software so fragile no one dares touch it.

Good practices such as Test Driven Development, Pair Programming, Behaviour Driven Development and Automated Regression Testing may seem costly at first. But when considered in the context of lifetime cost, they are a sound investment. More importantly, they enable the right business decisions to be made because there is a confidence in the software.

Quality code with a solid set of tests enables refactoring and new features to be added with the knowledge you are not causing unintended consequences elsewhere by breaking older functionality. This reduction in risk is a considerable advantage, especially when supporting older applications.

This is not a carte blanche to gold plate or over-engineer. Quality Code is the right code for the story and No More. We write just enough to satisfy the story and we write it well. Over-engineering applies to the GUI too–we don’t add features or over-engineer.

4 – Efficiency and Improvement
(Building it Better and Faster)

By this point we should be working on the most valuable product to our company. With that taken care of, our next focus is to work on the most valuable feature or story for our users/customers. We should be doing it in a manner that enables us to be confident in the work and able to expand it later.

But guess what? You can do it better. We should reflect on the decisions we made and how we make them. Are we making the right decisions? What helped us make those decisions? Are we making the wrong decisions? If so what could we change to avoid repeating those mistakes.

The reflection and improvement should be done at all steps and should incorporate the learning from all stages. If we continually look for ways to improve we will get better and better.

If you always do what you always did, you’ll always get what you always got

Henry Ford

What about efficiency of developer effort?

So what of the original question about being more efficient with horizontal splitting of stories, or the perceived inefficiency of re-working the same area of code later?

It is a question of impact and perspective. In both cases the question is founded on ‘efficiency’ being a measure of the developer’s efforts. What I would like you to consider is that in terms of delivering value to your users and ultimately your company efficiency should not be measured in terms of developer effort, but should be measured in terms of delivered value.

Efficiency should not be measured in terms of expended effort, but should be measured in terms of delivered value.

The most valuable decision is to work on the right project – this dwarfs all other decisions by an order of magnitude. But it is at a different level of scope than this question.

The next most valuable decision is what to work on. This generally best considered from the perspective of delivering value to the customer quickly and of being able to respond to their changing and emerging needs.

When we split horizontally or when we do extra work, we know we will need later we may give the appearance of making more efficient use of developer effort, but in doing so we reduce our ability to adapt to changing needs and more significantly we delay the time to deliver the next most valuable feature.

This is an example of working with a waterfall mindset. The measure is that while it delays us this week, we will make back the time next month or next year. So if we are not planning to deliver this to our customer until next month or next year, it might appear to make sense. But you may not have considered two factors.

If we are deploying frequently, we are realizing value with every release and in the value of our software isn’t massively more than the cost of developer time to create it, then it is likely we shouldn’t be working this project at all. So ultimately the cost of developer effort for having to rework the same code later for a new feature is insignificant to the value gained by delivering sooner. We should measure ourselves based on value delivered not the effort to deliver it.

The second consideration is that the work you are doing on the assumption of needing it for a future feature may not actually be needed. That feature is by definition lower value and less important as it has been prioritized lower. There is a pretty reasonable chance that the customer may change their needs or there is the possibility of the project being cancelled or considered good enough as it is. That work may never actually be needed and you would have delayed the project for work that had no value. The efficiency you are trying to achieve may just be an illusion.

This is the business equivalent of spending $10 today to save $1 next year.

When considering efficiency and improvement, remember your goal is to maximize value to your customer and to realize that value as quickly as possible. Ask yourself if the efficiency improvement you are proposing fulfills those goals? If not it may be just be an illusion.

Weeks of coding can save hours of planning

In the context of Lean manufacturing there have been numerous studies that estimate that the proportion of value adding time in a production cycle is around 5%. The other 95% is deemed to be waste. These studies also conclude that by far the biggest waste is overproduction.

Anecdotally I think it is a very similar story in Software development although my fear is that the proportion of value adding time is even lower.

Waste takes many forms but broadly speaking effort as a team/company fall in to three areas:

1 . Valuable Effort – Value adding activities, these activities cost time and money, and there is a consequential opportunity cost but they add some value. However, the value may be able to be realized more effectively.

2. Obvious Waste – Non-value adding activities that are evident. These activities cost time and money (and opportunity cost) but add no value to the product being created. Examples are vacation, breaks, sickness.

3. Valueless Effort – Non-value adding activities masquerading as Valuable Effort, they cost time, money and have an opportunity cost but add no value to the product being delivered.

Waste Reduction is Not Your Goal

I will be covering the wastes in more detail but it is very important that waste reduction is NOT the focus of your efforts, Waste Identification is a supporting activity for the Theory of Constraints, any efforts to improve a part of your system that is not the bottleneck is a waste in itself. But identifying waste can aid in your efforts to improve your bottleneck so is a great tool to support your other activities.

The 7 deadly sins

Lean identifies 7 wastes (recently adding an 8th Waste)

Overproduction
Inventory
Tranportation
Over-Processing
Waiting
Motion
Defects
Wasted Potential of People

There is nothing so useless as doing efficiently that which should not be done at all.

Peter Drucker

Overproduction

Overproduction is considered the worst of the wastes and ultimately it is this particular waste that is the basis of much of the Agile Manifesto for Software Development. Which is why systems thinking is a topic I keep coming back to.

Agile is founded on the premise that at the start of the product we know the least and lack of flexibility is the biggest constraint in the success of software development. Traditional methods plan, create, test and support endless features that were unnecessary, the cost of this waste is unfathomable and big enough to trigger the Agile movement and challenge the way we work.

Overproduction was also the primary waste identified in the book “The Goal” by Eli Goldratt, and if you haven’t read that book I would heartily recommend it. The book is . great primer for the Theory of Constraints and for understanding Lean thinking.

Planning is Waste?

But Agile has not completely fixed this problem, and in my experience development teams regular and persistently develop unnecessary features. With many teams choosing to work without sufficient time spent planning; story writing; prioritizing; and without consideration for whether the work they are doing adds any value now or more significantly adds the most value next.

Road mapping, planning and even story writing are often incorrectly perceived as ‘waste’ and the avoidance of waste is used as a justification to get back to coding on something that is likely not valuable and almost certainly not the most valuable activity to be worked on next, which is a far more insidious waste than the planning ever could be .

Features “not needed yet” are implemented on the basis that it will save time later, or features are added because “We know we will need it later” – (7 words I dread to hear.)

We work to look or feel busy, in our minds we translate activity as being productivity when there is little correlation between the two in the context of software development. In software, creativity; problem solving and planning are far more valuable efforts than unfocused coding.

Give me six hours to chop down a tree and I will spend the first four sharpening the axe.

Abraham Lincoln

In most cases features have no value until they are in the hands of a user and being used for productive effort. So any activity not spent getting the next most valuable feature into the hands of a user quickly is just waste.

Writing extra features that are not used or rarely used extends the production time but brings little or no value, it also compounds all of the other wastes because by it’s nature production of something of little value needs to go through the system thus exposing an unnecessary feature to all the other wastes.

When you next start work on something ask yourself: “Is this the next most valuable activity for our customer?” If you cannot confidently answer that question then maybe you need to spend more time planning so you can spend less time coding something that is not needed.

The worst case scenario

In software the biggest risk to any project is that it will be cancelled or obsolete prior to being used by your customers. This may sound obvious but if a project is cancelled ALL of the features are/were waste. All that effort produced no value for anyone. That time, effort and money could have been spent elsewhere. So getting your product right is only any good if you get your product delivered.

Delivering value to your customer quickly is the best way to mitigate the risk of your efforts being wasted, and Done is not really done unless it is in the hands of a customer and actually being used for a productive purpose.

Overproduction is a big topic and deserves a little extra focus so I’ll delve deeper into the other wastes another time.

Is culture observation or aspiration?

There has been a lot of talk recently about culture and it’s importance when creating organisational identity, but there are two ways I see for an organisation to create a culture.

A short story…

I was once told a story of how the British and US army engineers take two different approaches to footpath planning when creating their bases.

The British planned in advance and they laid the footpaths to a defined route and the soldiers were required to follow the specified paths, and were corrected if they didn’t.

The US engineers on the otherhand would delay laying the footpaths until the base was in use, they would observe the routes taken and where the soldiers walked and would lay the paths when the preferred routes were clear.

The belief (or so I was told) was that people will find the most efficient route on their own.

Each has it’s own merits, and is itself likely a reflection of the culture of those two organisations.

A deliberate culture or a reflective culture

I see this as being very similar to a company’s culture. You have two main choices: either you decide the culture you want, you lay it out and then make decisions that reinforce the path you set. This means hiring practices, rewards, punishments, recognition, and everything in between, you continue to do this until the normal behaviour is to follow the path set. Your culture is by your design. But to get the culture you want requires a lot of correcting of behaviour until it happens.

Or the alternative is to wait and see, behave the way you behave naturally and the same for the others around you, soon enough a culture will form and it will be a culture that reflects the way you behave. The good news is this is your real culture, the bad news is – this is your real culture.

There are problems with both of these, choosing a deliberate culture that goes against some of your natural tendencies or is unrealistic can lead to it not being followed and the result is that you claim one culture but actually have another, this can be very damaging especially to those that believe in the defined culture. If you follow the rules but others get ahead by other means it can be corrosive. A lack of defined culture can also bad as there is no safety check on poor behaviour, left unchecked it quickly becomes the norm and then it becomes your culture, which is the case for women in IT.

Women in Tech

One great example could be seen with Women in Tech, where most companies would say their culture does not set out to exclude or marginalise women, but without a deliberate culture to seek out diversity we have allowed the lack of diversity to become the normal state and for the culture to be one that unintentionally discouraged or excluded women. Often evolving from small companies that have grown by surounding themselves with like minded individuals. Unconsciously biased towards those similar to them. It will take time and effort and a deliberate culture to break through some of those barriers we have created over the years.

But this is seen in all aspects of an organisation, if your culture tolerates something for long enough, maybe because it is easy to ignore when small, it can become a much larger issue when you grow. If you are not explicit about the culture you want then you may not be able to shape the culture you have. In larger organisations sub-cultures can form in different areas and this can be even more damaging, without a clear global culture factions develop and the inconsistencies undermine the larger whole.

Agile Transformation

One of the reasons that Agile Transformation is so hard is because it is a culture change rather than a process change, you are defining a new culture and that will not happen overnight. All the previous actions that were normal, the rewards, the metrics the measurements are very hard to undo. Empowering people to be self-organising when they have only known command and control will take a while to adjust. I believe this is why so many agile transformations are unsuccessful, some processes are changed but there is no desire or will to change the culture, there is a general wish to change to Agile without actually changing.

The solution

The solution in my opinion is to do a little of both. Be aware of the culture you want and be explicit about it, shout it from the rooftops, and repeat it and repeat it and repeat it, until everyone in your organisation knows you mean it and you believe in it, be clear where you aspire to be. This will still take a very long time to have impact.

But also be aware of where you are now, the unwritten culture you have now is just as strong and just as real. Be especially aware of the behaviours that your culture currently has that you are not happy about. If you are honest about your weaknesses and failings you have a far better chance of changing. Seek out and coach those that are not behaving the way you aspire to be, remember they behave that way because it is your culture.

Culture change wont happen overnight but that doesn’t mean you shouldn’t be intollerent of any behaviours that don’t reflect the culture you want.

Project Management Mistakes

I found an interesting link discussing common Project Management problems and suggested solutions, and I found myself questioning the advice given…

http://www.cio.com/article/2391872/project-management/12-common-project-management-mistakes–and-how-to-avoid-them.html

So many projects, so much mismanagement. That’s the refrain of many IT executives. Indeed, even with project management software, IT projects often wind up taking longer (much longer) than planned and costing more than budgeted.

I have previously covered the issue of how many failed projects there actually are, the proportions are really quite frightening: Most projects will fail by conventional measures, they will go over budget, be late or the scope will change, even with ‘good’ planning and contingency. So an assessment of “why?” is a great idea, but many companies are still stuck in a rut of doing the same thing and expecting different results.

The Survey in the link above and the proposed solutions is nice to see, but to me it felt as if the respondents were trying to solve problems by doing the same things that have failed previously – only suggesting that if they had done it ‘better’ it would be different, rather than considering that maybe the process that was at fault? I wondered how applying an Agile perspective might offer different solutions to try.

I do not intend to be (too) critical of the original responses, they were clearly made by experts in their field and may very well be the right answer, but I have taken each issue – all of which are common project management issues, and I have applied an Agile head when offering a solution.

I don’t claim my solutions are right or better, but they may offer a slightly different perspective on persistent problems. And reflect how I would advise the problems should be resolved.

Project Management Mistake No. 1: Not Assigning the Right Person to Manage the Project.

Typically during resource allocation, most of the effort is focused on finding the right resources rather than finding the right project manager. Indeed, too often project managers get picked based on availability, not necessarily on skill set. However, an inadequately trained and/or inexperienced project manager can doom a project.

Traditional PM Solution:

Choose a project manager whose skill set(s) match the project requirements.

Agile solution:

1) Ask whether the project even needs a Project Manager, it may be that the content and scope could be ‘owned’ by a single ‘Product Owner’ When it comes to a project that involves integrating many independent components from different sources and there isn’t a clear hierarchy or dependency then a Project Manager may make sense, but where the project is delivery of a product increment, or there is a clear hierarchy and dependencies it is not clear to me what value if any that a PM adds, it becomes an extra layer of bureaucracy but no added value.

2) However the traditional answer applies in an Agile environment. Finding a Product Owner that has the right knowledge and skill set is vital, as is empower them appropriately. Finally have them focused entirely on this one and only product. Multi-tasking will generally lead to problems with one or both projects.

Project Management Mistake No. 2: Failing to Get Everyone on the Team Behind the Project.

Too often, projects are doomed to fail because they didn’t get enough support from the departments and people affected by and involved in the project. Either managers: 1) Didn’t make clear what everyone’s role was. 2) Didn’t describe the personal payoff everyone would get when the project was completed successfully. 3) Didn’t tell how each person’s contributions to the project would be evaluated. And/or 4) Failed to generate a sense of urgency about the project, leading the team to think business as usual will be fine.

Traditional PM Solution:

The project manager should start by calling the team together (being certain to include off-site staff via the best technology available) and delivering a presentation about the project and its significance in a way that gets everybody fired up.

Agile solution:

1) The Product owner should share the vision with the team, show how their part fits in with the big picture. The vision is crucial and should be clear to everyone. (just as above)

2) Where possible have team members dedicated to the project, this immediately builds ownership and commitment, have them co-located with colleagues and build a team. Motivation to team mates is more effective, more consistent and has greater longevity than that which can be created to a project.

3) Have the team involved in setting goals and expectations; the more involved they are the more they will buy-in to the project. Give them ownership of the design and the level of quality, a self-set target is more meaningful than an imposed one.

4) Discussing Personal payoff is not helpful, we are trying to build a team, in software projects like any cognitive task both carrot and stick are counter product and can be demonstrated to reduce productivity. It is far better to build a good team and share a vision, a well-motivated team does not need a sense of payoff, successful delivery of a product is motivation enough. A shared purpose and shared success.

5) Again a sense of urgency is not a helpful tool for motivating software teams, ‘Urgency’ should be reflected in prioritization not pressure or deadlines. An appropriately motivated team should work at a sustainable pace. Let’s talk in terms of priority: Urgency is a reflection of poor management and poor planning, projecting that failure on to the team is in my opinion a sign of failure of management.

One final note – “Failed to generate a sense of urgency about the project, leading the team to think business as usual will be fine” I find this to be a very bizarre comment, in my opinion “Business as Usual” is fine, in fact business as usual is great. If I have a team that works at a sustainable and predictable pace that is the holy grail for a project manager, or it should be. A known quantity, and one that can run and run and run like the Duracell bunny is what any project manager should desire.

Why would anyone thing that driving a team into the ground to meet an urgent deadline, followed by a crash of exhaustion, staff potentially off with stress, or quitting, or any of the other consequences of deliberately overworking and pressuring staff is actually a good thing?

Whilst meeting an unrealistic deadline set by someone outside of the team may well be the priority of a PM, it is naïve to assume you can move teams from one project to the next without a break always expecting them to work with a sense of urgency. It would be far better to think of the team as a machine that takes a while to get up to speed, whilst you may be able to stress the engine and push it to the limit, to do so regularly or for prolonged periods will cause damage. Whereas a good engine run at a sustainable pace can run for far longer.

Ultimately, It comes down to a question of respect. If you treat your team right, they will work well for far longer and be far more productive in the long-term.

Project Management Mistake No. 3: Not Getting Executive Buy-in.

Traditional PM Solution:

Somebody at the higher levels of the organization needs to own the project from start to finish and be personally vested in its success, When a project has no clear head, things tend to fall apart.

Agile solution:

1) A single Product owner should be empowered, and personally vested in the success and assigned exclusively for the duration. If the Product Owner cannot be sufficiently empowered to achieve success, then your organization has more serious issues.

2) Not all projects need a senior sponsor, but they do need support appropriate to the project.

3) Senior sponsorship for the way you work is vital – By which I mean Framework – in this case Agile. The organisation needs to be behind the delivery method. If the project is necessary then the project leader needs to have the backing of the company to get it done. Any block to agile delivery needs to be aggressively unblocked and sometimes this required uncomfortable change in attitudes, and that will require senior sponsorship.

Project Management Mistake No. 4: Putting Too Many Projects into Production at Once.

Most managers think that they can get more done by starting all projects at once, but in reality, it’s counterproductive. Multitasking slows people down, hurts quality and, worst of all, the delays caused by multitasking cascade and multiply through the organization as people further down the line wait for others to finish prerequisite tasks.

Traditional PM Solution:

To stop these productivity losses, a good first step is to reduce work in progress (WIP) by 25-50 percent. This reduces the back and forth and makes managers and experts more responsive in dealing with issues and questions. Though counter-intuitive, reducing the number of open projects by 25-50 percent can double task completion rates.

Agile solution:

The same as above: reduce WIP, far too often we resort to claiming credit for starting work, or for claiming it is in progress. The only metric that matters is completed work. If limiting the number of projects on the go, results in more projects being completed then what are you waiting for?

I’d like to write more on this topic, I feel this is so crucial to success, the number of times teams are held up because of competing demands on networks teams, DBAs or deployment pipelines or any number of other critical resources. The impact of these are often unmeasured, but simply reducing the number of concurrent projects relieves the context switching and demand on these resources. Which is an immediate easy win.

But more that if you can deliver 4 projects in 12 months, why not deliver 2 of them in 6 months, and then 2 in the following 6 months. That is two projects delivered 6 months early without any additional work and without delaying anything, you may even find they get done quicker.

Project Management Mistake No. 5: Lack of (Regular) Communication/Meetings.

Communication is the most important factor of successful project management. Without regularly and clearly communicating, the project will fall apart.

Traditional PM Solution:

Pick a day and time to meet each week (either virtually or in person) that works for the team (not just the project manager) — and stick with it. Having specific days and times scheduled, in advance, helps to keep everyone on the same page and keeps the project flowing.

Agile solution:

Meet daily, co-locate the team to reduce further any delay in communication. Use information radiators (Whiteboards to the rest of us) to prominently display useful and pertinent information. If the information is useful you need it now, if you can wait a week for it, it probably isn’t that important.

Communication in Agile is crucial, anything that can be done to reduce the barriers to communication should be considered a priority, getting team members and those peripheral to the team communicating effectively is vital. Co-locate where possible, a daily stand-up is a scheduled opportunity to get together and share, but for anything critical even a daily meet up is not quick enough. But communication should be useful, timely and concise.

Project Management Mistake No. 6: Not Being Specific Enough with the Scope/Allowing the Scope to Frequently Change.

Any project that doesn’t have an ultra-clear goal is doomed, scope change is one of the most dangerous things that can happen to your project. If not handled properly it can lead to cost and time overrun. Even something small, like changing the color of a logo or adding a page to a website might cause unexpected delays.

Traditional PM Solution:

Define the scope of your project from the outset and monitor the project regularly to make sure you and your team are keeping within the scope. And to avoid delays and deviation from the original scope, track change requests separately from the original project scope, and provide estimates on how it will affect the schedule and get explicit customer/stakeholder approval for each change.

Agile solution:

“Even something small like changing the color of a logo might cause unexpected delays” Wow! And the solution is to “Avoid delays and deviation from original scope” Wow!

I am utterly stunned by this problem and the response. First everyone involved in a project does or should understand that Change causes delays, any client that expects to be able to change a Logo or add a page without a consequential delay, is extraordinarily naïve or is being misled. Very simply work takes time, sometimes even removing work takes time. A product Owner or PM should be able to candidly discuss this with the client, if the client is asking for change they should be made aware of the impact and that information should help shape their decision. If you cannot have this conversation then there is insufficient trust between you and the client, and rigorously enforcing terms of the original contract is not going to promote trust.

In my opinion the response is shocking, just who is the Client here? If the client has changed their Logo, then who would consider it sensible to plough on with a solution that is wrong? Refusing to accept change is not working for your customer, it is self-serving and ultimately futile. This stubborn refusal to accept change is the primary reason Agile has been the huge success it has, because the customer is respected. In Waterfall the goal is to conform to a contract, in Agile the goal is to give the customer what they want. The difference between the two is a happy customer and an irritated customer seeking a new supplier.

Example: If we consider an extension to a house, upfront I may have architectural drawings, and building plans, and I may get a builders quote based on those plans. But as the build progresses I decide that I’d like to change the position of a window or I change my mind about the type of tiles, or kitchen units. As the customer that is my prerogative.

Situation A: Builder says, “No! that is not what we agreed, you must stick with the plan and keep the materials you specified. If you want to change this, you must wait until we are done, then rip out the work and redo it later.”

Situation B: Builder says, “Yes! But it is not what our estimate was based on, changing the plan and materials may increase the cost, and may take a little longer. So long as you are comfortable with the impact we are able to accommodate your requests.”

And Just for fun – and this generally doesn’t work so well for building work where planning permission is needed upfront but still…

Situation C: Builder says, “Let’s build the initial framework and you can defer making the decisions about the layout and internal fixtures until later, when you are better able to envision the situation.

Project Management Mistake No. 7: Providing Aggressive/Overly Optimistic Timelines.

The intentions are noble, as project managers are often trying to keep their clients happy. But missing deadline after deadline will only lead to distrust and aggravation on the part of your client.

Traditional PM Solution:

Good project management software will allow you to manage many work items and the bandwidth of available resources. However, it’s still important to add a buffer providing some extra time and money to your project, especially in the world of technology.

Agile Solution:

The proposal of Better software, and more micromanagement and adding contingency to counter optimistic timelines, is the opposite of good agile practices. Once again I completely disagree with the proposed solution.

Solution 1) If the timelines are unrealistic this should be addressed, the team (dev or management team, or customers) should assess why they are coming up with unrealistic estimates, and modify behaviour accordingly. Discuss why a timeline is needed, and plan accordingly. If we must meet a specific date then we plan the solution accordingly, if we must keep to a certain budget, we can plan the solution accordingly, but an estimate is not the same as a deadline. See blog post…

Solution 2) Rather than adding buffers and contingency, how about prioritizing content and being flexible with the scope to meet a timeline if the timeline is critical, or being flexible with the time. It is a controversial comment but I find the routine practice of PMs padding estimates or surreptitiously adding contingency is counterproductive, it causes mistrust, and is ultimately futile as management will react by demanding earlier delivery believing that estimates are padded. I’d much prefer to be open an honest, and build trust, I keep management informed of progress and allow them to make decisions on true and upto date information.

Solution 3) Fancy software doesn’t help. The more you micromanage the less productive the team becomes. For a former software developer and general technophile, when it comes to project management I’d actually prefer to have no software tool at all. A Kanban board and a backlog of stories on Index cards is actually very powerful, software has value in some circumstances but most of the time the simple approach is sufficient and clear to everyone involved.

Project Management Mistake No. 8:

Not Being Flexible. While you may think of your project plan as your bible, telling you what needs to be done, by whom, and when to do it to get to your goal. Don’t hesitate to listen to new information and suggestions that come up along the way.

Traditional PM Solution:

It’s good at various intervals to step back and take a fresh look at the overall project, review how things have gone so far, and how you can improve your future work based on what’s already changed along the way. That doesn’t mean you should or need to constantly make changes, just be open to suggestions if they help the project.

Agile response:

Schedule regular retrospectives, make the act of trying to improve a regular part of your job. Actively look for ways to improve, a passive ‘being open to change’ is not enough. We need to seek to improve and have a willingness to continually find even small ways to grow. Many small improvements can lead to significant benefits.

Project Management Mistake No. 9: Not Having a System in Place for Approving and Tracking Changes.

Often, success or failure of a project hinges on the changes that occur after it begins. However, all too often, there is no system in place for approving and tracking changes.

Traditional PM Solution:

Having a clear process that must be followed is the best way to ensure the pertinent details: how much it will cost, why it is necessary, the impact on the overall project etc., are known before the change is approved. It’s also extremely effective for auditing performance during and after project completion.”

Agile solution:

Change is a part of software development, no amount of planning can ever reveal everything, there will be change, so plan for it from the outset. Prioritise work rather than plan in detail, allow for priorities to change and expect them to change. Allow for new work to emerge, and consider and plan for the possibility of failure. As with the traditional PM approach, why; cost and impact need to be considered, but these are a factor of priority. Any heavy weight review process is unnecessary.

Failure is deemed bad in all circumstances, but that is not the case, to fail early may actually save significant costs compared to failing later. This should he heralded a success, but too often all failure is considered bad. Failure can lead to successes later. Not learning from failure or continuing along a failing path is the real waste. But too often any failure is not tolerated and this can be very damaging.

Project Management Mistake No. 10: Micromanaging Projects.

Don’t babysit, It’s very common for budding project managers to treat their job like an enforcer, policing the project team for progress and updates.

Traditional PM Solution:

Instead of babysitting the project team, let it be known from the start [i.e., the kick-off meeting] that there will be regularly scheduled updates for the duration of the project. This lets your team know that status updates and progress are expected from them weekly and will encourage them to vocalize any issues or delays in advance.

Agile Solution:

Don’t allow the Project Manager or Product Owner to micro-manage, it is the job of the Scrum Master to coach the team to manage themselves and then the SM is to run protection – keeping the wolves at bay. PMs micromanaging is rarely beneficial and is generally damaging. The saying goes that you should hire the right people to do the job, and once you have hired them, trust them to do the job right. If you have hired the wrong person no amount of micromanaging will help, and if you have the hired the right person micromanaging will only hurt.

Project Management Mistake No. 11: Expecting Software to Solve All Your Project Management Issues.

I’ve seen people throw software at problems all too often, and though projects become enumerated and more visible, the underlying process is still broken,” “What you end up with in that case is a potentially costly piece of software only serving as a checklist of projects in motion without any thought given to advancing each project/milestone effectively.

Traditional PM Solution:

Choose project management software wisely — something all members of the team will be comfortable using. Then make sure to train users properly and set up a system for tracking projects. Above all, don’t let human capital be “overshadowed by the allure of software solutions’!”

Agile Solution:

Fancy software doesn’t help. The more you micromanage the less productive the team becomes. When it comes to software project management I’d actually prefer to have no software tool at all. A Kanban board and a backlog of stories on Index cards is actually very powerful, software has value in some circumstances but most of the time the simple approach is sufficient and clear to everyone involved. Naturally many projects involve more than a single stream of software and in that case a software tool may be useful, so long as it doesn’t interfere with the software development streams.

If we limit scope to be a software development stream, then simple metrics on backlog, cumulative flow and perhaps velocity should be more than enough to check progress towards milestones. But in this case the Product Owner is the best source for the health of a software project.

Project Management Mistake No. 12: Not Having a Metric for Defining Success.

Traditional PM Solution:

The very first thing a project manager should do is ensure he understands what the end users will consider a successful completion to the project,” Understanding what will make a project successful…ensures that when the project is completed [all] parties walk away satisfied.

Agile Solution:

Very similar, a clear Vision for the project is key, but a vision is not a set of requirements it is a concept. Ensure that the Product Owner and the team understand the vision and any intermediate milestones. But the goal is satisfaction of the customer, that is the only metric that matters. Ongoing conversation to ensure they are satisfied with the progress is essential, regular reviews and conversations to ensure your solution is meeting their needs. This is not an exercise in checking off items on a contract, it is about delivering the right solution to the customer.

Summary

It surprised me how different an agile approach is, I had expected far more overlap, after all Project Management is as old as the hills. Some solutions are common to both approaches but even then the approach whilst similar seemed to have a different goal.

But what struck me most was how Traditional solutions fell back to a desire for more control: control the scope, control the team, and control the customer. Whereas Agile was about building a team, responding to the customer and guiding not controlling the delivery. The perception of control is such a fallacy when dealing with a customers evolving needs and the unknowns of software development.

A quick Star Wars quote to finish:

“The more you tighten your grip, Tarkin, the more star systems will slip through your fingers.”

Could it be as simple as that? As a Project Manager it seems that the more control you try to exert, the less real control you have on the delivery, but by accepting a little Agility:- whilst it may seem to be relinquishing control you are actually far better able to steer the project.

There is nothing more deceptive than an obvious fact. ― Arthur Conan Doyle

And it is this simple:

Work on the thing that adds the most value and stop working on things that don’t add value.

What is Value?

Two Problems

Example

Why be a coach?

A good PO these days is hard to find…

1: Differentiating what is needed from what is wanted

2: Understanding what is required to create a successful application

3: Communicating effectively with both technical and business stakeholders

Summary

Measuring Capitalism

TL:DR Summary:

What has this to do with Agile?

Governance

Let’s change the way we write stories

Tell me how you measure me and I’ll tell you how I will behave.

Eli Goldratt

Hypothesis rather than Story

The best architectures, requirements, and designs emerge from self-organizing teams.

Already happening?

Measurements for Goals as the basis for Story Mapping

Make it measurable

The primary goal is to Maximize Value Early

The 4 Steps

1 – Prioritization (Selecting Which Project/Product to Build Next?)

2 – Direction (Product Ownership – Building the right Product)

Deployment and ongoing updates should not be an after-thought.

Feedback from people actually using your software is the most valuable feedback you can get.

3 – Quality (Build the Product Right)

Quality means doing it right when no one is looking.

Henry Ford

4 – Efficiency and Improvement (Building it Better and Faster)

If you always do what you always did, you’ll always get what you always got

Henry Ford

What about efficiency of developer effort?

Waste Reduction is Not Your Goal

The 7 deadly sins

There is nothing so useless as doing efficiently that which should not be done at all.

Peter Drucker

Overproduction

Planning is Waste?

Give me six hours to chop down a tree and I will spend the first four sharpening the axe.

Abraham Lincoln

The worst case scenario

A short story…

A deliberate culture or a reflective culture

Women in Tech

Agile Transformation

The solution

Project Management Mistake No. 1: Not Assigning the Right Person to Manage the Project.

Traditional PM Solution:

Agile solution:

Project Management Mistake No. 2: Failing to Get Everyone on the Team Behind the Project.

Traditional PM Solution:

Agile solution:

Project Management Mistake No. 3: Not Getting Executive Buy-in.

Traditional PM Solution:

Agile solution:

Project Management Mistake No. 4: Putting Too Many Projects into Production at Once.

Traditional PM Solution:

Agile solution:

Project Management Mistake No. 5: Lack of (Regular) Communication/Meetings.

Traditional PM Solution:

Agile solution:

Project Management Mistake No. 6: Not Being Specific Enough with the Scope/Allowing the Scope to Frequently Change.

Traditional PM Solution:

Agile solution:

Project Management Mistake No. 7: Providing Aggressive/Overly Optimistic Timelines.

Traditional PM Solution:

Agile Solution:

Project Management Mistake No. 8:

Traditional PM Solution:

Agile response:

Project Management Mistake No. 9: Not Having a System in Place for Approving and Tracking Changes.

Traditional PM Solution:

Agile solution:

Project Management Mistake No. 10: Micromanaging Projects.

Traditional PM Solution:

There is nothing more deceptive than an obvious fact.
― Arthur Conan Doyle

The best architectures, requirements, and designs
emerge from self-organizing teams.

1 – Prioritization
(Selecting Which Project/Product to Build Next?)

2 – Direction
(Product Ownership – Building the right Product)

3 – Quality
(Build the Product Right)

4 – Efficiency and Improvement
(Building it Better and Faster)