Agility – what’s in it for non-development roles, such as prod.mgmt or even sales…?


So, your development teams are now agile, they operate in a cross-functional setup, they do feature centric development, they practice continuous integration & delivery, and you have a number of communities-of-practice alive and well.  Are you now really agile, is your entire organization agile…. ?  Not likely, as I argued in a previous post.

But putting aside, at least for now,  the problems of making agile any large organization, typically characterized by rigid organizational structure, top-heavy process orientation, a plethora of  organizational layers, and suffocating bureaucrazy, let’s instead ask ourselves what –  if anything –   of value does agility provide to non-developer roles within any innovative development company.

For simplicity, let’s take the role of a product manager as our example:

In a not too distant past  – when men were men, and sheep were afraid – before the age of agility, product manager’s tended to travel the world, talk to existing and potential customers, and gather information about their needs and requirements. Then, they massaged this information into a high level product specification, and directed the development organization to implement something to match the customer’s needs.

Sometime later – very often very much later! – a product was more or less ready to be sent out the door, to the eagerly waiting customers.

During these dark ages, the customer involvement and their interaction with the organization responsible for developing a solution to match their needs was thus very much limited, in time as well as in volume.

In today’s world, most of our customers are not prepared to wait, nor are they willing to accept inflexible “written-into-stone” type of feature spec’s, and first and foremost, most of them – with perhaps domains such as Aerospace & Defence still being exceptions –  are no longer willing to engage in an old fashioned “development-by-contract” model.

Instead, our customers have become agile, they count on being able to change their minds mid-project, they expect their suppliers being able to cater for changes of many types way far down the project time line, and they expect their supplier’s to answer positively to such late-hour change requests.  In a nutshell, the modern, agile customer expects his/her supplier not to answer “No, we can’t, because we did agree on something else, you surely remember!”, instead the only acceptable answer in our brave new agile world is “Yes, we can!“.

So, let’s say you are a product manager (or heaven’s forbid, a sales guy!) doing some severe customer facing time with your important customer, and mid-way thru your discussion the customer comes up with a new fancy feature request that is currently nowhere near the top of your current product backlog:

Since you are now dealing with an agile customer not taking no for an answer, how can you decide in realtime what your answer to this customer request should be ? How can you decide, while sitting in the customer meeting,  whether your development organization is even capable of delivering the requested feature in any reasonable time, for instance, do you know the current “load” of all your teams, do you know the overall feature priority list by heart, have you access to the piece of information that one of your prod.mgr colleagues this very morning commited another unplanned  major feature to another key customer…?

If you are like almost all the development organizations I’ve ever worked with, the anwer to most if not all of the above questions will be “no”. That is, in that customer facing situation, you, as the product manager, have no ability what so ever to make an informed decision in realtime regarding how long it would take your organization to realize the requested feature.

Instead, the typical answer to the customer is something along the lines of “… let me get back to the office and meet with my team(s) to discuss this idea of yours. I’ll get back to you as soon as we have analyzed your request and made a decision, it will probably not take more than 3-4 weeks”.

That type of answer might have had cut it in the past, but in today’s agile world, with customer’s expecting and demanding agility, you are about to face a “lost opportunity” pretty soon  here.

Thus, in today’s fast moving world, customer’s expect you to respond with “yes, we can!“, and in order for you being able to respond in that way, you need accurate, detailed, and timely information about all relevant aspects of your current development situation, in other words, you need total transparency into the complete status of your development machinery at your fingertips.  Out-of-date – even ever so slightly! – off-line spreadsheets/documents on your laptop will not provide the needed minute-by-minute snapshot of your current “production machine status”, in order to have any confidence in your answer to your customer, you will need a state-of-the-art information & analytics engine capable of rolling up any kind of leaf-level development status and product data into a format allowing instant analysis and decision making.

As of this time of writing, there are not many such technologies around, but for any organization increasingly facing agile customer’s, such a technology will soon not be optional, but necessary to stay alive.

For a “vision” of how this type of truly agile organization is able to operate, consider the the situation facing a potential customer stepping into the show room of a premium car maker. The sales guy at the car company is able to provide instant and accurate information regarding  exactly when the car with all the requested bells & whistles, i.e. the tailor made car the customer wants to buy, will be available for delivery.  Without “deep” transparency, such precision in information is not possible. Now, as goes for most analogies, this analogy is far from perfect, particularly since the car example deals with “instances” of an already existing product, whereas we in the systems and software business mostly deal with designing completely new “classes”, that is, the car example is from a world of production, while our world is fundamentally a world of design. But despite the imperfection of the analogy, it might help us establishing a shared vision for where “agile & lean software production” should aim at.

For more details on why software is different from traditional engineering efforts, see this paper on the differences between software and engineering I wrote a looong time ago…


About swdevperestroika

High tech industry veteran, avid hacker reluctantly transformed to mgmt consultant.
This entry was posted in Agile, Business, development, software, Systems, Technology and tagged , , , , , , . Bookmark the permalink.

4 Responses to Agility – what’s in it for non-development roles, such as prod.mgmt or even sales…?

  1. I really like that you put “agile” into a broader, non sw-dev context. From what I see, we all struggle to establish this mindset across all roles of the product lifecycle – from product management, to the labs, to sales/tech sales, to field services consultants to the software support organization etc… I’m not sure if I will live long enough to see “agility” across all these LoBs.

    The point you make in your post (transparency, always up-to-date in-flight information) is key, but doesn’t solve the problem completely.
    If you consider the PM (or sales) guy sitting in a customer meeting to be kind of a “Product Owner”, you’re not allowed to make commitments to your customer at that point.
    Still with agile, your job is to “shield” your delivery team from distractions until the next planning session, where the team can triage the new requirements.
    The feedback cycles might be shorter, but you still need time to let your analyze what they think the effort, impact, risks etc.. of this request will be. You as a product manager, would also need some time to think about the impact and the overall strategy of your product.
    I’ve seen more than once that there where “tactical” feature commitments to one single customer. It turned out that at the time the feature was released a) it wasn’t that important anymore and b) created lots of technical dept for us and issues for other customers not requesting the feature.

    Finally, I think the problem is not that we have to tell the customer that we have to go back to our team to analyze the request and come back later – the problem is that if we do, it should not take two more years of development to actually GA it.
    – Florian

  2. Florian, thanks for the comment, appreciate it! I’m fully aware of the issue you point out, that the problem of becoming a truly agile *organization* is not fully resolved by what I suggest. But I believe that for “agility” to truly become mainstream, not only in small shops, or, when it comes to large organizations, exclusively within their development team, we as a community need to identify the “what’s in it for me ?” for all the non-developer roles out there. I’m convinced that it’s only by clearly demonstrating true value derived from agility to all these non-developer roles that we can hope to reach the new desired state of a truly agile organization. So, I’m fully aware that my post is a bit simplistic, but still, I think this type of thinking is the way to go (not least for those companies that provide tools in the ALM/CLM arena…! 🙂


  3. Excellent points and description on today’s situation and suggestion on a future solution. However I think that on of the key aspects of agile development is closing the distance between development team(s) and customers. So as Florian correctly said, the PM has no possibility to commit at the meeting.
    Off course the answer to the customer should be “Yes we can!” with a rough guestimate based on accurate data, maybe even a projection on priority as compared to existing requests. The PM can be working agile with the customer based on real-time data, but how can he estimate the effort, cost, risks and everything on data alone without the input from development?
    So in addition to answering ‘Yes, we can!” this should be an invitation for further discussion and explanation at the correct point in time in the near future. Unfortunately it seems still to be a long way for organizations outside of development to embrace the level of agility, accountability and customer involvement needed.

  4. Erik, thanks for the comment! It’s very obvious to me that for most large organizations, “Agility” is not something that has penetrated outside of the development teams – at business and administration level, most large organizations still operate in a traditional hierarchical “command & control” fashion, leading to low velocity,general inefficiences, unwanted information redundancy, lost business opportunities, poor quality, inflexibility and demotivated staff. My guess the reason for this includes that upper mgmt are rarely if ever aware of the “philosophical” dimension of agility and lean – for the Cxx-folks, agile & lean are just tools to that might be used at the leaf levels of the organization.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s