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…