Transforming from Projects to Products

There is an old saying - An Agile Transformation is easy, you only have to change two things: Everything you say, and everything you do.

But actually, as obvious as that joke was, it is also wrong. You only need to change one thing, you need to change the way you think.

Project or Product

It is my premise that when we talk about Agile Transformation what we mean is transforming our thinking from considering our deliveries in terms of 'Projects' to thinking in terms of 'Products'. And transforming from measuring people in terms of their effort, to measuring them in terms of their collective contribution to a shared goal (the value they add).

Project: an individual or collaborative enterprise that is carefully planned and designed to achieve a particular aim.

Product: an article that is created or refined to satisfy a need.

As we have all discovered, software product development is complex, both in the development itself where we face a host of unpredictable variables, complications and unknowns. But, more significantly, it is very difficult to know what you want until you see it and consequently there are an abundance of quality software products that do not effectively fulfil the need that triggered their commission.

We have learned that reviewing progress regularly with stakeholders and modifying based on that feedback is far more likely to result in a successful product.

In most cases it is a fallacy to believe that for a complex and bespoke software solution you can know your end state before you begin, regardless of how well you analyse. And no matter how good at planning you are if you don't know the end state your plan is flawed, and as you cannot predict the unknown even the best plans are unreliable.

We have come to realise that bespoke software delivery is far more akin to product design and development than it is to project delivery.

Management is doing things right; leadership is doing the right things. - Peter Drucker.

Agile Transformation is about moving from Management to Leadership

Peter Drucker is an inspiration here, traditionally we put so much effort into getting things right, to be more efficient, or to do this, by that deadline, that we forgot to ask if what we are  doing is bringing value. We put all our emphasis on measuring and monitoring effort, or efficiency, rather than assessing if we are achieving our goal.

If you are considering an Agile Transformation it is likely that you have discovered that efforts to 'manage' projects are leading to the wrong results and the focus needs to move from a focus on effort to a focus on value. To set a direction and 'lead' the way in product development.  Try to stop measuring output and to start measuring outcomes.

Impact on Project Managers and Business Analysts

But this is a major cultural change for many companies and not an easy one. It is a complete shift in perspective, moving from planning the delivery of a project to collaborating on the creation of a product.

It is particularly difficult for Project Managers.

For project management to be effective the end state needs to be [largely] known, and for the steps to get there to be familiar and [largely] predictable. With a known end state and predictable building steps, a Project Manager can effectively work towards that aim.

But bespoke software is far more complex and is generally dealing with many unpredictable variables, the biggest variable being the end state. In the majority of cases the end state is not known at the outset and emerges in the course of the product being developed. The true end state needed to fulfil a need or want can very often be significantly larger or smaller than initially anticipated.  The ability and flexibility to pivot based on emerging information is crucial for delivering value and the product being a success.

Project Managers, often find the transition to an Agile mindset the hardest as it is their role that is arguably impacted the most and ultimately needed the least. So many of the traditional measurements are turned on their head when dealing with software.  Once you can let go of the assumption that bespoke software is predictable and repeatable. When you are able to consider each project/product to be unique and undefined then it gets easier and there may be a place for some amount of project management in software. But even then it is not about managing the product so much as reporting, and managing expectations of customers and stakeholders.

Business Analysts similarly must adapt, project planning generally relies on knowing as much as possible at the time of planning, and so there is heavy reliance on the Business Analyst. Product Development is again a mindshift for a Business Analyst, there is no longer a need for detail up front, in fact in most cases it is a waste due to the likely and frequent change of direction and priority as we learn so much as the product emerges.

Business analysis in agile software product development means that an early assessment generally at a high level is all that is needed, with detailed analysis happening much closer to when the work is done, at this point much more is known about what is actually needed and so we are not wasting time analysing something that will not be done.

Transition for Business Analysts is easier, their role doesn’t change drastically it is more the timing, the conversations with the customers are closer to when the work will be done and BAs often make very good Product Owners as they share a focus on identifying what the customer needs.

An Agile Mindset

Agile is a mindset far more than anything else, and when you start to look into it, there is nothing new, nothing original, and you will be surprised to find that whilst the word Agile has been used a lot by the software industry in the last 20 years or so, the practices and behaviours are just the good practices and behaviours of general management going back a century and possibly even a millennium or two.

'Agile' as we have come to know it whether we mean Scrum, Kanban, Lean, Lean Start-up, or any of the many other Agile frameworks is, in most cases a collection of historic good practices and guidelines identified by successful leaders and businesses in the past, they have been collected under one umbrella polished up a bit and marketed - very successfully - which is likely why you are reading this.  I say this to discourage the notion that 'Agile' is new and untested, there are certainly some misinterpretations and misapplications but the underlying principles are sound and based on a lot of experience.

Just as an observation, if you looked back at the early days of the Ford motor company as an example from over 100 years ago, and you assessed them against modern standards of agile my guess is that they would hold up very well.

Agile Transformation should not be your objective

Agile Transformation is often presented as the objective, when in reality it should be a strategy to reach a goal. Taking some time understanding what your goal really is, will make any transformation far more likely to succeed.

• Are your customers dissatisfied?
• Are your products missing the mark?
• Do you(or your clients) feel you are not getting value for money?
• Are you slow to market?
• If you are creating software products for internal teams are they not having the impact you expected?
• Are people circumventing your tools?
• Is your ROI on software development too low?
• Are you losing key development staff?
• Is there a lack of transparency in the software development process.

These are just a few of the many reasons a company may want to undergo an Agile Transformation, they are all global business issues, and that is a key point: Agile Transformation is not an initiative just of the software department, it is a change for the entire business. It is a major cultural change that will impact your business from top to bottom. From the way you sell your products, to the way you hire staff, and particularly to the way you measure success.

Agile Transformation is a major cultural change that will impact your business from top to bottom. From the way you sell your products, to the way you hire staff, and particularly to the way you measure success.

Traditional Change Management

An Agile transformation is just a form of traditional change management, 'Agile' is a cultural change far more than a process change. Because of that it also doesn't need to be limited to the software industry. If you have a genuine desire to improve your company and are willing to take the steps to create a culture that embraces change and continual improvement then you have taken the first and most important step.  But this is also the step where most companies flounder.

If you are changing to Agile because you have heard it brings good results and so want to change your processes but are unwilling to change your culture, you will likely struggle.

If you continue to measure your teams the same way you always have then you will get the same behaviours and the same results - likely the ones you are trying to change.

How do you measure?

The level of Agility you can achieve is determined by the behaviours you choose to reward or punish

Most small companies start out pretty agile, they have to, just to survive, failure and learning, adapting, evolving and reflecting are essential. We often find that the successful start-ups will describe how learning more quickly about failures helped them, and how they are all working to a common goal. But as companies become more established they "grow-up" they organise and divide responsibilities and failure goes from being a good thing to a bad thing. Goals shift from being shared goals to individual department goals and lack traceability back to company goals.

The department has goals that they are measured against, the team has goals, individuals have goals.  I am not saying goals are a bad thing, but goals that cannot be directly tied back to a common goal of the organisation are a bad thing, they create conflicting behaviour and activities that do not take you towards your goal very likely keep you from it.

Take a moment to think how often in your organisation you have needed something to help meet a company goal - deliver a product, or hire more staff, but you were dependent on another team or person, and that team couldn't or wouldn't help. IT support (sorry for picking on you) is often a good example, a simple firewall change to launch a product which takes weeks to be scheduled or new PC that doesn't show up until a week after a new hire started.

These frustrations cause us to work around them: there is a headcount freeze/limit so instead you 'temporarily' hire more expensive contractors to fulfil a need and meet your department's goals.  Frustrating though these situations are, they result from a department goals not being aligned with company goals. Or they are misinterpreted and result in departments competing or not cooperating.

If the company made it clear that this product launch was No 1 priority then IT support would know where to put their efforts. If cost-cutting or limiting headcount was a goal then circumventing it is not acting towards a common goal. Similarly the recruitment freeze may be hindering the true goal which is profitability.

Biggest Hurdles

People behave the way they are measured and in the case of an Agile Transformation the biggest hurdle tends to be Project Management and People management and it is precisely because Agile changes the way we measure project success and how we measure people's behaviour.

Tell me how you measure me, and I will tell you how I will behave. - Dr. Eli Goldratt

Project Managers are routinely measured by whether their project is on track: Each week they report on their status:

Is it on track, on budget, on time, in scope?

As a result they put all of their efforts into keeping the project in budget; on time; and within scope.  What is wrong with that? I hear you ask.  The PMs are doing what is expected, and so they are rewarded for this.

The problem though is that keeping projects 'on track' should not be a company goal. As mentioned earlier, software products rarely know the end state, so managing towards an end state is not viable. The goal needs to shift, to be about satisfying a need and an acceptance that you cannot measure against an unknown end state.

Delivering the right product (profitably) and keeping the customer happy, should be your goal, and rarely, if ever, is the initial project plan one which will achieve that goal. So focusing on doing the wrong thing right, is not helping you towards your goal.

[Project] Management is building things right; [Product] leadership is building the right things.

(shamelessly paraphrasing Peter Drucker)

Traditional Project Management when applied to a complex software product is the art of doing the [wrong] things right (on time, in budget, and to scope).  Agile Product Leadership is about accepting the plan is likely wrong or at the very least unclear and the scope is unknown, and so adapting to change and building the right things to fulfil our customers’ needs.

Project Managers should become leaders rewarded for adjusting and adapting the project plan to remain in alignment with the goal, the changing requirements and emergent events. Far more often they do their best to force the emergent events and reality to align with their plan, thus 'managing' the project to the wrong aim.

In other words they act the way you measure them.  In your next project status meeting think about what you are asking: are you asking your PMs to display an awareness of the customer and the reality of the situation and show they are responding to change, or are you rewarding them for telling you that the project is green and has no problems?

Having no problems is the biggest problem of all. - Taiichi Ohno

Measuring Value or Effort

Valuing effort more than value can happen at all levels and is just as harmful at the individual level. If in a daily stand-up you ask "what did you achieve today?” there is an implied pressure to show you have been busy, inevitably people will seek out things to do. Measuring utilisation should not be a goal, customer satisfaction, delivering value for money, creating growth and new opportunities likely being far higher value goals.

Try changing the daily stand-up to be "how did I help the team towards their goal?” this is a significantly different question and will not result in encouraging unnecessary work being done to give the illusion of being busy. It will encourage the team to seek out work that gives value, rather than busy work. Reward people that help with team goals and hold people accountable for work (regardless of how useful or efficient it appears) that does not help towards the team goal.

Changing your stand up from:
"What will I do today?" to "What can I do to help the team towards our goal today?"
can make a huge difference to behaviour.

 Agile Practices and Principles

You will notice that I have talked a lot about organisational change in general, and how what you measure essentially determines your company's culture. But I have hardly mentioned Agile Practices and Principles, and this is deliberate.  If your organisation understands the need for a cultural change to focus on the true company goals and your culture reflects that. If you learn to measure and reward success based on contribution to company goals rather than focusing on local optimization,  then adoption of Agile is easy (or easier - as old habits die hard) nearly all Agile frameworks conform to the notion of supporting system-level thinking, and thrive in this type of culture.

But if Agile does not become part of your culture, then your transformation will get stuck with new practices being measured against old yardsticks and what you will end up with is not Agile and likely not better than where you were. Cultural change is hard but worth it.

An Agile Culture

This is where I think the agile movement has done itself a disservice, what we are aiming for is a cultural change to improve your organisation and to use the best practices and tools to reach your company's goals. If we accept that this is just good business sense and remove the term Agile Transformation we may have a better understanding of the significance of initiating a cultural change in your organisation.

Your business should be saying: Where do we need to improve? and how will we measure success? Agile transformation may be a means of reaching that goal.

If you choose an Agile Transformation you will measure success by delivering what customers need, by creating happy and satisfied customers not adherence to a plan. You will measure teams success by those that are willing to learn and grow.  By empowering teams to make decisions for themselves you can create an environment of continuous improvement.

Change is Hard

Change is hard, and we continually underestimate how hard, preferring instead to look for ways to do the same thing but call it something new. Sadly many of the frameworks buy in to this and offer solutions that let everyone continue as they were doing the same thing but add a stand-up and call it agile. When the reality is that a change to an Agile Mindset is an investment in your future, if you are not willing to put in the effort and make that investment you are doomed to repeat the same problems.

About the Author

John Yorke is an Agile Coach for WWT Asynchrony Labs, he leads the Product Owner Chapter within Asynchrony and runs a Product Ownership Meetup in St Louis. John has over 20 years working in software delivery, as a developer, designer, project manager and department head. Now, as a coach, he supports clients with Agile Transformations as well as coaching the delivery teams in house. He is also a writer and speaker on agile topics.