I’m a big believer in the employment of Lean principles to complement Agile methodologies in application development. From a pure software development perspective, Agile has proven enormously beneficial in speeding through application projects. However, what Agile typically does not address is the first principle of Lean: the definition of value in each application development initiative.
Generally speaking, “software running” is typically the defined value in any application development engagement, and Agile is all about getting software running. But the question this fails to address is what software is actually running. The answer – and the real value – lies in delivered and running the right software, something that can only be achieved by applying Lean thinking. Although it may sound simple, getting this proposition right may not be so straightforward. In other words, the old saying, “garbage in, garbage out,” holds true even when it comes to Agile.
Does this mean that we need to go back to the “requirements” phase of traditional methodologies, before starting the project implementation under Agile precepts? Of course not. This would entail a significant step backwards, as well as a knockout on flow and pull, and it would generate considerable waste – waste that Lean aims to eliminate. Requirements are discussed in Agile projects as user stories, or items on the product backlog, as part of the flow, in a much more interactive (and rich) way than the boring “requirements analysis” we were used to.
What’s necessary is for the development team to know the ultimate business purpose of the project, and to understand in the customer’s terms the definition of the ultimate value – i.e., the intent of the application.
How does it fit into the business strategy? What are the business goals that will be achieved by means of this new application (and everything else surrounding it, since it’s never just the application)?
It sounds obvious, and maybe that’s why people are so often misled to being satisfied with far-too-simplistic answers to these questions. The key is to not take the goal as a given, but to truly question the definition of value in each individual project. This includes a better understanding of the business goals and metrics for success, and why it is believed that the software will help to achieve them.
Imbued with that spirit, the Agile team can deliver far greater and more measurable results. The team can truly serve as a partner to the business stakeholder in the client organization, and bring considerably more to the table than just the technical ability to transform user stories into code in an efficient way. It is only with this perspective in mind can the Agile team contribute in a strategic way, helping the business to prioritize user stories according to the value delivered.
Of course, many would argue that the development team does not have a say in the backlog prioritization process or the business value of the application. Some would also argue that the role of IT is tactical and that the business should come to IT with everything already prioritized.
My intention is to illustrate that the development team should provide the means for the product owner to objectively rank backlog items and user stories based on business value, and that such a mechanism should foster dialogue among the business, its representative in IT (the product owner) and the development team. Moreover, by fostering this dialogue, the development team will be able to develop better applications, because from the discussion it derives a much better grasp of what really delivers value. If this isn’t enough, the development team over time will become increasingly mature in its understanding and ability to offer valuable contributions on business matters.
In the interest of demonstrating how the concept of application teams contributing on business matters in development projects can be practically applied, I’d like to discuss a technique that can be used by application development teams (both internal and external) to foster a dialogue with business clients – value engineering.
Regardless of whether this is catalyzed by the business clients (which would be ideal, but is unlikely based on typical behavior) or the IT organization (including the app dev teams, which are actually in the best position to make this work), this method provides a better understanding of and alignment around business goals and is surprisingly simple to implement.
Imagine, for example, that we’re using Scrum (one of the Agile methodologies available), we are about to start a sprint (a time-boxed window of two to four weeks at the end of which some software will be delivered), and we need to decide what to prioritize for that sprint. The typical conversation would sound something like this:
ScrumMaster (SM): “Product Owner (PO), based on what we have in the backlog (and any new needs that might have appeared), what would you like us to do on this sprint?”
PO: “Good question. On this sprint we should do A, B, and C, since these features are important because of x, y and z” (x, y and/or z typically include a deadline: “It must be live by mm/dd/yy”).
SM: “Ok, we will verify that this fits our delivery capacity, and if so, we will begin immediately.”
And the team, led by the ScrumMaster sets about developing the features. At no point does the team discuss why those features are really important. And at no point do they question whether or not those features should be a priority. It’s taken for granted.
Now, imagine a different situation arises when the team asks the PO: “PO, what is the business value of features A, B and C?” using an objective measuring stick to rank them. The PO, armed with the knowledge he or she acquired about value engineering, writes down some values (preferably using a non-linear scale, so as to truly distinguish among priorities).
Next, the SM replies: “Ok, here is the cost to implement those features.” They quickly map on a chart how the features compare in terms of business value vs. cost-to-implement. In using this approach, there’s a chance that the PO might actually realize that feature D should be included along with A and B for that sprint. Or, alternatively, they may recognize that feature C, although expected to “go live” by a certain date, doesn’t deliver much business value or is too costly to implement in relation to the value provided.
In this case, the PO, if not totally entrusted to make decisions (though this would be ideal), at the very least possesses an objective mechanism to bring the issue about in meetings with upper management. Meanwhile, the development team receives a better understanding of what is really important in the project, which gives them an opportunity to contribute at another level (a faculty that develops over time among the team).
The bottom line — and the major benefit of value engineering — is that the development team understands its contribution to the business, and is therefore empowered to make decisions in projects with an understanding of how the software is impacting the business. This makes the provider’s use of Agile, with its focus on getting software running efficiently, more effective overall, while helping companies to focus on complementing it with the Lean principle of understanding and adding value.
Leonardo Mattiazzi is Vice President of International Business for Ci&T, a global IT services company headquartered in King of Prussia, Penn., and Sao Paulo, Brazil.