Skip to main content

Are You Ready for the Fallout?

There is an old saying – “An Agile transformation is easy, you only have to change two things: Everything you say, and everything you do.”

However as obvious as that joke was, it is also wrong. You only need to change one thing; you need to modify the way you think. 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 or Product

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

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. However, more significantly, it is tough to know what you want until you see it and consequently there is an abundance of quality software products that do not adequately fulfill 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 custom software solution you can know your end state before you begin, regardless of how well you analyze. No matter how good at planning you are if you do not 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 realize that custom 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. Management consultant Peter Drucker is an inspiration here, as traditionally we put so much effort into getting things right, to be more efficient, or to do this by that deadline. Given that we often forget to ask if what we were doing was 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 the effort to a focus on the value. To set a direction and “lead” the way in product development. Try to stop measuring output and start measuring outcomes.

Impact on Project Managers and Business Analysts

This is a significant 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.

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

Software projects are far more complicated with many unpredictable variables with the biggest variable being the end state. In many cases the end state is not known at the outset and emerges while developing the product. The true end state needed to fulfill 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.

Business Analysts similarly must adapt, as project planning relies on a knowing as much as possible at the time of planning, and so there is substantial reliance on the Business Analyst. Product Development is again a mind shift for a Business Analyst since there is no longer a need for detail up front. 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 an early assessment at a high level is all that is needed with detailed analysis happening much closer to when the work is done. At this point what is needed is more known, and so we are not wasting time analyzing something that will not be done.

An Agile Mindset

Agile is a mindset far more than anything else, and when you start to consider it, there is nothing new, nothing original, and you will be surprised to find that while the word Agile has been used a lot by the software industry in the last 20 years or so, the principles and behaviors are simply the good practices of general management going back a century or longer. “Agile” as we have come to know it can cover Scrum, Kanban, Lean, Lean Start-up, or any of the many other Agile frameworks. In most cases, it means a collection of historic good practices and guidelines identified by successful leaders and businesses that have been collected under one umbrella, polished, and marketed. I say this to discourage the notion that Agile is new and untested. It is essential to note that there are misinterpretations and misapplications but that the underlying principles are sound and based on much experience.

Let’s take for example the Ford Motor Company. If you looked at this company over the last 100 years and assessed it against modern standards of agile, my guess would be that Ford held up quite 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. For example:

  • Are your customers dissatisfied?
  • Are your products missing the mark?
  • Do you (or your clients) feel you are not getting value for the 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 Return On Investment (ROI) for software development too small?
  • Are you losing critical 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.

Comments (2)